Cryptography-Digest Digest #63, Volume #10 Tue, 17 Aug 99 06:13:03 EDT
Contents:
Re: E2 (DJohn37050)
Re: NIST AES FInalists are.... (wtshaw)
Re: Will CIA be an actor of end-times ? ("Douglas A. Gwyn")
Re: E2 (Hideo Shimizu)
Re: CRYPTO DESIGN MY VIEW ("Douglas A. Gwyn")
Re: Blowfish algorithm - Is it foolproof? ("Tom Leylan")
E2 ([EMAIL PROTECTED])
Re: Kana, was occurrence of letters in english
Re: Blowfish algorithm - Is it foolproof?
Re: Blowfish algorithm - Is it full proof? (David A Molnar)
Re: Blowfish algorithm - Is it foolproof? (Phil Barnett)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: NIST AES FInalists are.... (Volker Hetzer)
Re: Will CIA be an actor of end-times ? ("collomb")
Re: NIST AES FInalists are.... (Volker Hetzer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: E2
Date: 17 Aug 1999 04:12:23 GMT
I listed it as one of the 6 I wanted to see in this selection, along with the
others that were selected.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 21:08:31 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Matt Curtin <[EMAIL PROTECTED]> wrote, in part:
>
> >No matter how many Smart People NSA hires, there will be more Smart
> >People outside of NSA.
>
> But how many of them will be paid full time to work on cryptography?
>
How many of them are sufficiently dedicated to work full time on
cryptography even if not paid?
--
All's fair in love, war, and crypto. ERACE
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Will CIA be an actor of end-times ?
Date: Tue, 17 Aug 1999 04:21:31 GMT
Soeren Mors wrote:
> You might have noticed the sci. in the name of this newsgroup. Someone
> needs to do a lot more work to convince me that this decryption is the
> right one.
Where have you been? Kryptos was independently solved (except for
the last 97 characters) by three separate workers (one was a team),
and they all got the right answer, as verified by the sculptor.
The right answer is *nothing* like the mystical nonsense collomb
is espousing.
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: E2
Date: Tue, 17 Aug 1999 13:46:15 +0900
Hi
I just agree with you.
> high ROM requirement was in the Java implementation which was only
> used as a performance enhancing measure, correct? Were NIST's hands
I feel SUN's report is no good, because their implementation level
is not*flatten*.
Hideo Shimizu
TAO, Japan
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 17 Aug 1999 04:15:56 GMT
Okay, while our local network was down today I did a bit of research
in the tech library, and found that "arithmetic coding" seems to be
the compression method of choice. The basic idea seems to be to
dynamically repartition the code space so as to always minimize the
expected size of the *next* symbol; if you have a good model of the
population statistics, this method is supposed to achieve nearly
optimal compression (better than Huffman coding). There is supposed
to be a good tutorial in the Mar. 1984 IBM J. of Rsch. & Devel., and
it's described in some textbooks. The library closed before I could
find out more, but that should be enough to get you started.
http://www.cs.toronto.edu/~radford/ac.software.html contains pointers
to software for this and an associated article by Moffat et al.
------------------------------
Reply-To: "Tom Leylan" <[EMAIL PROTECTED]>
From: "Tom Leylan" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it foolproof?
Date: Tue, 17 Aug 1999 00:57:49 -0400
Eric Lee Green <[EMAIL PROTECTED]> wrote...
> For recognizing natural languages frequency analysis might be used, and
> if the result seems to indicate a natural language as vs. random
> garbage, a human being called in to verify this. As for your PKZIP, all
> PKZIP files have an easily-recognized header. I would imagine that any
> bogon out there interested in breaking your encryption has computers
> quite capable of recognizing all commonly-used compression headers.
This is good. It indicates that binary data is enough to make the task
"non-machine determinable" (it sounds like it _ought_ to be an encryption
concept) and as you recognized, a custom "zip" or masker would help
considerably. Each layer of course means transmitting even more information
about how to decrypt it to the intended recipient however. But it sounds
like every attempt at decryption must be "validated" to see if it worked.
> In any event, the easiest way to "break" a code is to steal the poor
> sod's private key. Second-best is to read over the guy's shoulder after
> he's already decrypted the message.
I figure paying the guy for the code is the surefire solution. It has
generally worked well in the past and it saves a large decryption effort.
Thanks... re: Pradeep's question however. I imagine a binary value can be
interpreted as an integer so even the encrypted value would look "okay" if
the number fell within some acceptable range of values (for whatever he was
using it for.) Does that sound right? I am totally guessing but it sounds
like he would have to encrypt a constant as a sentry value so that it could
be checked to see if the decryption actually happened.
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: E2
Date: 17 Aug 1999 04:02:03 GMT
Is anyone else disappointed that E2 was not chosen as an AES finalist?
I'm just curious because E2 (along w/Twofish) was one of my favorites.
I'm also puzzled by some of the things in the NIST report. AFAICT, the
high ROM requirement was in the Java implementation which was only
used as a performance enhancing measure, correct? Were NIST's hands
tied because of the code submitted?
It also seemed to me to be middle-of-the-pack in terms of security and
performance when compared to the chosen algorithms. Neither the worst
nor best in any area, even in the R1 report, though the smart card
concerns are somewhat valid.
I guess I'm just unhappy it was left out and am looking for some more
understanding as to why. *shrug*
--
Sent via USENET
Learn what you know. Share what you don't. -- [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Kana, was occurrence of letters in english
Date: 17 Aug 99 05:45:22 GMT
wtshaw ([EMAIL PROTECTED]) wrote:
: Speaking of Japanese, a general question, exactly how many Kana are needed
: and/or used? If not a long list, what are they? Can normal punctuation be
: used, period, comma, and period? Is the assumption that various numbers
: of Kana can be used for different words, separated by spaces, correct?
There are 46 symbols in the Kana syllabary, plus two marks that follow
some of the Kana, thereby changing the value of the consonant. As well,
nine of the Kana are used in a smaller-sized form to aid in writing
syllables that end in a consonant or for other purposes.
Normal punctuation is used in Japanese (and also in Chinese), except that
L-shaped symbols are used for quotation marks. Since spaces are not used
to separate words in normal Japanese writing (Chinese-character Kanji with
cursive Hiragana used for word endings) they are not always used in Kana
texts.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it foolproof?
Date: 17 Aug 99 05:47:51 GMT
Tom Leylan ([EMAIL PROTECTED]) wrote:
: Great... 3 answers none of which appear to be to the question you posted.
: Let me try and translate from English to English by asking a simple question
: of those that understand the Blowfish encryption algorithm.
: What "do you get" when you get an incorrect answer. Clearly Pradeep is
: asking NOT if the number he encrypted is secure from decryption but rather
: would a bogus decryption, i.e. one that was attempted and failed, return a
: number that for all intents and purposes "could" be correct. In other words
: if his function simply decrypts and he gets 67890 he is going to act on it
: not knowing it wasn't the original number. How would he know?
I thought that was exactly the question _I_ answered in my reply.
Blowfish couldn't contain inherent protection against that kind of
problem, because that would weaken it. If this kind of thing will be a
problem in your design, the thing to do is use error-checking methods on
your enciphered text.
John Savard
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: 17 Aug 1999 06:10:43 GMT
In sci.crypt Helger Lipmaa <[EMAIL PROTECTED]> wrote:
> Pradeep Rathi wrote:
>> 1. Encrypt 12345 and let's call the encrypted information 'A'.
>> 2. Manipulate 'A' and let's call that 'B'.
>> 3. Decrypt 'B'.
>> 4. Is there a possibility of 67890 being returned.
> Assuming that Blowfish is an ideal cipher, knowing that 12345 is a plaintext
> corresponding to A will not help anyhow to find a plaintext corresponding to
> any different ciphertext B. I.e., the problem is equal to brute forcing the
> cipher. Otherwise it would be a major weakness of Blowfish and you'd get
> famous by publishing your attack.
What if we're not aiming at the target plaintext 67890, but just want
*any* other plaintext than 12345 ? I agree that being able to pick the
resulting plaintext would be a huge weakness! Except it's not at all clear
to me why flipping bits in Blowfish (with the key staying the same)
wouldn't produce a valid ciphertext which decrypts to some garbage
plaintext...although the adversary wouldn't know which one.
At least, in ECB mode this seems to work -- although if we are expecting
integers of a certain type or range, maybe it would be caught. I guess
with a proper feedback mode the error would propagate and you'd notice
from context that something screwy happened. If you were just encrypting
random data with no way to recognize a correct answer (not realistic, I
know), then I don't know how you would tell bits had been flipped between
encryption and decryption.
this is why some schemes try to acheive non-malleability via "tags"
computed from the plaintext and sent along with the ciphertext, right? to
give some means of identifying a "proper" ciphertext even if the plaintext
has no recognizable structure?
thanks,
-David
P.S. non-malleability is important. think of bit commitment schemes. if an
adversary can corrupt a commitment in transit, such that it opens to a
different value than intended, then when Alice and Bob try to compare
values at opening time, they have no way of knowing that neither tried to
cheat the other.
"to the fairest" ?
------------------------------
From: [EMAIL PROTECTED] (Phil Barnett)
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it foolproof?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 17 Aug 1999 07:03:33 GMT
On Mon, 16 Aug 1999 20:23:20 -0400, "Tom Leylan" <[EMAIL PROTECTED]>
wrote:
>Great... 3 answers none of which appear to be to the question you posted.
>Let me try and translate from English to English by asking a simple question
>of those that understand the Blowfish encryption algorithm.
>What "do you get" when you get an incorrect answer. Clearly Pradeep is
>asking NOT if the number he encrypted is secure from decryption but rather
>would a bogus decryption, i.e. one that was attempted and failed, return a
>number that for all intents and purposes "could" be correct. In other words
>if his function simply decrypts and he gets 67890 he is going to act on it
>not knowing it wasn't the original number. How would he know?
>I can think of plenty of things I would like to know about Blowfish and
>other encryption algorithms but if nobody can understand the simple
>questions I'm not exactly sure what will happen when I ask the tough ones.
>I will try one, it is a variation of Pradeep's question. How does one know
>when you've got the answer? Particularly with regard to the well-publicized
>DES decryption contest. Would anybody have noticed they had figured it out
>if I simply used PKZIP on my original plaintext? If it relies on
>recognizing English it is quite easy to disguise that.
Checksum the input. Store the checksum at the end of the input.
Encrypt it.
After decryption, strip the checksum and recalculate the checksum on
what's left. If they match, it's likely the same. If you check sum it
twice or more with different prime numbers, you are more likely to
prove it's the same.
It's not the encryption technique's job to make sure the output is the
same as the input. Quite the opposite. If things don't go perfectly,
it's the encryption techniques job to insure that the output looks
nothing like the input.
--
Phil Barnett mailto:[EMAIL PROTECTED] <-- Remove the first .
Oasis WWW http://www.iag.net/~philb/
FTP Site ftp://ftp.iag.net/pub/clipper
Clipper FAQ http://www.iag.net/~philb/clipper.html
Harbour Project http://www.Harbour-Project.org
The game will never end. For the game is
life itself, and life is Who We Are.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 17 Aug 1999 09:58:19 +0200
SCOTT19U.ZIP_GUY wrote:
>
> >I don't see how you requirement can be realized. If you have a file
> >A compressed to B and the last symbol written to B consists of, say,
> >4 bits. If I delete the last bit of B to become C, then on
> >uncompressing C the software will find the last 3 bits of C that it
> >can't decode. So this 'wrong' file C obvioulsy will be determined
> >to be an invalid file. Or do I miss something?
>
> AS usual you don't understand and I am not sure that I can help you
> I don't want to go on forever with you like I have in the past.
> But TAKE A LOOK AT THE CODE. YOU HAVE THE PROGRAM.
> That said lets see if I can help. The files invovled are all wirtten
> in a whole number of bytes. So you can't delete "one bit".
It is only a matter of scale. If the constraint is that the file is to
be in whole numbers of bytes (indeed quite reasonable in practice),
I can consider the case where the last byte is deleted. Avoiding
also to discuss the end filling problem, let's assume that the last
symbol output has 9 bits and that the last bit is at byte boundary.
Now on uncompressing the program will find at the end of the 'wrong'
file one bit that it can't decode, there being 8 deleted bits
missing. (Isn't this a good example?)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 17 Aug 1999 10:09:06 +0200
Douglas A. Gwyn wrote:
>
> Okay, while our local network was down today I did a bit of research
> in the tech library, and found that "arithmetic coding" seems to be
> the compression method of choice. The basic idea seems to be to
> dynamically repartition the code space so as to always minimize the
> expected size of the *next* symbol; if you have a good model of the
> population statistics, this method is supposed to achieve nearly
> optimal compression (better than Huffman coding). There is supposed
I have only scanty knowledge about arithmetic coding. But I vaguely
remember that arithmetic coding, because it operates on real
numbers, could have some implementation difficulties if the real
numbers supported by hardware are not long enough. I hope experts
would comment whether this is true or false.
M. K. Shen
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Tue, 17 Aug 1999 10:42:10 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Volker Hetzer
><[EMAIL PROTECTED]> wrote:
>
> >> The only possible reason to use the same
> >> method for everyting is to limit the size of the program.
> >And to concentrate analysis on one algorithm.
> Yes leave the NSA just one small fast method to analyse.
> Why make it hard for them.
Less work to do plays in the hands of the guys with less manpower.
According to you, that's us, so an easy to analyze algorithm is good for us.
> >> All else aside it is
> >> highly unlikely that a low memory fast encryption program is good for all
> >> aplications.
> >Could you please give us examples where a high memory slow encryption program
> >would be advantageus?
> I think scott19u.zip is very good example of a high memoty slow encryption
> that has many advantagous. FIrst it is slow only because of the work it needs
> to do to encypt.
I certainly believe that you didn't add delay-loops. But recent examples
around here show that an algorithm does not need to be slow to be secure.
> Yes anything can be written slow. " If it takes very few
> machine cycles to use a small key to encrypt. Then it takes less time on the
> average for the NSA types to break." This is common sense.
But not applicable here. Complexity of the algorithm only adds a constant
factor to the breaking instead of the exponential security increase you get
by increasing keylength.
Furthermore, algorithms that are slow because of internal complexity are
those algorithms that profit most from specialised hardware (with lots
of pipelining inside). Since it's NSA's specialised hardware you fear
you should design an algorithm that is fast and simple. Then give it a big key
to make it slow.
This way specialised hardware will be of less use.
> I think simplicity should count a lot to. As in the simplitity of using
> a large random S-table. But not the simplicity of a low memory short
> key fast method. At least not for anything one wants to keep secure.
You don't need a lot of memory for a long key.
> Yes and rember the the red threaded cyrpto machines the swiss sound to
> various countries around the world. The NSA has a long arm does it not.
I was talking about IDEA. The big difference is that IDEA is published.
The internals of those machines were not.
Btw, by shying away from any sort of establishment (like known cryptographers
and yes, NSA designed ciphers) you seem to favour an amateur approach
to cryptography. Just have a look at M$'s security products to see the
result of that kind of method.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "collomb" <[EMAIL PROTECTED]>
Subject: Re: Will CIA be an actor of end-times ?
Date: 17 Aug 1999 08:51:54 GMT
Re- Will CIA be an actor of end-times�?
I specify that my solution to decipher Kryptos is completely logical
and < natural >.
The trick consists in making upon the start a geometrical form
by using the characters of the first series. This trick is suggested
by the square of Vigenere which, lets recall it, appears too
on the sculpture of the CIA. Then, all the demonstration is
based on the geometrical idea of the square, and that until the end,
when on the square 10X 10 appears: the 97 characters + GOD.
The second series must be treated along with the first, for they are bound
by the concomitant missing of the character O. The importance of the
missing character rises from the observation of the square of Vigenere,
for the characters of the word Kryptos are not repeated in the alphabet
of Vigenere reproduced on the sculpture.
Once started correctly, decoding continues in a < natural and logical >
way. It is natural to turn to the Bible when word GOG is discovered,
no matter what think about of, the senior cryptographers.
In my opinion, I am the only one to publish a complete solution on a
site web.
If I have good memory Jim Sanborn said somewhere he < loved > the
work of the 3 cryptographers, but he did not say: < that's it ! >
Gwyn writes:
> Kryptos was independently solved, except for the last 97 characters �
What would think of a cryptographer saying to the Chief of HQ :
Chief, all is deciphered, except a small sentence < the 97
characters � >. Unfortunately, these characters meant < attack tomorrow
at
dawn > That is enough to lose the war.
[EMAIL PROTECTED]
collomb <[EMAIL PROTECTED]> wrote in article
<01bee7ee$89560020$a3150f9a@collomb>...
> Will CIA be an actor of end-times�?
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Tue, 17 Aug 1999 10:52:25 +0200
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
> > You don't need a billion computers. The NSA can make custom chips
> > and put several processors in each die. Assuming this, they only
> > need a few million chips stuck to circuit boards with very minimal
> > support logic (maybe no support logic at all for such a specialised
> > chip). This is quite possible for them, think of large telephone
> > exchanges...
>
> Ok assuming you can get 1 billion chips working...
You don't need to get them ALL working.
With this kind of farm you can use timeouts and give the work to
those that are ok.
Using a hierarchical system of monitoring the chips, the requirements
of the communications network are minimal.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
** 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
******************************
