Cryptography-Digest Digest #468, Volume #14 Tue, 29 May 01 03:13:01 EDT
Contents:
Re: Good crypto or just good enough? (Stefan Lucks)
Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: Good crypto or just good enough? (wtshaw)
Re: Good crypto or just good enough? ("Scott Fluhrer")
Re: James Felling: Sorry to break your bubble (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Stefan Lucks <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Tue, 29 May 2001 07:09:26 +0200
On Mon, 28 May 2001, Eric Lee Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 28 May 2001 15:19:08 +0200, Stefan Lucks <[EMAIL PROTECTED]
> mannheim.de> wrote:
> >On Sun, 27 May 2001, Tom St Denis wrote:
> >> > I have recently seen an application where people encrypted their
> >> > plaintexts using triple DES in OFB mode. As it turned out, what they
> >> > really wanted was authentication, and they actually did not care much
> >> > about confidentiality. So using a single DES based CBC-MAC would have been
> >> > much better than encrypting under triple DES.
> >>
> >> For authentication I would have used a hash first ...
> >
> >What is the purpose of a hash here?
>
> A hash by itself simply verifies that the message came through. If you
> then encrypt the hash [...] then you have a signed message.
I don't think so. Encrypting a key-independent hash value does not
necessarily provide a secure MAC. (Well, it depends on the choice of
encryption, but note that I mentioned using triple DES in OFB mode above.)
Denote the original message by M, and assume both M and the hash value
H(M) are encrypted using a block cipher in OFB mode (as above), or any
binary additive block cipher. Instead of a MAC value, you have a value
X = (M || H(M)) XOR S,
where || denotes catenation and S is a key-dependent key stream, not
depending on M.
Assume the adversary somehow knows M. She can compute H(M) and thus
S = (M || H(M)) XOR X.
To provide a valid forgery for any message M', she computes
X' = (M' || H(M')) XOR S.
Voila!
--
Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
e-mail: [EMAIL PROTECTED]
home: http://th.informatik.uni-mannheim.de/people/lucks/
====== I love the smell of Cryptanalysis in the morning! ======
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 29 May 2001 04:21:08 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>>
>> Uncity distance is a concept found by Shannon that is valid even
>> today. It has to do with the amount of cipher text needed to be
>> looked at in a ciphertext only attack to determine the key and
>> the rest of a secret message.
>[snip]
>
>
>Unicity distance can be interpreted as the smallest number of
>of ciphertext letters which must be intercepted in order to
>expect a unique, *meaningful* decipherment. It
>is a function of both keyspace entropy and the redundancy of the
>"language". Language redundancy arises from the fact that not
>all possible messages are meaningful.
>
>I don't see how compression makes a difference. Compression reduces
>the redundancy (a message in a language that contains no redundancy
>cannot be compressed), but since the redundancy is a property
>of the *language* then not all decompressions will be meaningful.
>
>I don't think you can get around this. It seems to me that all you're
>doing is adding another step, i.e. decrypt and then decompress to
>determine
>whether or not the message is meaningful, rather than just decrypting as
>the case would be if no compression were used.
>
>Simply put, redundancy is a feature of the language. You can't change
>the redundancy without changing the language. Without changing the
>redundancy you can't change the unicity distance (assuming no
>change in the entropy of the keyspace).
>
>Am I overlooking something?
Well your right in the fact differnt langues have a different
reduncacny so the unicity diestance would be different. Thats why
when breaking a encryption you need to know the language used.
But if you belive Shannon and I think most who read him do. Compression
does increase the unicity distance. If you had language with no
measurable redunancy I guess you could encypt it with most anything.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Good crypto or just good enough?
Date: Mon, 28 May 2001 22:57:46 -0600
In article <9es21q$11lo$[EMAIL PROTECTED]>, "Harris Georgiou"
<[EMAIL PROTECTED]> wrote:
>
> I don't think that modulation has anything to do with comms security.
Relying on modulation that is particuliarly noise sensitive can mean that
signals have trouble getting through. We have talked in years past on
this, but an overall
communciations strategy needs to be sufficiently robust to make the most
of any channel.
> Modulation standards change (at least for radio channels) so that the
> available bandwidth can be used more effectively in cost and speed terms. I
> mean, what specific modulation algorithm can a micriprocessor-based modem do
> that cannot be simulated by software in a standard PC?
You just named two miroprocessor baseed systems. My statement is that
none might be needed.
> Sure speed is a
> factor, but no one can rely on the secrecy of the modulation scheme (which
> is not key-specific in most cases) or the channel speed to ensure that no
> eavesdropper monitors the traffic. Of course special-purpose modulation can
> make the cracking work harder but it's no way comparable to encryption or
> authentication.
In dedicated systems I have made, I've brewed my own. Hardware glitches
can be a problem if you let them and be hard to fix, but software glitches
are easier to make, maybe harder to find. Modems in extreme environments
must be able to take punishment, where most half-thought out circuits die
rather easily. When you think commercial and military, you figure failure
is pretty much out of the question. Security depends on presence.
I've tried lots of weird modulation schemes; simple usually is best. The
old FSK techniques, usually badly implemented, were where most of us
started, synchronous and low baud rate. Without going into too much
theory, the old premise was wasteful and slow. Things have changed, but
here we start from scratch.
Consider the simplicity and economy of a twelve tone asynchronous system
as a minimum replacement. With a little circuitry you can get synchronous
onits, base 11. Digits in groups are easily sent. Two tones can mean a
set of 100 characters can be used. If the tones are musical notes in one
octave, notes to the limits of the channel can be sent, and due to onlt a
2 to 1 frequency difference as a maximum, band width is easily handled
with simple filters. Of course, digits can mean anything. At least the
term digital is used in a classic sense.
--
Suppose California quit sending food back East.
Would Gerorge be ready to barter with energy?
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Mon, 28 May 2001 22:29:06 -0700
David Wagner <[EMAIL PROTECTED]> wrote in message
news:9eucrq$2i50$[EMAIL PROTECTED]...
> Sam Simpson wrote:
> >Thanks for the response David. I was specifically enquiring RE Douglas's
> >"it must be at least *slightly* more secure" statement. You show that
they
> >must be at least equivalent, but does your proof show that 3des must be
any
> >stronger than DES, rather than just equivalent?
>
> No, it doesn't. It seems to be very difficult to show that 3des is
> even a little bit more secure than des. I don't know of any provable
> justification for the "at least *slightly* more secure" statement (but
> I'd be interested to hear if there is one!).
It is well known that DES does not form a group. From that, we know that
the set of permutations formed by 3DES is a strict superset of the
permutations formed by DES [1].
Of course, getting from "the set of permutations is larger" to "it's more
secure in any meaningful way" is a bit tricky, but at least the first part
is strictly provable.
[1] Actually, that's obviously true of 3DES in EEE mode. It's almost
certainly true of the more common EDE mode, although a proof of that eludes
me at the moment.
--
poncho
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: James Felling: Sorry to break your bubble
Date: Mon, 28 May 2001 23:12:48 -0700
Kt wrote:
>
> HiEv wrote:
>
> > First of all, the phrase is "burst your bubble" not "break your bubble".
>
> HiEv, this guy is one of life's embittered losers. Let him be.
>
> Kt
> --
> http://www.althacker.org
> Web: http://kt.althacker.org
> PGP Fingerprint: 75B2 6525 A47D 7B5B B68B 4141 CAD9 8985 504B 580D
>
> "Two fonts walk into a pub and the barman says, 'Sorry, we don't serve your
> type here.'"
(I posted this 24 & 48 hours ago but don't see it here so I've
posted it again.)
Actually I did post this reply to his post in the original thread.
I posted it here as well because I know that some readers haven't
been following that original thread.
(Be sure to read the last 5 lines of this reply post.)
I am not going to go back and pull out my politeness handbook but he
is the one who came up with the "nasty" flaw comment. When you start
horse playing around with a gorilla I would expect the play to get a
little rough.
I think it is significant when someone says that I have egg on my
face then gives me a suggestion to fix or improve my design then
come to find out that his suggestion is so completely bogus as to
nearly defy description although I did manage to describe why his
suggestion is all washed up.
So with my stunning proof that he doesn't know what he is talking
about with his own suggestion as to what I should do or how he has
come up with a better mouse trap, how can you continue to blindly
give his original comments anything but skepticism?
But you answered this question in your own post: "Which is how just
about everyone feels about it in the first place." (I presume you
are referring to OAP-L3.) You have chosen to "feel" instead of
think.
Don't you have a brain? Why don't you use it then? He clearly
doesn't know what he is talking about here yet you still "feel" his
original comments to be valid.
I responded that his fixed point argument is immaterial. When a
different process is run these fixed points are no more.
If his point(s) is/are valid then when the final OTPs are generated
then you can surely point out to us where and how and why these
alleged "flaws" have affected the OTP output where you can determine
something, anything, etc. (keep hoping) that you can claim has
compromised the output.
To claim there is a flaw requires that one be able to point it
out. Point out any flaw in the final OTP output as a result of these
(immaterial) "flaws." If they are immaterial then they are not
"flaws." Perhaps a better phrase would be inconsequential anomalies
or immaterial peculiarities of OAP-L3.
If you are saying that these "flaws" are material to the final OTP
output then I will ask you as I ask everyone: prove it in the
slightest sense. Give us a clue. Give us something to chew on.
The recommended use of OAP-L3 is to randomly choose the processes to
run and randomly choose what order to run them in and to input
random data into each process.
Check this out. Here are the first 105 permutations from the file
after I have run this particular process ten times with random
input for each run. Now compare this output to what JF suggested.
Array number: 0 0 1 2 3 4 5 6 7 8 9
Array number: 1 0 1 2 3 4 5 6 7 9 8
Array number: 2 0 1 2 3 4 5 6 8 7 9
Array number: 3 0 1 2 3 4 5 6 8 9 7
Array number: 4 0 1 2 3 4 8 9 6 7 5
Array number: 5 0 1 2 4 5 9 7 8 3 6
Array number: 6 0 1 2 4 6 3 5 8 9 7
Array number: 7 0 1 2 4 6 3 8 9 7 5
Array number: 8 0 1 2 5 4 3 6 8 7 9
Array number: 9 0 1 2 5 6 3 4 8 7 9
Array number: 10 0 1 2 7 5 9 6 4 3 8
Array number: 11 0 1 3 4 5 7 8 2 9 6
Array number: 12 0 1 3 4 6 2 9 5 8 7
Array number: 13 0 1 3 4 6 2 9 7 5 8
Array number: 14 0 1 3 8 6 5 9 2 7 4
Array number: 15 0 1 4 3 2 7 5 6 9 8
Array number: 16 0 1 4 3 2 8 6 7 5 9
Array number: 17 0 1 4 3 6 5 7 2 8 9
Array number: 18 0 1 5 2 3 9 6 8 4 7
Array number: 19 0 1 5 2 3 9 7 6 4 8
Array number: 20 0 1 5 2 6 3 7 4 8 9
Array number: 21 0 1 5 3 7 2 9 4 8 6
Array number: 22 0 1 5 4 9 6 7 8 2 3
Array number: 23 0 1 5 4 9 8 3 2 6 7
Array number: 24 0 1 6 7 4 8 9 2 3 5
Array number: 25 0 1 6 7 4 8 9 2 5 3
Array number: 26 0 1 6 7 4 8 9 3 2 5
Array number: 27 0 1 6 9 8 4 5 3 2 7
Array number: 28 0 1 6 9 8 7 2 3 4 5
Array number: 29 0 1 7 2 8 6 9 4 3 5
Array number: 30 0 1 7 3 6 2 8 4 5 9
Array number: 31 0 1 7 6 2 3 9 5 4 8
Array number: 32 0 1 7 6 2 4 5 9 8 3
Array number: 33 0 1 7 6 2 4 8 3 9 5
Array number: 34 0 1 7 6 4 2 3 9 8 5
Array number: 35 0 1 7 6 4 2 5 3 8 9
Array number: 36 0 1 7 8 3 2 6 9 5 4
Array number: 37 0 1 7 8 3 4 5 9 6 2
Array number: 38 0 1 8 2 9 4 5 3 7 6
Array number: 39 0 1 8 3 2 6 9 5 4 7
Array number: 40 0 1 8 3 2 7 4 6 5 9
Array number: 41 0 1 8 4 5 6 2 3 9 7
Array number: 42 0 1 9 7 5 3 4 8 2 6
Array number: 43 0 1 9 7 5 3 4 8 6 2
Array number: 44 0 1 9 7 5 3 6 2 4 8
Array number: 45 0 1 9 8 5 7 2 3 4 6
Array number: 46 0 2 1 5 6 4 9 8 3 7
Array number: 47 0 2 1 5 6 7 8 9 4 3
Array number: 48 0 2 1 6 5 8 3 7 9 4
Array number: 49 0 2 1 7 9 6 8 3 4 5
Array number: 50 0 2 1 7 9 6 8 3 5 4
Array number: 51 0 2 1 9 3 7 6 5 8 4
Array number: 52 0 2 1 9 4 5 3 8 7 6
Array number: 53 0 2 1 9 4 5 6 8 7 3
Array number: 54 0 2 1 9 5 7 8 6 3 4
Array number: 55 0 2 4 1 6 3 9 8 7 5
Array number: 56 0 2 4 3 1 7 5 9 6 8
Array number: 57 0 2 4 3 1 7 6 8 9 5
Array number: 58 0 2 4 3 1 7 9 5 8 6
Array number: 59 0 2 4 3 5 9 7 6 1 8
Array number: 60 0 2 4 3 6 5 8 1 7 9
Array number: 61 0 2 4 9 5 1 7 6 8 3
Array number: 62 0 2 4 9 5 1 7 8 3 6
Array number: 63 0 2 4 9 5 1 7 8 6 3
Array number: 64 0 2 4 9 5 1 8 3 6 7
Array number: 65 0 2 4 9 6 3 8 7 5 1
Array number: 66 0 2 5 1 7 6 4 8 9 3
Array number: 67 0 2 5 3 9 8 4 7 6 1
Array number: 68 0 2 5 4 9 8 6 3 7 1
Array number: 69 0 2 6 1 9 5 7 8 3 4
Array number: 70 0 2 6 9 3 1 8 7 4 5
Array number: 71 0 2 6 9 3 1 8 7 5 4
Array number: 72 0 2 6 9 3 4 1 8 7 5
Array number: 73 0 2 7 1 6 5 8 3 9 4
Array number: 74 0 2 7 1 6 5 8 4 3 9
Array number: 75 0 2 7 1 6 5 8 4 9 3
Array number: 76 0 2 7 1 6 5 8 9 3 4
Array number: 77 0 2 7 1 9 8 5 4 6 3
Array number: 78 0 2 7 3 1 8 4 9 5 6
Array number: 79 0 2 8 3 6 4 1 9 7 5
Array number: 80 0 2 9 4 3 8 6 7 5 1
Array number: 81 0 2 9 4 8 6 7 5 3 1
Array number: 82 0 2 9 4 8 7 1 3 5 6
Array number: 83 0 2 9 4 8 7 1 3 6 5
Array number: 84 0 2 9 4 8 7 3 1 5 6
Array number: 85 0 2 9 6 1 3 7 8 5 4
Array number: 86 0 2 9 6 1 5 3 7 4 8
Array number: 87 0 2 9 6 1 5 3 7 8 4
Array number: 88 0 2 9 6 1 8 7 5 4 3
Array number: 89 0 2 9 6 3 4 5 8 1 7
Array number: 90 0 2 9 8 6 5 1 3 4 7
Array number: 91 0 2 9 8 6 5 1 3 7 4
Array number: 92 0 3 1 8 4 6 9 2 7 5
Array number: 93 0 3 1 8 5 7 4 2 6 9
Array number: 94 0 3 1 8 5 7 4 6 9 2
Array number: 95 0 3 1 8 5 7 9 4 2 6
Array number: 96 0 3 1 8 9 7 2 4 5 6
Array number: 97 0 3 1 9 5 6 2 8 7 4
Array number: 98 0 3 4 6 9 5 1 7 8 2
Array number: 99 0 3 4 8 1 7 5 6 2 9
Array number: 100 0 3 4 8 5 7 2 9 1 6
Array number: 101 0 3 4 8 5 9 6 1 2 7
Array number: 102 0 3 4 8 5 9 6 1 7 2
Array number: 103 0 3 4 8 6 2 1 5 9 7
Array number: 104 0 3 4 9 2 5 6 1 7 8
JFs suggestion will never ever even come close to this. Every
single one of his 105 permutation groups will always have the first
5 or 6 digits exactly the same no matter how many times he runs
his process.
I seem to have concretely defended my position. If it is not clear
enough then tell us a problem you have with OAP-L3 and I will address
it further for you.
JFs suggestion that my groups are 105 permutations is misleading.
Technically this is true when you look only at one specific running
of the process. But the effect is cumulative over the entire
3,628,800 permutation set. The more the process is run the more the
effected group is expanded: the entropy over the entire permutation
set increases.
His suggestion was exactly 105 permutations long and remained so no
matter how many times he ran the process. The entropy was confined
within each 105 permutation group within the entire permutation set.
As you said, my process also shows some redundancy. This is inherent
in this process. But it does add entropy over the entire permutation
set. You can quantify the entropy. You know exactly where you
stand.
When you randomly run processes and input random data in each process
you can calculate what the output entropy is. And each process
increases the entopy over the entire permutation set.
At first glance you may not be too impressed with the above 105
permutations. Keep in mind that since you are randomly running each
process it is unlikely that you will run the Mix a Mixfile process 10
times in a row. But when you do run it it will add the usual entropy
to the output file. And it makes a big difference in what sequence
or order you run the processes in.
And keeping in mind how the permutations transform each other and
index or reference each other to generate random digit output you
will realize that the cumulative entropy and inherent inefficiency
designed into OAP-L3 will result in very good random number
distributions. There are utility programs that come with OAP-L3
that allow you to quantify the random number output distribution.
The random output numbers are excellent.
No single process was designed to randomly shuffle the entire
permutation set. Each was designed to add a modest amount of
entropy. And in combination all the processes were designed to at
least effectively reach enough of the possible key space to make
OAP-L3 practicably unbreakable: quite so.
Now keep in mind that this is just the first half of the overall
process. Once you use three thoroughly and randomly shuffled
MixFiles to generate random digits and only use about a random 70%
of these digit triplets you further thoroughly reprocess these
random number (000 - 255) files.
If you can even reasonably suggest any possibility of some sort of
flaw in the final OTP files generated, again, we would all like to
hear of it.
By the way, I wouldn't put it past JF to have made his post knowing
all along that his suggestion was bogus. He might just have wanted
to see if I was intelligent enough to see through it.
But in so doing he has heard from many of you, as well.
Cheers.
(Get a sense of humor.)
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
