Cryptography-Digest Digest #40, Volume #10 Fri, 13 Aug 99 14:13:04 EDT
Contents:
Re: Journal of huffman coding (SCOTT19U.ZIP_GUY)
Re: Please help a HS student with an independent study in crypto ("Douglas A. Gwyn")
Re: Future Cryptology (SCOTT19U.ZIP_GUY)
Re: NIST AES FInalists are.... (SCOTT19U.ZIP_GUY)
Triple DES (168bit) -- Triple DES (112bit) ("Frank Piepiorra")
Re: Please help a HS student with an independent study in crypto ("Jeff Moser")
Re: NIST AES FInalists are.... (Patrick Juola)
Re: NIST AES FInalists are.... (SCOTT19U.ZIP_GUY)
Re: Better combiner than PHT? ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Q. a hash of a hash ... (Anton Stiglic)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
decryption verification methods ("Matthew Bennett")
Re: Triple DES (168bit) -- Triple DES (112bit) (fungus)
Re: Triple DES (168bit) -- Triple DES (112bit) (Padgett 0sirius)
Re: NIST AES FInalists are.... (SCOTT19U.ZIP_GUY)
Re: Digital simulation (Medical Electronics Lab)
Re: Q. a hash of a hash ... (Medical Electronics Lab)
Re: Triple DES (168bit) -- Triple DES (112bit) (Medical Electronics Lab)
Re: Depth of Two (John Savard)
Re: IEEE Computer: Staying with the Herd (John Savard)
Re: crypto survey (Medical Electronics Lab)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Journal of huffman coding
Date: Fri, 13 Aug 1999 15:59:30 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>
>Andras Erdei wrote:
>
>> [I'm crossposting it to sci.crypt as i don't know much
>> about cryptography -- hope the guys there can correct me
>> (and you).]
>>
>> [EMAIL PROTECTED] wrote:
>>
>> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>>
>> >> I have several examples at my site. But the big advantage
>> >> of adaptive huffman compression over stataic is that the
>> >> static is not as useful for encryption and for small files
>> >> the file is longer with static due to the fact the static
>> >> compression table has to be sent with the file. For example
>> >> my method will compress some files as short as 3 bytes to a
>> >> 2 byte replacement. Try that with static huffman.
>>
>> > Compression itself does not increase security.
>>
>> AFAIK it increases security by hiding the statistical
>> properties of the plaintext -- the compressed plaintext
>> usually has much higher entropy so it is much harder
>> to guess on parts of it (and check if the guess was right).
>
>Agreed, assuming that it does not have some form of overhead
>data/headers/characteristic pattern usable as a crib. Also in the case
>of known plaintext attacks, unless the compression is keyed in some way,
>the compression will change nothing.
The design to my version of the "adaptvie huffman compression" uses
no header of any kind. As a matter of fact any finite file can be
uncompressed to a file that when recompressed gets the same file
back. This is a KEY feature of any compression method that would
be used as a first pass to an encryption. Yet very little is written about
this topic.
>
>All compression really does for security is (on average) reduce the
>amount of data sent, thereby giving the Opponent less material to
>analyze -- a deffinite good thing, but not inherently security
>enhancing.
The compression method in question was not to replace
encryption as security but as a first pass to increase the
average entropy per bit of the message for low entropy
message as one commonly uses in short ascii messages.
It is well known that the use of high entropy messages
is inherently security enhancing.
>
>>
>>
>> > Adaptive methods also are bad since the 'dictionary'
>> > is based on the plaintext.
>>
>> AFAIK on the contrary; when using adaptive compression
>> for encryption purposes one usually starts with an initial
>> dictionary derived from an encryption key which is
>> impossible (?) with a static method without seriously
>> degrading the compression ratio and thus reducing the
>> benefits of compression. Also, with a static method it
>> is much easier to check whether guesses on parts of the
>> plaintext are right.
>>
>
>Such a keyed dynamic method will be less efficient on average, and will
>for longer files eventually converge to a dictionary close to that which
>would have been used in the case of an unkeyed dictionary. Agreed this
>CAN add security to the data, but an unkeyed method may actually yeild
>better results as less data will be sent. I would be inclined more to
>rely upon the encypherment algorithim to provide security, than the
>compression. I do however agree a dynamic compression, will yeild
>better results than a static algorithim, and therefore is better to use.
There are many added security benifts. If one thinks that Mr R of
RSA is correct in that an all or nothing form of encryption is better.
Then an "adaptive huffman compression" actually spreads the entropy
over the file better. The non error propagating modes of the normal
Cipher Chaining can be deated since it would be very hard to
synchronize the data again for the decompression program. I
aslo haeva less agressive huffman filter that can be use for the
reverse pass. See http:/members.xoom/ecil/compress.htm
>
>>
>> > The only benefit of compression is to make the messages
>> > shorter.
>>
>> Which is a great benefit: the less the data the harder to
>> break it; you can use more time consuming methods (larger
>> keys) because you have to en/decrypt less text, or on the
>> contrary (smaller keys in your OTP -- AFAIK that was the
>> cause of the initial interest in data compression).
>>
>> > That's all.
>>
>> Is that all?
>>
>> TIA
>>
>> Andras Erdei
>> [EMAIL PROTECTED]
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Please help a HS student with an independent study in crypto
Date: Fri, 13 Aug 1999 14:10:32 GMT
Jeff Moser wrote:
> subject. My main question to the group is this: are there any professors,
> students of crypto classes, other enthusiasts, etc, who could help me in
> forming an itinerary of important things that I should focus on in the time
> I have during the year?
It's perhaps a bit too "streamlined" (abstract) for a HS student, but as
a
source of important topics and practical examples, I'd recommend the NSA
Technical Literature Series Monograph No. 25, "Number Theory for
Cryptology:
A Textbook for MA-550" (3rd Edition, January 1991). I'm not sure how
you
can get hold of it; perhaps get a math teacher to ask the National
Cryptologic School for a copy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Future Cryptology
Date: Fri, 13 Aug 1999 16:16:49 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>David A Molnar wrote:
>
>> With all due respect, the reports on Echelon suggest that "they" are out
>> to get all of us, with some minimal level of effort. I'd want to know more
>> about just what you're handing in your white hat hacking before
>> speculating fruitlessly on just how much more effort the NSA is expending
>> on you. :->
>
>....
>
>> Seen any strange vans on your kerb lately ?
>
>Funny you should ask that...there was a Bellsouth van sitting across my street
> a
>few weeks ago. It sat their for 2 days. I was freaking out...but then I found
>out there was no one in it, it just broke down. (Too bad I didn't raid it.
> =)
>
I am not sure if this is BS but I saw a BellSouth van sitting in my parking
lot for a few days. Small world isn't it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 16:12:15 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> How convenient for you that the rules allow you
>> to flaunt how much you know on Usenet and to
>> belittle the skill of respected cryptologists ...
>
>I'm not flaunting anything, just trying to be helpful
>in advancing the public state of cryptology compatibly
>with my obligation to protect legitimate national
>interests. My personal agenda is to ensure as soon as
>possible that everybody can have adequate protection
>for the privacy of their communications. It's not my
>fault if you think the state of the art is defined by
>academics rather than by actual practitioners. Other
>posters have shown a better understanding of this issue.
When you state something that disagrees with the false
crypto gods expect a tongue lashing. They live in there on
bubble of self inflated ego. That is why the germans and
japanese felt so secure. They had assholes let could wirte
pretty prose and pat them selves on the back as to how smart
they are. But they rather never cared about the black art of
actual encryption and never will. Again I state they do not
care about advancing the art of encryption. They truely are
foolish enough to belive that academics as defined by them
are on the cutting edge. It is because of people with small
brains that think one should design for as small a key as
practiacal that they get a false sense of security. It does
not take to much logic to see that a large key system
based on some very simple S-boxes is vastly superior
to there small keyed crap. But since it so so easy to study
it is not very apealing to there way of thinking so they will
contunue to deisgn small insecure systems so the NSA
can continuie to read there mail.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Frank Piepiorra" <[EMAIL PROTECTED]>
Subject: Triple DES (168bit) -- Triple DES (112bit)
Date: Fri, 13 Aug 1999 11:38:27 -0400
Several publications refer to Triple DES with the key size 168 bit or 112
bit. Both seems to have Triple DES but what in detail, besides the key
length :-) is the difference and does it have an impact on security?
Frank
------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: Re: Please help a HS student with an independent study in crypto
Date: Fri, 13 Aug 1999 10:52:10 -0500
> It's perhaps a bit too "streamlined" (abstract) for a HS student, but as
> a
> source of important topics and practical examples, I'd recommend the NSA
> Technical Literature Series Monograph No. 25, "Number Theory for
> Cryptology:
> A Textbook for MA-550" (3rd Edition, January 1991). I'm not sure how
> you
> can get hold of it; perhaps get a math teacher to ask the National
> Cryptologic School for a copy.
Thanks for the reply!
I noticed that your email address is at the arl.mil in MD too. Would you
happen to know if the NSA has a list of non-classified publications of
things such as the textbook you mentioned?
Thanks again,
Jeff Moser
(my email server is having problems today, so if possible reply to the
group)
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: NIST AES FInalists are....
Date: 13 Aug 1999 11:51:55 -0400
In article <7p1ckg$2vbm$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> When you state something that disagrees with the false
>crypto gods expect a tongue lashing. They live in there on
>bubble of self inflated ego. That is why the germans and
>japanese felt so secure. They had assholes let could wirte
>pretty prose and pat them selves on the back as to how smart
>they are. But they rather never cared about the black art of
>actual encryption and never will. Again I state they do not
>care about advancing the art of encryption. They truely are
>foolish enough to belive that academics as defined by them
>are on the cutting edge.
.... as opposed to, for example, cryptography as practiced by
amateurs who don't perform the amount of analysis required of
academic cryptography. Yes, that makes sense -- academic
standards are too lax, so let's abandon standards altogether.
After all, anything designed and tested by academics is obviously
trivial for the evil spirits of Ft. Meade to read. Something
cobbled together in a basement, by constrast, is -- nay, MUST BE --
impenetrable by virtue of the author's ex officio moral superiority.
And thus doesn't require testing or analysis, or even a readable
design.
-kitten
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 18:07:36 GMT
In article <[EMAIL PROTECTED]>, "Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>>
>> You don't have to be a member of the NSA to write good crypto
>> algorithms. Look at DES, CAST, RC5 and Blowfish. I think a fair level
>> of 'trust' has to be put into the AES designers.
>
>What I am worried about, is that some of the AES designers *ARE* members
>of the NSA. That would be smart.
>
This wories me also. But it would worry me more if the NSA was to dumb
not to be secrectly invovled and getting the Trojan horse candidate in. IF
there is no secret NSA entry in the remaining contenders then we tax payers
are not getting our moneys worth.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Better combiner than PHT?
Date: Fri, 13 Aug 1999 16:12:16 GMT
<snip>
Yet another simple mixing function. This one does not promote
diffusion but does mix two words.
It mixes 2 n-bit words with a n bit key
A' = (a and K) or (b and_not K)
B' = (b and K) or (a and_not K)
This has the effect of swaping bits between 'a' and 'b' using the 'key'
K. It was used in ICE, Loki and DES (crypt (3)).
It's usefull to destroy 'characteristics' that are word dependant
(depends on which word they are in). The best way to model would be
with differentials ...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 16:14:54 GMT
In article <7ouirq$e08$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:
> > First of all no real secure system would get past the AES
entries. IF it is
> >not written in there special format.
>
> "There [sic] special format" being PostScript, of course....
>
> The rest of this ignorant rant deleted.
That about sums it up...
btw what does 'sic' mean anyways? IJWTK.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Q. a hash of a hash ...
Date: Fri, 13 Aug 1999 12:09:19 -0400
Say I have a hash algorithm H (I'm in fact using SHA_1),
is using H(H(x)) as secure as using H(x), do the same properties
for H stant for H of H ?
Thanks in advance for inputs!
Anton
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 17:13:08 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Sure, but there's no reason to make it any easier for them now, is
there?
> A sturdy envelope is always better than a postcard after all.
This is true, but it's not hard to open an envelope.
> Besides, I'd be happier anyway if e-mail and other electronic traffic
> had the same kind of legislative protection afforderd to my Snail
Mail.
Well for email the biggest problem is whatever law your federal
legistlation passes will not effect me. We are said to be non-local.
For the most part you have to take security into your own hands.
Exchanging PGP keys physically (then publishing) is probably the
easiest way to send mail securely to the intended people. I would
rather not see crypto become law because it's too new to trust. What
would be a legal RSA key? 1024 bits? 4096 bits? What happends when a
new algorithm comes out are these keys 'illegal'? What happends if a
cipher which is not 'legal' is used? What happends if this cipher is
broken? What happens if you are key is compromised ... This causes too
many problems. These laws are also usually inforced by people without
the slightest clue (read: Clinton Admin). Personally I trust the PGP
group to get their part of the crypto right, and I trust myself to use
my keys properly. Simple as that.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Matthew Bennett" <[EMAIL PROTECTED]>
Subject: decryption verification methods
Date: Fri, 13 Aug 1999 18:22:06 +0100
Reply-To: "Matthew Bennett" <[EMAIL PROTECTED]>
Other than simply encrypting a check phrase into the file and checking it
upon decryption, how would you rate these three other verification methods:
1) Write a random block of 8 bytes to a file followed by another duplicate 8
bytes, then encrypt. Upon decryption, check the first 8 bytes matches the
second 8 bytes.
2) Hash the first 32 bytes of the file, encrypt the whole file, store the
original hash value at the beginning. Upon decryption, hash the same 32
bytes and check the number produced matches the original value.
3) Like method 1, but sandwich a small part of the data file between the two
8-byte blocks.
I'll be using Blowfish in CFB mode for the encryption, and SHA-1 as the hash
function.
In particular is there an increased security risk if, say, someone knew that
the first 8 bytes matched the next 8 bytes? Does anyone know of a better
verification method?
/\/\/\//
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Fri, 13 Aug 1999 16:55:15 -0100
Frank Piepiorra wrote:
>
> Several publications refer to Triple DES with the key size 168 bit or 112
> bit. Both seems to have Triple DES but what in detail, besides the key
> length :-) is the difference and does it have an impact on security?
>
Triple DES is DES applied three times, there are two ways to do this:
1) Use three different keys, A, B and C. Encrypt the message three
times, once with each key.
Total key size 168 bits.
2) Use two different keys, A and B. Encrypt the message with key A,
decrypt it with Key B, encrypt it again with key A.
Total key size 112 bits.
This method was used to make triple DES chips compatible with
single-DES systems - if you make key A and B the same then you
get single-DES...
168 bits can't give you less security than 112 bits, though under
certain circumstances it doesn't give you much more (in the case
of 3DES...)
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Padgett 0sirius)
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Fri, 13 Aug 1999 12:01:01
>Several publications refer to Triple DES with the key size 168 bit or 112
>bit. Both seems to have Triple DES but what in detail, besides the key
>length :-) is the difference and does it have an impact on security?
>Frank
Some feel that the algorithm used does not gain in strength over 112 bits
k1e(k2d(k1e))) rather than k3e(k2d(k1e))). Personally, I suspect that 112
bits is "enough" for the near future & is now permitted in France.
A. Padgett Peterson, P.E. Cybernetic Psychophysicist
http://www.freivald.org/~padgett/index.html
to avoid antispam use mailto:[EMAIL PROTECTED] PGP 6.0 Public Key Available
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST AES FInalists are....
Date: Fri, 13 Aug 1999 18:17:18 GMT
In article <7p1eur$hag$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>In article <7p1ckg$2vbm$[EMAIL PROTECTED]>,
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>> When you state something that disagrees with the false
>>crypto gods expect a tongue lashing. They live in there on
>>bubble of self inflated ego. That is why the germans and
>>japanese felt so secure. They had assholes let could wirte
>>pretty prose and pat them selves on the back as to how smart
>>they are. But they rather never cared about the black art of
>>actual encryption and never will. Again I state they do not
>>care about advancing the art of encryption. They truely are
>>foolish enough to belive that academics as defined by them
>>are on the cutting edge.
>
>..... as opposed to, for example, cryptography as practiced by
>amateurs who don't perform the amount of analysis required of
>academic cryptography. Yes, that makes sense -- academic
>standards are too lax, so let's abandon standards altogether.
>
>After all, anything designed and tested by academics is obviously
>trivial for the evil spirits of Ft. Meade to read. Something
>cobbled together in a basement, by constrast, is -- nay, MUST BE --
>impenetrable by virtue of the author's ex officio moral superiority.
>
>And thus doesn't require testing or analysis, or even a readable
>design.
>
> -kitten
Mr Pussy Cat
I am sure that the so called acadmeic types could design a better
secure method if I tried to play be there rules. That is some weak
short keyed block encryption method using the phony blessed out
of date chainning methods that should have died when the computer
was invented.
And they may even be able to write a better long key program than
what I have. But that is not there goal. They are fooled into thinking
that there fast short key methods are vastly superior due to the time
it would take for a brute force crack. This is the same phony crap the
germans used to justify the security of various forms of Enigma. Except
the the "true key lenght" of some the there systems was longer than
what the AES contest is albout. It seems like we are encapble of learning
from history. My god the key sizes are smaller than what the germans
used in some of there systems. Have we learned nothing.
Encryption time wise should push the envovlope of the machine it
runs on. That is if you want secure encrption. If you want toy
ciphers use AES.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Digital simulation
Date: Fri, 13 Aug 1999 12:32:59 -0500
Christy Fulcher wrote:
>
> Im am looking for a way to simulate an encryption algorithm in
> Electronic Workbench
> (or similar), for a project in electronics. My knowledge so far consists
> of simple
> circuits like and, not, xor etc. Could anyone help me in suggesting an
> algorithm that can
> be implemented using these tools.
>
> Any help would be much appreciated.
The simplest thing for this kind of project is an LFSR and XOR
with plain text. Look up "stream ciphers", there are a great
number of combinations of shift registers and xor's that make
something fun to do.
Don't expect it to be secure, but it will be a good learning
project.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Q. a hash of a hash ...
Date: Fri, 13 Aug 1999 12:21:16 -0500
Anton Stiglic wrote:
>
> Say I have a hash algorithm H (I'm in fact using SHA_1),
> is using H(H(x)) as secure as using H(x), do the same properties
> for H stant for H of H ?
>
> Thanks in advance for inputs!
Assume x is the same size as H(x). If this is not a valid
assumption then use y = H(x) and perform H(H(y)).
Suppose you do H(H(H(....)))) for many cycles and different
inputs. You'll find that you get into a loop, and some of the
different inputs are just different points in the cycle.
There will probably not be some input which has only 2 points on
the cycle, but there are certainly going to be some cycles which
are shorter than others. So doing H(H(x)) actually reduces
your security because your giving an attacker information about
the cycle.
I guess I'd like to see a mathematical analysis, but my gut
level feeling is that it does not have the same properties.
You can easily break the cycles using H(H(x)||g) where g is
some random garbage.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Triple DES (168bit) -- Triple DES (112bit)
Date: Fri, 13 Aug 1999 12:39:32 -0500
Frank Piepiorra wrote:
>
> Several publications refer to Triple DES with the key size 168 bit or 112
> bit. Both seems to have Triple DES but what in detail, besides the key
> length :-) is the difference and does it have an impact on security?
Use 3 keys: E(k3,D(k2,E(k1,message))) == 168 bit key
Use 2 keys: E(k1,D(k2,E(k1,message))) == 112 bit key
Both methods are reported to have the same strength, 112 bits.
This is from the "meet in the middle" attack (I think).
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Depth of Two
Date: Fri, 13 Aug 1999 17:47:19 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>The example messages use reciprocal alphabets
as stated in the excerpt
>and have a period of 4,
Shh! At least I wasn't spoiled: I found that out over the lunch hour
yesterday...
>as can be determined from the patent repeats. Solution involves
>chaining and an observation about chaining of reciprocal alphabets.
You mean...
(spoiler warning)
If we hypothesize that Q of reciprocal alphabet 1 and t of reciprocal
alphabet 2 both become plaintext E, then E of reciprocal alphabet 1
must become plaintext Q and e of reciprocal alphabet 2 must become
plaintext T.
If plaintext T occurs often enough that we have seen e of reciprocal
alphabet 2, then in a case like the example, we also have the
equivalent of the same plaintext letter (since we have two identical
messages) in reciprocal alphabet 1, and so we can keep going and
going. (Depending on how complete our alphabets are, at least: so we
can test a hypothetical plaintext equivalent by continuing on until we
come to a contradiction.)
>In case it isn't well known, Enigma and Hagelin alphabets are both
>reciprocal.
Quite correct. I wasted some time trying a period of 26, thinking the
example might have been a simulated Enigma...then I noticed the large
repeat, and estimated a period of 16, which I revised to 8 and then 4.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: IEEE Computer: Staying with the Herd
Date: Fri, 13 Aug 1999 18:01:12 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>Because of my current situation I am probably not going to be able to
>participate in a discussion, but the article (actually, a guest
>column) is published whether I am ready or not.
Of course, these issues were discussed at great length in a thread
some time back.
I think both sides have valid points, and thus I agree that multiple
layers of encryption - when handled properly - are a useful measure.
Although the fact that an algorithm has recieved a large amount of
attention and study from the most respected academic researchers does
not _prove_ that a weakness in it won't be discovered in the near
future,
it is also valid to say that such an algorithm has survived a
winnowing process that many new, unknown, unexamined algorithms are
likely not to get as far in.
On the other hand, a large quantity of different algorithms can create
a large amount of required effort for an attacker, and for that one
has to make use of algorithms that are less well tried.
Addressing both threats by using algorithms from both sides, under
safeguards (message expansion not allowed by the algorithms themselves
- a separate and "trusted" method produces IVs and/or session keys -
keys for each algorithm are effectively independent, due to being
produced by distinct hashes) that prevent one algorithm's weakness
from undermining another one's strength is a sensible and cautious way
to go.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: crypto survey
Date: Fri, 13 Aug 1999 12:53:10 -0500
[EMAIL PROTECTED] wrote:
>
> Simple question: Who is your enemy?
Every government that exists :-)
Patience, persistence, truth,
Dr. mike
------------------------------
** 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
******************************
