Cryptography-Digest Digest #116, Volume #10 Thu, 26 Aug 99 21:13:03 EDT
Contents:
Re: SHA-1 test vectors (DJohn37050)
Re: SHA-1 test vectors (Keith A Monahan)
Re: SHA-1 test vectors (Alfred John Menezes)
How does RC5 work? ("Brian Mullen")
Re: UNknown-related key cryptanalysis? (David Wagner)
Re: NEW THREAD on compression (John Savard)
Re: UNknown-related key cryptanalysis? (John Savard)
Re: NEW THREAD on compression (John Savard)
Re: Can we have randomness in the physical world of "Cause and Effect" ? (John
Savard)
Key to Ciphertext Ratio's ([EMAIL PROTECTED])
Re: Can americans export crypto when in another country? (SCOTT19U.ZIP_GUY)
Re: Can americans export crypto when in another country? (SCOTT19U.ZIP_GUY)
Re: How Easy Can Terrorists Get Strong Encrypt? ("Trevor Jackson, III")
Re: cryptographic DLL ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: SHA-1 test vectors
Date: 26 Aug 1999 20:19:32 GMT
The SHA-1 std is from NIST, try www.nist.gov.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: SHA-1 test vectors
Date: 26 Aug 1999 20:33:18 GMT
You could look in FIPS PUB 180-1 or...
"abc"
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"
84983E44 1C3BD26E BAAE4AA1 F95129E5 E54670F1
A million repetitions of "a"
34AA973C D4C4DAA4 F61EEB2B DBAD2731 6534016F
I copied these from sha1.c by Steve Reid.
: Where could I get some SHA-1 test vectors?
: Tomas
Hope this helps,
Keith
------------------------------
From: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: Re: SHA-1 test vectors
Date: 26 Aug 1999 20:41:15 GMT
The chapter that Pate is referring to is available for free download
from www.cacr.math.uwaterloo.ca/hac/
- Alfred
==========================================================================
| Alfred Menezes | Email: [EMAIL PROTECTED] |
| Department of C&O | Phone: (519) 888-4567 x6934 |
| University of Waterloo| Web page: www.cacr.math.uwaterloo.ca/~ajmeneze |
| Waterloo, Ontario | Web page for Handbook of Applied Cryptography: |
| Canada N2L 3G1 | www.cacr.math.uwaterloo.ca/hac/ |
| Centre for Applied Cryptographic Research: www.cacr.math.uwaterloo.ca |
==========================================================================
In article <[EMAIL PROTECTED]>,
James Pate Williams, Jr. <[EMAIL PROTECTED]> wrote:
>On 26 Aug 1999 19:04:35 GMT, [EMAIL PROTECTED] (Tomas) wrote:
>
>>Where could I get some SHA-1 test vectors?
>
>_Handbook of Applied Cryptography_ by Alfred J. Menezes et al. Table
>9.6 Test vectors for selected hash functions page 345. You might be
>able to find this chapter on-line. Do a web search for the title or
>author.
>
>==Pate Williams==
>[EMAIL PROTECTED]
>http://www.mindspring.com/~pate
------------------------------
From: "Brian Mullen" <[EMAIL PROTECTED]>
Subject: How does RC5 work?
Date: Thu, 26 Aug 1999 17:37:59 -0400
I've read RSA's FAQ on it, but I don't understand it completely. Is there
another source of information on this protocol? My main problem is the key
expansion step. When the key is copied into array L[0...c-1] it says that
c=[b/u]. b=bytes in the secret key, and u=(word size in bits)/8. What
about a basic RC5-32/12/5? There, u=32/8 so c=(5/4). How does that work?
How can you have a fraction as a location in the array? Any tutorials on
RC5 would be appreciated...
Brian
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: UNknown-related key cryptanalysis?
Date: 26 Aug 1999 15:35:44 -0700
In article <[EMAIL PROTECTED]>,
Rochus Wessels <[EMAIL PROTECTED]> wrote:
> Suppose K1=(a,b), K2=(a,c),
> but the difference between b and c is unknown.
> Are there any attacks of this kind against any cipher?
Yes.
Let me first tweak the question slightly to simplify the matter.
Suppose K1=(a,b,c), K2=(a,b,d), but the difference between c,d is unknown.
Then it turns out that this situation is insecure if you use three-key
triple-DES. A full description of the attack is given in Section 4.6
of our CRYPTO'96 paper on related-key attacks, available at
http://www.cs.berkeley.edu/~daw/papers/keysched-crypto96.ps
Put briefly, we encrypt a fixed plaintext P under the two keys to get
two ciphertexts C,C'. Note that DES(d,DES^{-1}(c,C)) = C'. Thus we
can solve for c,d using the attack on double-DES, and once c,d are known,
we can solve for a,b using a second double-DES break. Total complexity
can be as low as O(2^56) time and space.
Now if you look at Section 4.7 of the same paper, you will see another
mode of encryption where the answer to your question -- exactly as posed
-- is yes. A plaintext P_1,..,P_n is encrypted as
M_{j+1} = DES(K_1,M_j) C_j = DES(K_2,M_j xor P_j)
To attack this, obtain the encryption of a fixed plaintext P under both
keys to get two ciphertexts C,C'. Note that
DES(K'_2,DES^{-1}(K_2,C_j)) = C'_j, so K_2, K'_2 (i.e., b,c, in your
notation) can be recovered using the standard attack on double-DES; then
K_1 (i.e., a) can be recovered with an exhaustive keysearch.
A simpler way to see that the answer is yes may be to view K1 as a
168-bit key, divided into two parts by taking the first 112 bits
(call it "a") and the last 56 bits (call it "b"). Then three-key triple-DES
is vulnerable to attack under this scenario, using exactly the observation
in Section 4.6 of our CRYPTO'96 paper.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEW THREAD on compression
Date: Thu, 26 Aug 1999 22:42:05 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>Sorry that I don't understand what you wrote. What redundancy is
>being introduced through this convention of mine? (It simply leaves
>one single Huffman code unused.) Would you please detail a little bit?
That's the redundancy. Not using a code means that the other codes are
all too long by a small amount.
>I don't yet see your redundancy argument. My convention (1) enables
>me to output the compressed bit sequence without adding any length
>information at all (only 0 padding is used to obtain whole bytes,
>which is normally required in practice). Convention (3) even allows
>me to shorten the output from the Huffman algorithm under some
>favorable circumstances. So I believe there is less redundancy, if
>any, in my scheme as compared to that of yours.
Well, I don't agree, but I'll respond in full later.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: UNknown-related key cryptanalysis?
Date: Thu, 26 Aug 1999 22:51:57 GMT
Rochus Wessels <[EMAIL PROTECTED]> wrote, in part:
>Suppose K1=(a,b), K2=(a,c),
>but the difference between b and c is unknown.
>Are there any attacks of this kind against any cipher?
There are attacks involving identical plaintexts, enciphered with
different keys, against many classical ciphers. However, modern block
ciphers, from DES onwards, are quite resistant to that attack, since
they are resistant to chosen-plaintext attacks, which are stronger.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEW THREAD on compression
Date: Thu, 26 Aug 1999 23:05:28 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>(3) After (2) is done, any number of trailing bytes that contain
> contain all 0's may be deleted or added according to user's
> choice or else randomly decided upon by the program.
That may occasionally shorten the file slightly.
Having an unused code lengthens many of the other codes, so the whole
file is slightly more redundant.
This can be minimized if the unused code is a long one, treated as if
it belongs to a low-probability symbol.
But if this is done with a symbol with an obvious pattern - and the
all-zero symbol certainly is that - other characteristics of the
Huffman code used become known to an attacker.
If there's an omitted symbol 0000000000, then there has to also be a
symbol 0000000001 to keep it company. And there either has to be a
symbol 000000001 or two or more symbols starting with that string.
And what this means is that low-frequency symbols will tend to start
with zeroes.
That flaw can actually be corrected: instead of omitting the symbol
that is all zeroes, one can just as easily match the symbol that, all
the way through, matches the digits of pi or any other sequence.
The longer your message, the more the added length due to the extra
symbol will be greater than that created by padding.
Note that I said to put the three bits indicating the number of unused
bits in the last byte in the second-last byte. This avoids the problem
where there are unused bits in the byte before the byte from which we
find out they're unused, which might lead to them being processed.
Thus:
01101 000 11010110
11010 001 1011010*
00110 010 011010**
...
10110 111 1*******
And note that the unused bits that are used for padding _need not_ all
be zeroes, instead one can use _random_ bits for padding. (And one
_definitely_ should. But one's 'random' bit generator must not leak
information about anything else.)
Thus, the plaintext message consists of uniformly distributed
bits...right down to the very end. As far as possible, it has been
ensured that each bit of the plaintext has a 50% probability of being
either a 1 or a 0.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Can we have randomness in the physical world of "Cause and Effect" ?
Date: Thu, 26 Aug 1999 23:07:54 GMT
sb5309 <[EMAIL PROTECTED]> wrote, in part:
>I am not a physicist.
It is claimed that quantum mechanics, as far as we know, allows true
randomness.
However, physical randomness methods, even when they do not involve
quantum mechanics, have the advantage over a computer pseudorandom
method in that the initial conditions, which are the cause of the
'random' output, can often be genuinely hard to determine.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Key to Ciphertext Ratio's
Date: Fri, 27 Aug 1999 00:06:52 GMT
Here's a little thought provoker. Assuming we're using a block cipher,
IDEA for example, and we keep the plaintext constant. For the purpose
of this discussion, since the plaintext will be kept constant, IDEA
becomes a 128-bit to 64-bit transformation of the key. Ideally, there's
no such thing as a bad key, so we will assume that no key will encrypt
to anything resembling the plaintext, i.e. no more than 1 plaintext
character may pass through the cipher, worst case of course.
Now, there are 2^64 different ciphertext permutations. Since we are
assuming that there are only good keys, there are somewhat less than
that. With these assumptions, is it possible that two or more key's
encrypt the same plaintext to identicle ciphertext's? Also, in this
example there are 2^128 different permutations of the key, thus the
problem is further compounded.
Now to make things worse. Let's say we don't restrict the plaintext.
Now we have 2^64 different possible plaintexts and 2^128 different
possible keys, both combined map to only 2^64 different ciphertexts.
So, if the cipher is properly designed...
1. Could it be possible that two different key's for a given ciphertext
produce two legitimate plaintexts? This does not necessarily assume
alpha-numeric text.
2. What are the chances that two or more key's can encrypt the same
plaintext to identicle ciphertexts?
3. Can this be exploited? Certainly it could make a brute-force attack
much easier if one gets lucky.
Anyway, food for thought, or in this case thought over food.
Casey
Here's an original quote for greg :-)
"The truth is out there. You may just have to 'extract' it from
somebody."
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: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 01:23:33 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Michael D. Crawford) wrote, in part:
>
>>can I export the crypto
>>back to Switzerland without violating US laws?
>
>No, the U.S. law covers the actions of its citizens abroad.
>
Since you claim I am covered by US law do I have to drive
on the right side of road when overseas. No you can't export it
if you wrote it over there. Same if you go to Holland and smoke
a joint. Its ok in Holland so who cares what it is in the US.
Alsoi many people have dual citizen ship. What rules would they
follow.
>John Savard ( teneerf<- )
>http://www.ecn.ab.ca/~jsavard/crypto.htm
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: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 01:20:39 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Doug Stell)
wrote:
>On Wed, 25 Aug 1999 19:32:32 -0700, [EMAIL PROTECTED] (Michael D.
>Crawford) wrote:
>
>Mike,
>
>From past experiences, I understand it to work as follows:
>
>The export regulations preclude "U.S. rnvolvement" in crypto work
>outside the U.S., unless you are licensed to do so. This applies to
>U.S. citizens and, with some caveats, to corporations.
>
>>Speak Freely includes encryption, so if I port that while I'm in the US
>>I can't contribute my changes back to the original source archives,
>>which are in Switzerland.
>
>Correct. That would be an exportation.
>
>>But I may be moving to Canada in a few months (I'm marrying a Canadian
>>woman). Once I'm in Canada, as long as I create my port of the crypto
>>software while I'm in Canada (so I never bring the crypto Speak Freely
>>into the US, and don't take it back out again), can I export the crypto
>>back to Switzerland without violating US laws?
>
>Unless you give up your U.S. citizenship, doing so would be "U.S.
>envolvement" and would be covered under the export regulations. Living
>in Canada or marrying a Canadian would make zero difference.
>
>BTW, a U.S. company may be licensed to participate in crypto work
>outside the U.S., only if there is no paarticipation on the part of
>people in the U.S. or U.S. citizens, whereever they reside. The two
>countries I know of such arrangements with were Austrailia and Israel.
>Canada may be in a better position than even these allies.
>
>>I expect to travel to the US frequently on business and it would be a
>>drag to get arrested for some free software work I do while in Canada.
>
>You would be running that risk.
>
>>Canada itself has some export controls, but according to the Crypto Law
>
>Canada is more lax than the U.S., both in its regulations and in their
>application. However, you would would be bound by the stricter U.S.
>regulations and application, unless and until you relinquish your
>citizenship.
>
Where did you hear this crap. IF you write the stuff on your own
out of the country it is not exporting it by defination.
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
------------------------------
Date: Thu, 26 Aug 1999 20:47:35 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Medical Electronics Lab wrote:
> JPeschel wrote:
> >
> > What export controls are there on compilers?
>
> I just got a Code Composer release from TI. In the "End-User
> License Agreement" it says:
> 6 - Export Control - The re-export of US orignal softare and
> documentation is subject to the Export Administration Act of
> 1969 as amended. Compliance with such regulations is your
> responsibility. You agree that neither you nor your customers
> intend to or will, directly or indirectly, export or transmit
> the Licensed Materials or related documentation or technical
> data to any country to which such export or transmission is
> restricted by any applicable US regulations or statute, without
> the proper written consent, if required of the BXA (fully
> spelled out), or such other government entity as may have
> jurisdiction over such export or transmission.
>
> There's a compiler for one type of processor (the C3x series)
> somewhere on the CD. I wouldn't be supprised if they (TI)
> haven't shipped the CD all over the world and they just
> change the boiler plate for the country it's delivered in.
> But it's clear TI thinks there are controls on compilers
> and other software.
The license does not contain a claim that controls exist, but an
allocation of responsibility for complaince with controls whose
existence is indeterminate. "any applicable US reg or statute" "if
required" "other such government entity" --> These are all CYA
legalisms. They have no bearing on the existence of controls except
that TI's lawyers want TI protected against actions its customers may
take.
TI apparently likes belt, suspenders, and straightjacket.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: cryptographic DLL
Date: Thu, 26 Aug 1999 23:52:01 GMT
In article <7q1en5$8hh$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
>
> > This may be a dumb question, but isn't it legal for him to
distribute
> > the dll at least? The reason I'm asking is that there are a number
of
> > cryptographic toolkits that are available worldwide, such as RSA's
> > CryptC and CryptJ. Now, since they don't encrypt anything by
> > themselves, that should make it exportable. I could just be real
> > ignorant, though.
>
> My understanding is that anything that can generate a key, source code
> or binaries, are what the NSA will tell Commerce and BXA is export
> regulated. I have the meat of my elliptic curve cryptosystem in C++
> libraries and you can download them from my web site, but the one file
> with the 8 linies of code necessary to "generate" a key is restricted.
> I have to mail that to you on a post card. I could e-mail it to you,
> but I am guaranteed that even if you are a foreign agent in this
> country, I will not violate export regulations by using a post card.
>
Well, I'm no expert. I tried to look up some stuff on it and it seems
very vague. The only possible definate that I found, that I was truly
looking for, was that if you leave the country and take a laptop with
you, you can have strong encryption on the laptop so long as it remains
in your possesion. Now, that came from a government web site, so I'm
95% sure it's correct. But anyway, I'm no expert. I merely live here
in the U.S.
> > Btw: I love that "So much tyrany to fight, so little time" quote
Greg.
>
> Thank you...
>
> --
> Red Dawn- "What makes us better than them?" "We live here!"
>
> Wallace on Brave Heart- "While you stand around and bicker,
> I am going to take the fight to the [king's back yard]."
>
"The devil can cite scripture for his own purpose." The Merchant of
Venice, by William Shakespeare. Act 1, Scene 3.
"If we don't learn that bigger and better weapons don't solve anything,
we may end up in the same cave we started in."
Terry Jones of Monty Python, from Ancient Inventions on the Discovery
Channel
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
