Cryptography-Digest Digest #99, Volume #10 Mon, 23 Aug 99 17:13:03 EDT
Contents:
Re: Clerification of Crypto Export Laws (John)
Re: CBC problems... (David A Molnar)
Re: How does RC4 work ? (Tom St Denis)
US export laws re Canada (dave)
Re: How does RC4 work ? (David A Molnar)
Re: IDEA in Applied Crypto (Stephan Eisvogel)
Re: question regarding number of keys possible. . . (John Savard)
Re: NIST AES FInalists are.... (David Wagner)
Re: Attacks on RC4 ? (Tom St Denis)
Re: NIST AES FInalists are.... (David Wagner)
Re: NIST AES FInalists are.... (David Wagner)
Re: Blowfish algorithm - Is it full proof? (Jim Dunnett)
Re: Human-Readable Encryption (Newbie) (Jim Dunnett)
Re: MUM (David Wagner)
Re: Cryptomathic Denamrk (Bob Silverman)
Re: I need strongest weak elliptic curve... (Greg)
Re: CBC problems... (Anton Stiglic)
Re: Unconcealed messages in RSA (Anton Stiglic)
Re: Human-Readable Encryption (Newbie) (John Savard)
----------------------------------------------------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: Clerification of Crypto Export Laws
Date: Mon, 23 Aug 1999 10:57:01 -0700
I will grant that scenario can occur. The truth is, if you
have connections, money, they'll leave you alone.
http://www.aasp.net/~speechfb
ps It would be hard to argue thatin court.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: CBC problems...
Date: 23 Aug 1999 18:25:45 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> Your not the only one to have asked stupid questions here! :)
seconded. Indeed, stupid questions sometimes lead to interesting pointers.
I am very thankful to the person who suggested looking at other methods
for generating provable primes after I mistakenly thought n! + 1 was
prime...
-David
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How does RC4 work ?
Date: Mon, 23 Aug 1999 18:52:34 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> "Georg Zetzsche" <[EMAIL PROTECTED]> writes:
> > Does anybody know, how the RC4 - encryption algorithm works ?
>
> It's AFAIK the simplest strong cipher in the world. Ciphersaber
> (an RC4-based cryptosystem) provides a good description:
>
> http://ciphersaber.gurus.com
No offense but is that a plug? RC4 is so simple you could explain it
here no need to advertise.
BTW RC5 is really simple as well... so is Blowfish, TEA, X-TEA .... :)
Tom
--
PGP 6.5.1 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: dave <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: US export laws re Canada
Date: Mon, 23 Aug 1999 19:13:38 GMT
According to two articles in "Canadian Machinery and Metalworking", the
USA passed amendments to the InternationalTraffic in Arms Regulations
in April of this year that revoked Canada's exemption from this
regulation.
The CM&M writers stress that this effects any technology or data that
might conceivably be applied to military use will now require export
permits. Canadian defense contractors are experiencing clearances on
quotation details that take longer than the open time on the request for
quotations, and can't even enter a bid.
This seems to be applied to manufactured goodies, electronics, aircraft
parts, etc, but would probably apply to the "strong" encryption
products, too.
Anyone up here tried to open a computerised bank account recently? I
think they need the strong encryption...and I recall "swearing" that I
was a Canadian citizen when I set one up some time ago before I could
down-load
the bank's package.
Anyone know anything more about this gem?
Dave
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How does RC4 work ?
Date: 23 Aug 1999 19:07:29 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>> http://ciphersaber.gurus.com
> No offense but is that a plug? RC4 is so simple you could explain it
> here no need to advertise.
Check out the site - it's based on that fact. :>
------------------------------
From: Stephan Eisvogel <[EMAIL PROTECTED]>
Subject: Re: IDEA in Applied Crypto
Date: Mon, 23 Aug 1999 21:03:22 +0200
Tom St Denis wrote:
> So I will ask, does anybody know of any errata from the IDEA C code
> from Applied Crypto?
I recently messed around with side-channel attack papers to harden
some of my own code against it. You can go to
http://www.ascom.ch/infosec/downloads.html
and download the revised IDEA 2.1 code. There's also plenty of test
vectors to verify your code against. If decryption doesn't return
the plaintext you started with, check for byte-ordering bugs. My
first IDEA code for a microcontroller had that thing wrong in the
key-setup routine and it almost drove me mad... heheh!
Good luck,
--se
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: question regarding number of keys possible. . .
Date: Mon, 23 Aug 1999 19:31:01 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>And, thanks to your question, I found a mistake on that page: the
>number of wirings for 8-contact rotors was eight times too small.
Oops. Four times too small.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST AES FInalists are....
Date: 23 Aug 1999 12:30:27 -0700
In article <7ppror$s8i$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> As a matter of fact we can define a standard mode for using the AES
> that automatically achieves this goal at the price of slightly larger
> ciphertext. All applications that use AES in this mode would guarantee
> that the same key will not be reused too often. Here is one
> possibility: define a new blocklaintext size that is a multiple of 128
> bits, for the sake of discussion let's pick 1600 bytes or 100 blocks.
> Now before encrypting, generate 16 random bytes, xor them to the
> original AES key and use the result to encrypt the 100 blocks. Send or
> save the 16 random bytes in the open.
I take your point, although the exact proposal you suggest has some
troubling features. In particular, it looks as if it allows for
related-key attacks on the block cipher. Many block ciphers aren't
designed for security against this type of attack model.
Nonetheless, I'm sure the proposal can be modified to fix this weakness,
and I understand your point. I just wanted to make this small observation,
even though I realize that it is a minor quibble.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Attacks on RC4 ?
Date: Mon, 23 Aug 1999 18:56:11 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> I'm sure others here will supply details of the two weak key attacks
> found by Andrew Roos and David Wagner, but here's the one other
result
> I know about: a very tiny bias in the CPRNG, experimentally verified.
>
> http://www.hedonism.demon.co.uk/paul/rc4/
Here is my question. What machine did you test 2^45.5 bytes on?
That's about 50 days of work or so... Do you have more info on it?
Tom
--
PGP 6.5.1 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: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST AES FInalists are....
Date: 23 Aug 1999 12:23:33 -0700
In article <7pkde8$bgq$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> I wonder. Surely the AES competition is not an academic
> exersize framed by NIST's specifications for the contest;
> after all the AES will be an important primitive in many
> real-world COMSEC systems. You cannot analyze primitives
> independently of their context. I think it would serve
> security better if the public researchers investigated for
> weaknesses in the AES finalists when only a few known or
> chosen plaintexts are available, because this is the
> appropriate attack model in the real world. Why not assume
> that "only" a thousand known plaintexts are available and
> compare the finalists under this assumption alone?
In principle, I agree. In practice, I don't see how it can work.
If we took this as the criterion, we'd never be able to make a decision:
I consider it highly unlikely that anyone would be able to find a
non-trivial attack on even the weakest of the AES candidates under this
threat model.
The state of knowledge about block ciphers is, IMHO, so extremely
underdeveloped that even if such an attack were to exist, it's not
entirely clear that we'd be able to find it.
So instead we use a sub-optimal strategy: we make extremely generous
assumptions about the resources of the attacker (generous to the
attacker, I mean), and look to see if there are any attacks under this
admittedly-unrealistic threat model.
If a cipher survives scrutiny under this more-generous threat model, the
argument goes, it is more likely to survive against real-world attacks
(which necessarily have much harsher limits on the attacker).
Of course, the problem is that we're probably not finding the best
attacks on the cipher, only the best ones we know how to find. So to
believe in this scientific method, you have to believe that there is
a strong correlation between the severity of the attacks we know how
to find and the best attacks, and you have to believe that there is a
strong correlation between the existence of attacks under a generous
threat model and the existence of attacks under a realistic threat model.
I'd like to believe that someday we'll know much more about how to design
and analyze block ciphers. Today we operate with only partial knowledge.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST AES FInalists are....
Date: 23 Aug 1999 12:28:18 -0700
In article <7ppror$s8i$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> If a "traditional" type of attack is found against finalist A that
> requires 2^50 known plaintexts and 2^50 computer resources (some
> function of work and memory) and another attack is found against
> candidate B that requires only a thousand plaintexts and 2^100 computer
> resources, which cipher should be considered more secure?
The conventional answer is that both candidates should be eliminated
from the competition. Both attacks are indicative of certificational
weaknesses that don't inspire confidence.
Of course, there is a risk that you'll eliminate all the candidates
in this way -- but if that happens, you just revisit all the decisions.
And my gut feeling is that it is unlikely that all of the candidates
will be eliminated in this way -- probably a few will survive, and
then NIST will pick from among the survivors.
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Mon, 23 Aug 1999 18:57:43 GMT
Reply-To: Jim Dunnett
On Sun, 22 Aug 1999 23:17:45 -0400, "Harlan Carvey, CISSP"
<[EMAIL PROTECTED]> wrote:
>> This
>> Klinton has some great friends doesn't he?
>>
>
>[snip]
>
>>
>> Klinton is the worst thing that ever happened to our country and
>> it's constitution. The man is EVIL. We have to thwart his every
>> move. Our liberty is at stake. And, no I am not some christian right
>> wing nut case.
Just an ordinary right-wing nut case.
What's the Klinton character got to do with PGP?
>Who is this "Klinton" and why is he so evil? You seem to be referencing
>events the President...you may not be the nut case you mention, but you
>sure as heck can't spell.
!!!
--
Regards, Jim. | We have decided not to go to France
amadeus%netcomuk.co.uk | this summer as it is too full of
dynastic%cwcom.net | unattractive, shirtless Englishmen
| talking into mobile 'phones.
PGP Key: pgpkeys.mit.edu:11371 | - Auberon Waugh.
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: Human-Readable Encryption (Newbie)
Date: Mon, 23 Aug 1999 18:57:44 GMT
Reply-To: Jim Dunnett
On Sun, 22 Aug 1999 19:58:05 -0400, <[EMAIL PROTECTED]> wrote:
>Your messages are all very interesting and helpful! However, could someone
>point to a resource (web site or publication) that would provide the
>algorithms, key generation methods, etc.? I don't even know where to begin.
>>> There's also 'ATBASH'. This converts ASCII to 5-character groups
>>> (mixed upper-case letters and figures).
I can't find any original documentation, only the executable.
Try searching on the net, otherwise come back and I'll search
further here.
--
Regards, Jim. | We have decided not to go to France
amadeus%netcomuk.co.uk | this summer as it is too full of
dynastic%cwcom.net | unattractive, shirtless Englishmen
| talking into mobile 'phones.
PGP Key: pgpkeys.mit.edu:11371 | - Auberon Waugh.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: MUM
Date: 23 Aug 1999 13:04:36 -0700
A clever idea, but this can be easily cracked.
Write Sa = A + mL, where m is an integer and LC = 0. Given SaC and C,
we can solve for an A of this form with linear algebra (but we can't find L).
Similarly write Sb = B + nR, where CR = 0, and solve for B.
Note that SaCSb = (A+mL)C(B+nR) = ACB + nACR + mLCB + nmLCR = ACB, by
the choice of L and R. (For example, nACR = nA(CR) = nA(0) = 0.)
In other words, to derive the session key, we only need to know A and B;
the exact values of Sa and Sb don't matter. But A and B are easily
calculated by a passive eavesdropper. Therefore, the protocol is insecure.
In article <[EMAIL PROTECTED]>, Gary <[EMAIL PROTECTED]> wrote:
> Let [Sa], [Sb] and [C] be 2X2 Matrices (Mod 2 to the power of 32).
> (Each matrix is 128 bits long)
>
> Let [Sa] and [Sb] be invertible.
> (Determinants not equal to 0 and odd (relatively prime to 2 to the power of
> 32))
> Let [C] be uninvertible.
> (Determinant equal to 0)
>
> [Sa] & [Sb] are generated using 128 bit random numbers.
> They can be re-chosen until passes invertible check.
> [C] uses 2 randomly generated 32 bit numbers. Their product is factorised.
> This is used to create the 2 other 32 bit numbers to yield a 0 determinant.
>
> Public key sender broadcasts the pair [C][Sb] and [C].
> (using matrix multiplication [C][Sb]=[C]X[Sb] (mod 2 to the power of 32))
>
> Replier sends back [Sa][C].
>
> Both can generate [Sa][C][Sb] as a secretly shared key.
> (Replier uses [Sa] multiplied by public key senders [C][Sb])
> (Public key sender uses replier's [Sa][C] multiplied by [Sb])
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Cryptomathic Denamrk
Date: Mon, 23 Aug 1999 20:04:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Yes, Cryptomathic is very legitimate. Peter Landrock is a great guy.
> Don Johnson
>
Amen. I have a great deal of respect for Peter. He is highly
competent.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: I need strongest weak elliptic curve...
Date: Mon, 23 Aug 1999 19:48:16 GMT
When I explained to NSA that I was going to use the x component
multiples of the shared secret as block cipher material (effectively
making a block cipher out of an asymmetric key cryptosystem), then they
said that the largest field size I could export was 113 bits, which is
sort of what I would expect. Would you all agree that this makes
sense? Or does it tend to shed light somewhere that I am not aware of?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: CBC problems...
Date: Mon, 23 Aug 1999 16:28:40 -0400
>
> Tommy just does oit get it. He can spout all kinds of BS but now we find
> he does not even have a clue as to how CBC works. Yet he acts like he
> understands what "wrapped-PCBC" is and how it relates to other cipher chaining
> methods. Tommy grow up.
>
> 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
I don't think that this sort of remark is suitable in this news group. Tommy is young
man who seems to love studying crypto. He may make mistakes, he may have
some opinions that others do not share, but he likes to learn. Alot of good questions
in this news group have been initiated by Tom. This is how we all learn.
Mr. Scott, if you would like people to take your SCOTT19 cryto system seriously,
start by respecting other people in the news group.
Anton.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Unconcealed messages in RSA
Date: Mon, 23 Aug 1999 16:33:22 -0400
Elisabeth Oswald wrote:
> Hi!
> Can anyone give me a hint how to get the number of
> unconcealed messages for RSA ? It should be
> (1+gcd(e-1,p-1))(1+gcd(e-1,q-1)).
>
> Thanks, Elisabeth
> ------------------------
> [EMAIL PROTECTED]
I have not read it, but I beleive you can get your answer in
this paper:
Blakley and Borosh,
"Rivest-Shamir-Adleman public key cryptosystems do not
always conceal messages",
Computers and Mathematics with Applications, 5:3,
1979, pp 169-178.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Human-Readable Encryption (Newbie)
Date: Mon, 23 Aug 1999 20:54:59 GMT
[EMAIL PROTECTED] (wtshaw) wrote, in part:
>Of course, without real keys, these are not examples of encryption, so some say.
But they are relevant none the less.
Data compression at the input end, and conversion to convenient form
at the output end are relevant to encryption.
Base conversion is a form of substitution, and substitution is
important in cryptography. Fractionation is a strong pencil-and-paper
form of cryptography, and fractionation not involving exact factors of
the alphabet length can indeed make things really hard.
Of course, if one simply converts to another base approximately, one
introduces some additional redundancy.
As I've noted, I've fished in these waters a little myself:
In extreme cases, such as 47 bits -> 10 letters, this additional
redundancy is very slight.
Otherwise, one can look for useful combinations of numbers that allow
an intermediate step which doesn't add any bulk:
128 = 125 + 3, 32 = 27 + 5, so there are two ways to convert a binary
message to streams of base-3 and base-5 symbols. Also, 26*26 = 1 +
27*25, and thus a very tight interweaving of a binary message, half
converted to letters, is possible.
But I make no apologies for starting from binary, instead of, say,
from a 44-character typewriter keyboard input alphabet. Besides being
able to encrypt pre-existing data files this way, binary, using the
smallest base, lets me efficiently compress data using Huffman codes.
If I used another base, the grain size would be larger. (Of course, I
*could* use arithmetic coding, but that's not a possibility I want to
consider.)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
