Cryptography-Digest Digest #583, Volume #10 Wed, 17 Nov 99 18:13:03 EST
Contents:
Re: AES cyphers leak information like sieves ("Douglas T. Yoest")
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: ATTN Scott Nelson (Scott Nelson)
Re: weak ciphers and their usage ("Gary")
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: NSA should do a cryptoanalysis of AES (albert)
Serpent speeds tested (albert)
Weak keys in Rijndael? What happened to that? (albert)
What part of 'You need the key to know' don't you people get? (Tom St Denis)
----------------------------------------------------------------------------
Date: Wed, 17 Nov 1999 15:38:29 -0800
From: "Douglas T. Yoest" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: AES cyphers leak information like sieves
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Not everyone is only interested in cryptography for the internet. While
global, its very narrowing.
<p>Doug
<p>"SCOTT19U.ZIP_GUY" wrote:
<blockquote TYPE=CITE>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
<br>>DJohn37050 <[EMAIL PROTECTED]> wrote:
<br>>
<br>>: This is known as the self-syncronizing property of CBC mode.
You only lose 2
<br>>: blocks due to a bit flip. Check it out if you do not believe
it.
<br>>
<br>>OK, then - I'll look it up.
<p> It is well known back in the morsecode
days one needed a way to
<br>get back in synch. Today it called error correcting and all the 3 letter
<br>ways of chaining have this "feature" but the only people who can really
<br>use the feature today are those breaking codes. The system protocol
<br>of the internet should keep your messages intact. It is foolish in
todays
<br>world to have these features part of encrption. The only reason it
is still
<br>there is inertia of the public crypto community and the fact the NSA
<br>likes people to use these old ways of chaining blocks.
<p>David A. Scott
<br>--
<p>SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
<br><a
href="http://www.jim.com/jamesd/Kong/scott19u.zip">http://www.jim.com/jamesd/Kong/scott19u.zip</a>
<p>Scott famous encryption website NOT FOR WIMPS
<br><a
href="http://members.xoom.com/ecil/index.htm">http://members.xoom.com/ecil/index.htm</a>
<p>Scott rejected paper for the ACM
<br><a
href="http://members.xoom.com/ecil/dspaper.htm">http://members.xoom.com/ecil/dspaper.htm</a>
<p>Scott famous Compression Page WIMPS allowed
<br><a
href="http://members.xoom.com/ecil/compress.htm">http://members.xoom.com/ecil/compress.htm</a>
<p>**NOTE EMAIL address is for SPAMERS***</blockquote>
</html>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 21:47:49 GMT
In article <[EMAIL PROTECTED]>, Volker Hetzer
<[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>> True but the purpose of some encryption is to make the data as hard as
>> possible for the attacker to recover. So you can add security by hiding the
>> information through out the whole file.
>How much security do you gain over a bidirectional CBC with a cipher of
>a blocksize of 128 bit?
>How much over a normal CBC with a cipher of a blocksize of 128 bit?
>
>The fact that in case of modifications not everything decrypts to garbage
>is no problem at all as long as a hash is included in the plaintext.
>
>> Standard 3 letter chaining methods
>> give a false since of security by giving the illusion of hiding data through
>> out the whole file.
>They don't give a false sense of security and no illusion either. They just
> exist
>and have properties that are easy to see for everyone.
>
>> As my procedure shows. When you edit a file that uses block encyption
>> with standard 3 letter chaining even if you do several passes of CBC when
>> you decrypt the modifed file only a small set of blocks come bach with
> errors.
>What's the point?
>The modes are there to hide plaintext patterns and to prevent dictionary
>attacks. They do exactly that.
>
The point is they don not spread information through the file so that
a code breaker needs to only analyize a small fragment of the file.
If one wants true security one should have the option of using chaining
that does not mod the file length and does spread information through the
file. Of course your happy with the status quo and may the NSA bless you
for your weak sighted beliefs.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: ATTN Scott Nelson
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 Nov 1999 20:54:56 GMT
On Wed, 17 Nov 1999, [EMAIL PROTECTED] (CoyoteRed) wrote:
>Thanks for your response to the "Another random number generator." My
>news server dropped it and I found it on accident as I was doing a
>deja search on some of my posts.
>
>Thanks for the input, but you mentioned that with skipping that the
>attacker may be able to resync his samples. I take it that you mean
>/after/ digitizing the signal? I'm thinking a major problem that he
>would have to over come is getting this string of samples as this only
>resides in the machine that is doing the generation and then is gone.
>Plus, trying to sync his samples to mine if he was listening to my
>analog signal would be difficult.
>
Yes.
>He would have to have a recording of my analog signal and use some
>kind of test to get the same samples as me as he "phase-shifts" and
>adjusts the gain of the recording in relation to the sampling
>interval. Then the recording would have to be perfectly the same as
>the signal on my machine, no induced noise. With the slightest
>deviation in a signal (gain, waveform, etc.) would throw off the
>samples, fine tuning would be extremely difficult. (Obviously this
>points out that if you use the 'blank cassette scheme' one would then
>have to record over or bulk erase this tape to destroy the 'blank'
>signal.)
>
>Plus in order to do these tests he would have to have something to
>test against. But let's pretend that he did have the first 100 bit
>portion of our number and was trying to get the rest.
>
>So, he has a recording and is time-shifting and adjusting the gain of
>the A-D convertor. It seems that if we are /not/ skipping, then he
>could get close and see a large percentage of bit matches, he would
>then be able to fine tune his adjustments to get the exact match.
>Plus a few bits of noise would not matter that much as he would only
>have to try all of the other possiblities.
>
>But with skipping, the bit stream would be so different for each time
>and gain differential that he would have to have an exact match before
>he even realized that he was close.
>
>Then as soon as he came across a
>noise hit he would have to start testing for the next true sample, but
>this will only work until he runs out of the stream that he has to
>test against. Plus, the earlier in the stream that he gets a noise
>hit the more it would effect his tests. So, if he has 100 bits and is
>running through his time and gain differentials and is testing for say
>55% plus matches then a single noise hit early in the stream would not
>alert a proper time/gain differential hit.
>
Start with the assumption that the enemy can do the
sampling perfectly (yes, it's not true, but start
there anyway) Then he'd have exactly the same set of
samples that we do. He takes the bits 2 through 5
of _all_ the samples and converts them to their skipping
values. Start anywhere in the stream, and proceed
as if that was where we started. Very quickly he
falls into sync with us. Once in sync, he stays in
sync.
If you have trouble seeing that, consider the
following sequence. Start anywhere in the first
half, and what ever number in that position, move
that many to the right. You'll always end up on
the last 3.
32414313133342414324231143043
1 11 11 1 1 1 111 1
2 22 22 2 2 2 222 2
3 33 3 3 33 3 333 3
44 44 4 4 4 444 4
The same principle applies to larger numbers,
it just takes more samples to get in sync.
So _if_ the enemy can digitize perfectly, skipping
only makes his task a little bit harder, and only
at the beginning. (There are actually ways around
the beginning problem too, but I won't go into that.)
Now suppose the enemy can't digitize perfectly.
Suppose as far as he's concerned, one 'skipping'
bit is always random. Then any value can lead to two
possible locations. Those 2 lead to 4, but then,
some of those 4 might collide with the others, so
there might be 8, or 7, or 6 locations. At most,
there are 16 possible locations we can be at.
(pick a stretch of 16 samples. We have to use
one of them.) So the enemy has to track all
16 possibilities.
It adds some complexity, but not much.
>I don't yet understand MD5 or SHA1 to know how much this will add to
>our randomness so my thinking is relying on more mundane means, but
>doesn't mean that I don't think MD5 or SHA1 wouldn't be beneficial
>though. So, I'm trying to get randomness and security on a basic
>level /before/ we more thoroughly massage the numbers.
>
The key point here is that how ever much randomness
is in a sample, that's all there is. A 'good'
function would use every bit of it. Skipping avoids
an average of 1/8 of the samples, so it must be
worse than _some_ function which made use of those
intervening values.
SHA1 is the 'high power' version of that function,
but it's not the only one. Just remember the basic
idea; All previous values should affect all the future
values as much as possible. Once the enemy is out of
sync, you want him to stay that way.
Here's a few example functions that are lessor versions
of the concept.
Take the LSB bits of each sample and rotate them into
a holding byte. Instead of throwing away the most
significant bit, XOR it with the incoming bit. In "C"
holding_value = holding_value<<1 ^ newbit ^ (holding_value >> 7)
Any mistakes the enemy makes will stick around forever.
But there's only 8 bits, so there's only 8 possible mistakes.
These accumulate, but only to a maximum of 256 possible values.
Plus, an error only affects every 8th bit.
We could use a CRC, which is just a more complex XOR
function and a larger holding register.
if ((newbit & holding_value) == 1)
holding_value = holding_value>>1 ^ 0xa4f18722
else
holding_value = holding_value>>1
That way errors will propagate across all the bits,
and the number of possible states can be very large.
We can use a LCG style accumulator
holding_value = holding_value * 17 + newbit
Or better, an LCG with carry
holding_value = holding_value * 17 + newbit + (holding_value>>30)
Which has about the same performance as CRC,
but is much harder for the enemy (and us) to analyze.
The important point of all of these techniques is that
the current value is based on _all_ the previous values,
and the larger the holding value, the more randomness can
accumulate.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: weak ciphers and their usage
Date: Wed, 17 Nov 1999 21:01:53 -0000
Correction:
I should have stated using 3 letter chain modes with a small (~128 bit)
block cipher only requires work on the first 2 small blocks.
Is key strenghening exportable even if it is indirectly done through time
consuming decryption algorithms that require the whole ciphertext?
Gary wrote in message <80v4ho$ij8$[EMAIL PROTECTED]>...
>Since using 3 letter chain modes only requires work on the first 2 blocks.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 22:07:02 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>In article <80tg4o$tg6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[ ... ]
>
>> You sir are ignoring reality. If you do the test I showed you.
>> You will see that all you pet modes are an illusion. They do
>> not spread the information though the file. But either you
>> don't understand or are to lazy to test.
>
>Quite the contrary: that's a well-known feature of (for example) CBC.
>Its self-synchronizing property is well-known and useful. I don't
>know what test you're talking about, but proving its existence is
>roughly as useful as yet another proof of the Pythagorean theorem: it
>might show that eventually, with sufficient tutoring, you'll learn
>enough about cryptography to be worth listening to, but provides no
>new information about the chaining mode at all.
I agree to those that know crypto this is not new information but
it is usually not fully covered and as you can see many people are
mislead by it.
>
>> Think why are they are this way. Could it be of use to the NSA.
>
>If you can show a practical attack due to the nature of CBC, feel free
>to do so. Right now, you're apparently of the opinion that a purely
>imaginary attack is more important than a very real error-recovery
>ability.
If one looks at what the so called Slide attack was attenpting
to do was to get pairs of data for the 19 but S-block that was used
in my code. Of course the slide attack was a failure due to its poor
design and a lack of understanding by Wagner of how my code worked.
The fact is you could have used any block cipher where I had the
19 bit lookup table. Then the slide attack would be reduced to trying
to find input output pairs to a block cipher. Something that is already
available to any one looking at the common 3 letter ciphers and do
a plain text attack. My virture of this mean is better asshole.
>
>> Look even
>> PGP use a weak chaing mode with compression. Most
>> people don't have the software to recover the real file
>> if a change occurred in the middle of the compressed encrypted
>> text. So what fuckin good does this error recovery do anyone
>> who depends on PGP. It does them no fucking good it can
>> only be of use to a dedicated attacker.
>
>For those looking on, I'll translate this into understandable (and
>civil) English: you're just as clueless as ever...
>
>> That is also way intelligent people should have the option
>> of using something like "wrapped PCBC" when they want
>> a far higher degree of security than the NSA 3 letter blessed
>> mods that you foolish think is safe.
>
>If you want to claim that one thing is more secure than the other, you
>need to quantify the security of each and then compare the two. Right
>now you're just making your usual unsupported claims. Oh well, back
>into the Bozo Bin with you...
I did you stupid pompous ass but your to dim witted to follow it.
Your are mostly more of BOZO with a suit and tie than me.
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 21:55:33 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>: Volker Hetzer <[EMAIL PROTECTED]> wrote:
>
>:>If you want to disguise patterns forward and backward, use CBC twice (in
>:>both directions).
>
>: Actuall when I first got interest in Ciphers many years ago. I did try
>: double CBC and using CBC as two direction passes. But what I found
>: out was that when one does either of the 2 methods and you hex edit
>: the encrypted file only a few blocks of plain text are messed up. So
>: that the information is not really spread throught the file.
>
>First, a disclaimer: what I know about block chaining will probably fit
>on a postage stamp. However, what I /do/ know seems relevant here.
>
>It is true that editing a bit in a file encrypted using this method
>will change three blocks. Two blocks will be changed completely,
>and one partially.
>
>However, this does not mean that information relating to the encrypted
>text is not spread throughot the file.
>
If you chane only one byte of block in the encrypted file and you recover
all but the blocks in that area it means information is not spred through the
file. If you take a long file and use whatever IV and CBC and use two
different keys and encypt in each direction. If you are given the middle
portion of the file. Except for a few blocks at the ends of the segments
you get on decyption the plain text that was there. So that means the
info is not spread through the file. You would not argue that if some one
did a 2's complement of each byte that info was spread. The fact that
the whole file may change due to a different IV does not mean infor is
spread.
To me the concept is pretty strainght forward. If a portion of the data
can be recovered from a portion of the file then all the information for
reconstructing that info is there. What could be easier to understand.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: albert <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Wed, 17 Nov 1999 13:13:22 -0800
> <snip>
> I think its a safe bet that whatever wins is something they can break.
>
> David A. Scott
>
Hmmm, what makes you say that? I tend to lean towards the thought that while NSA
might be ahead, they aren't THAT ahead. Even though "Sneakers" is my favorite
movie, I seriously doubt they have some black box to crack everything.
I'm quite interested as well to see reports that NSA did say to NIST that all 5 are
pretty secure...
------------------------------
From: albert <[EMAIL PROTECTED]>
Subject: Serpent speeds tested
Date: Wed, 17 Nov 1999 13:18:22 -0800
I took Frank Stajano's Python code, and tweaked it a bit. Stuck a few
loops in there, a few clock functions, and timed the "generic" Serpent
vs. the Bitslice method. The bitslice method came to be almost always
2x faster than the standard implementation (on 32 bit arch..) I suspect
close to 3 - 5x faster on 64 bit implementations, if Bitsliced DES is
any indication.
Anybody else out there do any Serpent standard vs. bitslice speed
testing? I'll post the results when get a chance to put it in a
digestable format..
Albert
------------------------------
From: albert <[EMAIL PROTECTED]>
Subject: Weak keys in Rijndael? What happened to that?
Date: Wed, 17 Nov 1999 13:15:10 -0800
I seem to recall reading someone (think his name was Tom???) who posted
something about Rijndael having weak keys. Anybody hear any more on
this? Was it a joke or for real?
Albert
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: What part of 'You need the key to know' don't you people get?
Date: Wed, 17 Nov 1999 21:19:46 GMT
Ok this is going on too long as well.
If I give out a C=Ek(P) to someone else... let's say Alice. And Carol
in the middle flips a bit in the middle of C. What will this reveal to
Carol? Hmm not much if anything at all.
Somehow some person [nameless] believes that this is a problem. It's
not. Unless you have broken the cipher or have the key 'k' you are not
getting the plaintext.
Let's take a simple CBC mode file ABC = Ek(DEF). Now let's change B to
Z we get AZC. What does an attacker learn from this?
Seriously you have to rethink your logic. This is not an attack that
is usable if you salt your key, use a IV and ANY chaining mode. If I
change my key and IV with each message, you will get Dk1(A) != Dk2(A)
even if A == A, which means even if you get similar ciphertext out it
will most likely not correspond to the same plaintext.
I can't imagine why this argument is continuing except for some
[nameless] person to annoy others. As he explained it, it's not a
weakness point and simple. Just chaging bits of ciphertext do not
reveal plaintext? Hmm... la changement d'information enchifre ne donne
pas le vrai message au attaquer... any other languages?
Seriously now... just rethink it... and please stop the insane posting!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
