Cryptography-Digest Digest #61, Volume #10 Mon, 16 Aug 99 22:13:03 EDT
Contents:
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... (SCOTT19U.ZIP_GUY)
Re: NIST AES FInalists are.... (JPeschel)
Re: crypto survey ([EMAIL PROTECTED])
Re: compress then encrypt? (Paul Koning)
Re: NIST AES FInalists are.... (John Savard)
Re: crypto survey (John Savard)
Re: rsa in other fields (Robert Scott)
Re: Statistical occurrence of letters in english (JPeschel)
Re: Implementing Rijndael's S-box (D. J. Bernstein)
Re: Blowfish algorithm - Is it foolproof? ("Tom Leylan")
Re: NIST AES FInalists are.... (SCOTT19U.ZIP_GUY)
Re: How good is this quadratic sieve variation? (D. J. Bernstein)
Re: Future Cryptology (wtshaw)
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
Re: Digital simulation (Wim Lewis)
Re: Prime numbers wanted (Josh Rubin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 21:12:51 GMT
In article <7p6pud$1u4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Well, I see your point, but as network speeds increase, in the future
> obtaining 2^36 blocks may not be so unthinkable as you imagine.
My point is that a protocol should not encrypt billions of blocks with
the same key, no matter how fast the connection and no matter how
trusted the symmetric cipher. Ever so often a new session key can be
negotiated or, even simpler, a new key can be computed as a function of
the old key and plaintext. (I have written programs where a different
key is used for each block.)
>I'd claim that if your cipher allows for 2^20 wirings, that should
>probably be viewed as 2^20 ciphers which must all be validated. Unless
>you do something clever, analyzing a set of 2^20 wirings will always be
>harder than analyzing one wiring. Given the tight AES timeline, the
>limited cryptanalytic resources, and the unknown competence of the
>academic world at designing very high assurance block ciphers, it might
>not be a good idea to add to the evaluation burden in this way.
As you know, Frog allows for as many different wirings as there are
keys, for example 2^128 wirings for a 128 bit key. The whole point is
that it should be very difficult to analyze them all. I know this goes
against the accepted wisdom that equates a cipher's strength with the
quality of its analysis, but it is a fact that the cost of breaking a
cipher includes the cost of analysing it. If we had a cipher where the
cost of analysis is demonstrably intractable then, arguably, this
cipher would be strong.
> Keyed wiring may reduce the risk of a catastrophic compromise, but it
> also seems to increase the cost of evaluation and validation. It's a
> tradeoff, IMHO.
:) Why do you say "catastrophic compromise" and not "catastrophic
failure"?
Maybe the best is to combine both worlds: mix in a cipher parts that
have fixed wiring polished against known attacks, with wiring that is
keyed.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 22:56:54 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>[EMAIL PROTECTED] (Patrick Juola) wrote, in part:
>
>>.... 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.
>
>While that is a very valid point, it is also true that many academic
>designs do seem to be designed for maximum speed and maximum
>simplicity.
>
>This is all very well for establishing the basic validity of a design.
>
>But if one is at all serious about security, while one does wish to
>use a sound design based on principles that have been studied by the
>experts, one will also have a burning desire to throw in larger
>S-boxes, key dependent S-boxes, extra rounds, and constructs which
>involve complexities that make analysis virtually impossible.
>
>Can one get away with doing that without an excessive risk of losing
>security entirely, by going with an unsound design? I think one can -
>if one knows a few basic general principles, and is cautious in the
>way one steps away from the well-trodden mainstream.
>
>Thus, I have been so bold as to present for examination my designs -
>and not only are they readable, they even come with nice explanatory
>diagrams - but I haven't implemented them in any C code just yet -
Well I agree a good solid key dependend S-box is the way to go.
If I may be so bold to say My writting may be crap but I have my
stuff in C that complies under DJGPP its all FREE and it works.
and is implemented.
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] (JPeschel)
Subject: Re: NIST AES FInalists are....
Date: 16 Aug 1999 22:14:06 GMT
>[EMAIL PROTECTED] (John Savard) writes:
>In this particular case: from his non-fiction writings, it appears
>that although Tom Clancy communicates extensively with the public, he
>has, in the course of his research, been permitted to learn a few
>things he is not at liberty to fully repeat.
I suppose he has, but just about every working journalist has been
asked not to repeat a few things he's learned.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: crypto survey
Date: Mon, 16 Aug 1999 22:18:19 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Simple question: Who is your enemy?
>
> Every government that exists :-)
I hope this is meant as a joke. After all, governments only reflect the
people they govern. There are people who view their government as an
enemy and there are people in government who view the people as their
enemy, or at least as their opponent. Both attitudes are not serious.
I would say my enemy is inefficiency. Cryptography has a great
potential for making the world a more efficient place - and therefore a
more just place. For example, the generalized used of cryptography
would give people an effective means for controlling their intellectual
property. If we agree that in the future most labor and most wealth
will be intellectual, then cryptography will make it more difficult to
exploit others. An economy that is free to private iniciative but also
free of exploitation is more efficient and stable.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: compress then encrypt?
Date: Mon, 16 Aug 1999 17:52:43 -0400
Tom St Denis wrote:
>
> Ok other then
>
> 1. Making the message smaller
> 2. Making the plaintext harder to guess (but not impossible with
> several adjacent blocks).
>
> What are the clear benefits of compression before encryption?
There's another way of looking at item 1:
If you send cleartext over a dialup link, your modem will compress
it for you and you typically get quite a lot more than the nominal
33 or 56 or whatever kbps. (JPG and ZIP files and the like excepted,
of course.)
If you turn on crypto, your performance will drop, of course.
Compression before encryption will let you recover most of what
you lost.
paul
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST AES FInalists are....
Date: Mon, 16 Aug 1999 22:57:03 GMT
[EMAIL PROTECTED] (David Wagner) wrote, in part:
>Right. But, remember the lesson of RDES. Randomized wirings can really
>destroy a design if you're not careful.
>(RDES was a DES variant that decided whether to do the swap or not after
>each round based on another key bit. I think the idea was to extend the
>key length of DES. In any case, Biham & Shamir showed that the result is
>very much less secure than DES against differential cryptanalysis, for
>almost all of the keys.)
Yes, I do recall RDES. And that didn't work specifically because the
stages were related.
If one left pairs of DES rounds alone, and randomly shifted the 64-bit
block left 16 bits half the time after the even rounds only, one would
not have the same degree of vulnerability.
I absolutely agree, one must be careful. And that is why I'm concerned
with looking into how one can be careful.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: crypto survey
Date: Mon, 16 Aug 1999 23:27:36 GMT
[EMAIL PROTECTED] wrote, in part:
>Simple question: Who is your enemy?
A hacker 50 years from now, who happens to have intercepted E-mails
lying around from 50 years ago which he is going to crack on his new,
fast computer.
Otherwise, I'd have no need to use the NSA as a measuring rod.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Robert Scott)
Subject: Re: rsa in other fields
Reply-To: [EMAIL PROTECTED]
Date: Mon, 16 Aug 1999 23:56:17 GMT
On Mon, 16 Aug 1999 16:20:25 -0400, Anton Stiglic <[EMAIL PROTECTED]>
wrote:
>Any cryptosystem working in a finite cyclic group Z_pq can
>be viewed as working in a finite field F_pq.
I'm not sure what you mean by F_pq, but there is no field of
order pq. Finite fields can only have an order which is
a power of a prime.
Bob Scott
Ann Arbor, Michigan (email: rscott (at) wwnet (dot) net )
(My automatic return address is intentionally invalid.)
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Statistical occurrence of letters in english
Date: 16 Aug 1999 23:25:14 GMT
>Roger Carbol <[EMAIL PROTECTED]> writes:
>In most cases, you're better off building your own statistics
>based on samples of the text you're trying to attack. If you're
>attacking emails, you could expect to see many more "@" than
>in the average Shakespeare play.
I would take note of a sea of spaces, and after counting them,
decrypt them, to wonder, to query no more.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: sci.crypt.research
Subject: Re: Implementing Rijndael's S-box
Date: 16 Aug 1999 23:49:42 -0000
Paul Crowley <[EMAIL PROTECTED]> wrote:
> very variable time depending on input
One way to avoid this is to compute the inverse as the 254th power, with
two-way table lookups replacing branches, or four-way table lookups
replacing pairs of branches:
const uint8 save[11] = { 2, 0, 1, 2, 0, 0, 2, 0, 0, 0, 0 };
const uint8 star[11] = { 0, 0, 2, 2, 0, 2, 2, 0, 2, 0, 1 };
const uint8 bit89[4] = { 0, 27, 54, 45 };
uint8 a89[4];
uint8 chain[3];
uint8 inverse(uint8 a)
{
uint8 b;
int i, j;
a89[0] = 0;
chain[0] = a;
for (i = 0;i < 11;++i) {
chain[save[i]] = a;
b = (a << 1) ^ bit89[a >> 7];
a89[1] = a;
a89[2] = b;
a89[3] = b ^ a;
b = chain[star[i]];
a = a89[b >> 6];
for (j = 3;j > 0;--j) {
b <<= 2;
a = (a << 2) ^ bit89[a >> 6] ^ a89[b >> 6];
}
}
return a;
}
The compiled code should be under 150 bytes on an 8-bit CPU with
constant shift instructions.
Anyway, I don't understand why NIST is worrying about the suitability
of AES for tinkertoys. Surely AES will be used in sufficient volume to
justify building dedicated circuits for it.
---Dan
------------------------------
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: Mon, 16 Aug 1999 20:23:20 -0400
Pradeep,
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.
Thanks,
Tom
Pradeep Rathi <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi!
>
> I'm using the blowfish algorithm, written in perl, to encrypt a NUMERIC
> INTEGER VALUE. My concern is if I mess around with the encrypted
> information and then try to decrypt it, is there a possibility of another
> numeric value being returned. To illustarte,
>
> 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.
>
> An assumpiton: I know nothing about the KEY that was used to encrypt or
> decrypt the information. All I've is two functions encrypt() & decrypt()
> that I can use.
>
> I would appreciate any comments.
>
> Thanks,
>
> Pradeep
>
>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST AES FInalists are....
Date: Tue, 17 Aug 1999 02:40:03 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>
>>And please don't talk vaguely about "back doors" -- while
>>they are possible in some circumstances, for an open system
>>like the AES it is not at all evident that it is possible.
>
>I quite agree. It is not at all evident that a publicly described
>algorithm can be weak in some well-hidden manner.
>
>I suppose, though, that before anyone had known about differential
>cryptanalysis, LUCIFER would have seemed impressive. But hiding a
>trapdoor that way - design a cipher to be weak against an advanced
>attack not publicly known yet - risks backfiring. After all, it was
>public interest in DES that led to the open discovery of differential
>cryptanalysis.
>
>Part of the trouble, though, is just as I can't prove designing an
>algorithm to be defective in some strange fashion is possible
>(although there is enough concern that it _might_ be that people
>proposing block cipher algorithms generally don't include S-boxes
>without an explanation of their derivation) neither can I provide a
>convincing demonstration that it isn't.
>
But with this beautiful AES contest they can have it both ways.
They can design some fishy method of encryption that is weak
against attacks that only they know of. Then 15 years from now
when the method smells in public. They can say they had nothing
to do with the selection. So thet take zero risk.
This to me seems to be how the NSA wants to take control
of all communications. Do you really think with the law enforcement
fear of people being able to talk freely that the government would
actaully run a nonrigged contest to make good crypto for everyone.
When some one says ther here from the govenment to help you
watch out.
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] (D. J. Bernstein)
Subject: Re: How good is this quadratic sieve variation?
Date: 17 Aug 1999 00:32:55 GMT
David Harden <[EMAIL PROTECTED]> wrote:
> Suppose that you collect expressions of the form n=a+b, where a and b
> are both smooth, so that a==-b (mod n) and -a*b^(-1)==1 (mod n).
This is the ``rational sieve,'' an elementary example of the number
field sieve. The run time of the rational sieve is roughly the 1.414
power of the run time of the quadratic sieve.
---Dan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Future Cryptology
Date: Mon, 16 Aug 1999 19:54:24 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > There actuall charter is classifed
>
> No, it isn't.
>
> > The total amount of there resources is classifed
>
> Not long ago I posted a very close estimate,
> but that's not my only source of information on the resources.
That's the line, but accountability requirements may be met on the surface
in rather creative ways.
In short, how do you trust someone or something known to rationalize the
worst things possible. Knowing that they are telling the truth is like
knowing the strength of an algorithm; without transparency, we simply
don't know, can't reliably prove much, and never will, since transparency
is reasonably an unobtainable. I would like to trust, but trust whom?
As in other things reputation is everything, and they don't have a good
one in these areas.
--
All's fair in love, war, and crypto. ERACE
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Tue, 17 Aug 1999 02:27:47 GMT
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
...
>
>For a weak cipher it doesn't help too much not to use a checksum: If it is
>neccessary to be able to check the integrity of the file wrapped PCBC
>doesn't help and there has to be some additional check. In the other case
>the attacker will be able to see whether he produced garbage or not.
>
I think a CRC or passpharse checker as in PGP is a bad idea. IF the
the idea is to make it as hard as possible to break you should leave no
hooks for an attacker to look at. IF you want a checksum or what ever
as a first test to see if file ok add it after the encryption like when you
ZIP a file.
...
>This is why the AES candidates use more rounds than neccessary, why MARS
>uses unkeyed rounds and so on.
It is your not that they really use more rounds than needed. IT is just
that they add more rounds than what seems to be best open literature
attack. Nothing to say a few years from know they could be weak. THere
strength is not based on information theroy ideas.
>
>Do you really think your cipher could be strong only because you are using
>an unusual design?
>
>Why do you think, NSA wouldn't be able to break a cipher that was
>developed without any cryptanalytic knowledge?
The problem with most designs is it is possilbe to undue or analyze since
they are made of simple operations or functions. However if one thinks about
it most operations can be undone. About the only thing in theory that can not
be is a random S-table. Yes it would be hard to desing a 64 or 128 bit S-table
becasue the keys get so large so fast. But if one could have a random S-table
for a 128 bit block then all the AES candidates are nothing more than a subset
of this super method. So I am trying to use the largest possssible S-table
that can easily run on a machine and still have a key that could fit on a
floppy that is currently 19 bits. History has shown us key size alone is not
everything. The Enigma in certain forms had a very large key much
larger than the AES candidates so one should strive for as large a block
size.
Well my block size is the whole file. This is where I am coming from
large keys large S-tables and the file or unit underconsideration should
be the whole block. The next thing of conseideration is how to weave these
blocks together. I like the shift and W-PCBC concept but there may be stronger
also if one is worried about chosen plain text or slide attack schemes one
should add a front and back round that is different to break these up.
Look I may not have the best. But I am sure the best treats a whole file
as a block and uses the largest S-table possible.
>
>> So the design should use the most amount of computer resourses for the
>> job that can be talerated while minimizing the possiblity of solutions.
>
>So you think your algorithm is secure because it is slow?
No but I think that a sercure algorithm is slow. In the since that
the less work you but into encrypting the easier it is to break.
That is not the same as saying just because it is slow it is secure
it is very easy to write a slow program that does nothing.
>
>3DES is better than blowfish because it needs more time to do it's job?
That is not what I am saying. But I am saying mine is better than blowfish
if you want to encrypt a file and keep it secret. Because the nature of the
S-block is such that there is no true fast way to do the encryption. Blowfish
does not treat the whole file as a block. If one wanted to use Blowfish in a
safeway you could use it with out the pre and post routines I have and use
it with W-PCBC and a different key for each wrapping. However I am not sure
people besides me knows how to do this. Since I made the term wrapped
PCBC up. However I would be willing to write a C soubroutine to do this.
The problem with "wrapped PCBC" is that it casuea a file rotation to occur
on each pass and the code has to be unwrapped in the reverse direction.
99% of the people here would only do several passes in one direction with
out the wrapping effect.
I would be willing to discuss this farther if your interested in tryin to do
"wrapped PCBC" with blowfish.
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] (Wim Lewis)
Subject: Re: Digital simulation
Date: Tue, 17 Aug 1999 00:52:13 +0000
In article <7p2390$hju$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Try a OTP.... hehehe...If you are serious I would try hardware oriented
>ciphers such as DES first.
>
>If you truly are into electronics you should note any cipher or program
>can be done with XOR/AND gates ...
Yah... first you design a CPU using logic gates, then you program it
to execute your algorithm ... ;-)
DES shouldn't be too hard to implement in hardware, especially if
EWB lets has a ROM component (for the S-boxes). ARC4 might not be too
hard either if you can build an 8-bit adder and an 8x256 bit memory.
--
Wim Lewis - [EMAIL PROTECTED], also hhhh.org - Seattle, WA, USA
------------------------------
From: [EMAIL PROTECTED] (Josh Rubin)
Subject: Re: Prime numbers wanted
Date: Sun, 15 Aug 1999 19:59:13 GMT
On Wed, 04 Aug 1999 02:01:02 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>Roger Carbol wrote:
>> 2) I don't have even an approximate idea of the density of
>> primes up around the 200 digit level.
>
>The distribution of primes goes all the way back to Legendre (1798).
>The number of primes < x is approximately L(x) = Integral from 2 to
>x of (dt / ln t), which can be expanded into a rapidly converging
>series by integration by parts. The dominant term is x / ln x, so
<snip>
A quibble: The expansion you describe for the Logarithmic integral
function, Li(x), does not converge for any value of x.
It is an asymptotic expansion.
That means that if you truncate the series, the sum is a good approx.
to Li(x) in the sense of relative error, once x is "large enough".
Josh Rubin
[EMAIL PROTECTED]
------------------------------
** 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
******************************
