Cryptography-Digest Digest #341, Volume #12 Wed, 2 Aug 00 17:13:01 EDT
Contents:
Re: Elliptic Curves encryption (Roger Schlafly)
Re: Elliptic Curves encryption (Mok-Kong Shen)
Re: Skipjack and KEA test vectors (Mark Wooding)
Re: Small hash checksum (Mark Wooding)
Re: A new crypto algorithm Wolf_Cub_2 (Mark Wooding)
Re: What vulnerabilities do I have? (Steve Weis)
What is the word on TC5? (tomstd)
Re: Math�matics (Ioshua)
Re: Security (Terry Ritter)
Re: IV for arfour ("Andreas Sewe")
Re: Skipjack and KEA test vectors (David Hopwood)
Re: Elliptic Curves encryption (Terry Ritter)
Re: IV for arfour ("Andreas Sewe")
Re: Elliptic Curves encryption (Terry Ritter)
----------------------------------------------------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Wed, 02 Aug 2000 12:51:26 -0700
Doug Kuhlman wrote:
> Have you seen a proof that breaking ECDH is equivalent to the
> ECDLP? I haven't.
No. It is an open question.
> I seem to recall a couple years ago, a claimed proof
> that breaking RSA was easier than factoring, but I never saw it enough
> to make my own judgment. Anyone else know about this?
There are some arguments that indicate that breaking RSA might be
easier than factoring. But no proof.
> Actually, most PK ciphers are scalable (in one form or another). It's
> one of the reasons they *seem* secure *now*. 1024-bit RSA not good
> enough but you think factoring is hard? Use 2048-bit RSA. etc.
> Scaling Rijndael, OTOH, to accept 512 bit inputs and a 1024-bit key
> seems less trivial....
I think the Hasty Pudding Cipher (another AES entrant) was scalable.
If that is what you really want, use it. (Some defects were found,
but they are probably all fixable.)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Wed, 02 Aug 2000 22:19:09 +0200
Roger Schlafly wrote:
> Doug Kuhlman wrote:
> > Actually, most PK ciphers are scalable (in one form or another). It's
> > one of the reasons they *seem* secure *now*. 1024-bit RSA not good
> > enough but you think factoring is hard? Use 2048-bit RSA. etc.
> > Scaling Rijndael, OTOH, to accept 512 bit inputs and a 1024-bit key
> > seems less trivial....
>
> I think the Hasty Pudding Cipher (another AES entrant) was scalable.
> If that is what you really want, use it. (Some defects were found,
> but they are probably all fixable.)
Just a question: How is the term 'scalability' to be exactly understood?
(Do we need to consider efficiency issue, etc.?) Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Skipjack and KEA test vectors
Date: 2 Aug 2000 19:53:36 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
> There's a much smaller collection of test vectors which will test the
> entire F-table. I have one at home, but I've not sent out a version of
> Catacomb with them in. Still, the more, the merrier. I'll put them
> into tests/skipjack when I get home.
My test vectors are below. (Fibrand is one of my library's
noncryptographic generators. It has the benefit of being fast.)
# --- The official Skipjack test vector ---
#
# It's a bit piss-poor that they only provide one test-vector here.
00998877665544332211 33221100ddccbbaa 2587cae27a12d300;
# --- From KEA test vectors ---
#
# The Skipjack algorithm is used by the KEA to derive the final key.
# Unfortunately, the test vectors given in the Skipjack/KEA spec don't
# match my (or anyone else's!) implementation. These are the values
# which seem to be generally agreed.
e7496e99e4628b7f9ffb 99ccfe2b90fd550b 60a73d387b517fca;
e7496e99e4628b7f9ffb 60a73d387b517fca 24c90cb05d668b27;
e5caf4dcc70e55f1dd90 b71cb0d009af2765 64f4877ae68a8a62;
e5caf4dcc70e55f1dd90 64f4877ae68a8a62 fee778a838a601cd;
# --- These are the results expected from the KEA spec ---
#
# A `?' indicates that I don't know what that digit's meant to be. I've
# derived the top 16 bits of the intermediate results from the spec.
# e7496e99e4628b7f9ffb 99ccfe2b90fd550b 2f30????????????;
# e7496e99e4628b7f9ffb 2f30???????????? 740839dee833add4;
# e5caf4dcc70e55f1dd90 b71cb0d009af2765 8e27????????????;
# e5caf4dcc70e55f1dd90 8e27???????????? 97fd1c6bd86bc439;
# --- Some more test vectors ---
#
# These are dreamed up by me. The above tests don't actually exhaustively
# test the F-table. There are 16 entries unaccounted for. The keys and
# plaintexts were generated using fibrand with seed 0.
cde4bef260d7bcda1635 47d348b7551195e7 f17b3070144aebea;
7022907dd1dff7dac5c9 941d26d0c6eb14ad a055d02c5e0eae8d;
568f86edd1dc9268eeee 533285a6ed810c9b b4c22f4fb74c35dc;
689daaa9060d2d4b6003 062365b0a54364c7 08698d8786f80d16;
6c160f11896c4794846e cfa14a7130c9f137 d6db848b7cecdd39;
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Small hash checksum
Date: 2 Aug 2000 19:55:12 GMT
stanislav shalunov <[EMAIL PROTECTED]> wrote:
> But if the input is short (say 32 bytes on average), CRC would still
> be faster, correct?
Yes. The blocking and padding of MD4 will dominate, and CRC will be a
much better choice.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: A new crypto algorithm Wolf_Cub_2
Date: 2 Aug 2000 19:56:52 GMT
Leonid Nowikow <[EMAIL PROTECTED]> wrote:
> This algorithm is very steady to the chosen-plaintext attack .
[snip binary mush]
Please repost with something readable.
-- [mdw]
------------------------------
From: Steve Weis <[EMAIL PROTECTED]>
Subject: Re: What vulnerabilities do I have?
Date: Wed, 02 Aug 2000 13:13:35 -0700
[EMAIL PROTECTED] wrote:
> I've implemented network data encryption of an client/server application
> where I use 3DES to encrypt all the data between the client and server.
> I know that I have atleast 2 compromises:
> 2) if the attacker uses a man-in-the-middle attack
Assuming the two parties have securely agreed on a key, how would an
man-in-the-middle attack be conducted? An active attacker could disrupt
packets or conduct a replay attack, but how would a m.i.t.m. work? My
understanding is that it would happen during key agreement where a third
party would inject an element into the protocol that would allow them to
read and forge all traffic between the two parties undetected.
------------------------------
Subject: What is the word on TC5?
From: tomstd <[EMAIL PROTECTED]>
Date: Wed, 02 Aug 2000 13:08:43 -0700
I have done more differential cryptanalysis on TC5 but no
breaks. There is a mistake in the TC5 paper as well.
But no real breaks on the cipher.
Maybe if David could explain his attack better we could finish
tc5 off?
Tom
http://www.geocities.com/tomstdenis/
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Ioshua <[EMAIL PROTECTED]>
Subject: Re: Math�matics
Date: 2 Aug 2000 20:17:41 GMT
Thanks a lot but how to join Sci.math.symbolic?
======
User of http://www.foorum.com/. The best tools for usenet searching.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Security
Date: Wed, 02 Aug 2000 20:19:24 GMT
On Wed, 02 Aug 2000 13:11:15 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt Mike Rosing
<[EMAIL PROTECTED]> wrote:
>[...]
>As pointed out in another thread here, you can never be 100% sure that some
>one won't find a way to break any PK system.
More than that, we can't even be 1% sure. We simply do not know the
probability of weakness for any cipher, perhaps especially PK.
We can know something about weakness with respect to our own
capabilities. But we only care about weakness with respect to others
whose capabilities we do not know.
Some might say that it is a tad misleading to talk about statistics
which cannot be known.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Andreas Sewe" <[EMAIL PROTECTED]>
Subject: Re: IV for arfour
Date: Wed, 2 Aug 2000 22:31:51 +0200
"David A. Wagner" wrote:
> I think there is some confusion here.
You may be right about that some confusion ;-).
> RC4 already allows you to use an arbitrary-length key,
> no modifications needed.
Well, your key is not quite arbitrary-length. Now I'm going into
pseudo-quoting mode, because I own only an translation of
"Applied Cryptography" - here we go:
"Initializing the S-Box is also easy. At first it is filled linearly:
S[0] = 0, S[1] = 1,..., S[255] = 255. Now you fill another array
of 256 bytes with the key, repeating the key as often as needed
to fill the whole array."
Well, after that crude translation it should be clear, that your
external key K_e can be only 256*8=2048 bits max. Any shorter
external key, say 128 bit, is - in this case - repeated 16 times to
fill the array.
Now this external key K_e is translated via the RC4 key schedule
into a permutation of 256 elements, the internal key K_i. Any
external key, even the fullsize ones are mapped onto this
permutation.
> You seem to be considering taking away the RC4 key schedule and
> replacing it with something else. Be very, very careful. The
> security of RC4 depends intimately on the key schedule. If you
> change its key schedule, you get an entirely different cipher, one
> that -- if you're unlucky -- may no longer be secure. I don't think
> changing the key schedule is wise.
Now, what I mean is not replace the RC4 key schedule with something
else, - i'm realistic enough not to come up with "absolutly secure" ideas -
but to totally avoid it.
Without any confusion, imho the best way is to enter the internal key
directly without bothering with an external one which is converted into
a permutation. Ok, your easy-to-remember passphrase is gone, but
thats the price for avoiding the mapping of K_e onto K_i. Now I can't
believe, that mapping all possible K_e produces exactly the same
number of each possible K_i, at least it should be hard to prove.
Some K_i occur likely more often than others, i guess.
That's the first part of the story. In its second chapter the question is,
how to link your key K, aka K_i, with the IV to produce your
session key K_s, since it is now a permutation.
/* Here comes my code */
for(int n = 0; n < 256; n++)
k_s[n] = k[iv[n]]; // the IV is used to mix up K
This code links two permutations, K and IV, giving a third one, K_s.
That's the stuff I was looking for.
> Given that RC4 accepts an arbitrary-length key, I can't see any
> motivation to take away the key schedule and replace it with something
> else. As far as I can tell, there seems to be nothing to be gained
> and a lot to be lost. What am I overlooking?
I hope I'm not overlooking something myself, but I do hope not to
produce that much confusion this time.
And if you miss your passphrases to much, you can still use your
RC4 key schedule for the generation of K, but having the possibility to
link it with the total range of IV permutations. That's what I called
interface adding just a little bit confusion.
An example, to avoid confusion this time:
You have a 128 bit key:
K_e
Next you use the RC4 key schedule to generate an 256 byte
permutation:
K_i = arcfour_key(K_e);
Now you generate another 256 byte permutation, the IV,
using a real random method - toying with 256 marbles or that kind
of thing:
IV
Then you link the internal key with the IV, generating the session
key:
K_s = K[IV]
Your message send looks like this:
IV, E(M)K_s
Anyone getting your message can easily reconstruct the session key,
if he knows K - and IV of course.
Due to the integration of a real random IV, the range of possible
K_s is extend from 2^128 (max) to 256! in the above example.
That's the basic idea behind all that confusion.
Andreas Sewe
PS: Well, brute force on your 128 bit key still is an option.
------------------------------
Date: Thu, 03 Aug 2000 08:34:23 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Skipjack and KEA test vectors
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> There's a much smaller collection of test vectors which will test the
> entire F-table.
If you can put those on the web, I'll link to them from the SKIPJACK
entry in SCAN.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYkgczkCAxeYt5gVAQFjeQf/cOC8jAnLRi8pSOxuPn9EhUVvZcUjjBm6
tJ4b9L7wqiPU66r7gkVoWYGBERKOertc6mSY04WUWKrSbLXpUGkQaKtPuEXTE0l5
1j4CMNxS50Cyj9I4cnLd7YIhIcGY2SchciME+ylgpjrK84j0/iaNUl4bEbxA7HHF
oKgAHRwcuIrSQ7DSDrNgRvhBUgcjUuyHkUj6Itw/NHrPem0DMuAsWcjhpGoYZ1Zr
yn57IFWBdHCXdlNfcjBCo1TSkR4EG4qeJEFJ5QhJgs7osPVlkkiyX1Ejxjr0r4NL
03WiDqYny1pmUZRyORCXze1NPzkHelQf3p+xROYRNK+bK/OZURe9vQ==
=Rz/L
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Elliptic Curves encryption
Date: Wed, 02 Aug 2000 20:44:01 GMT
On Wed, 02 Aug 2000 12:42:09 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt Mike Rosing
<[EMAIL PROTECTED]> wrote:
>[...]
>Terry is correct to state that these things are not secure from an
>unknown method of solution. It's ballancing the present against the
>future. If you want something secure *forever* you can't use anything.
>Because Terry is right, we simply can't know what will be discoverd
>in the future.
>
>To me, this is an impractical state. I'm willing to bet that any of
>these algorithms is secure for the next few years. That's good enough.
It has never been my position to say "don't use ciphers."
But I am quite concerned that mathematical proof in cryptography is
widely interpreted to be something it is not. This is deceptive to
precisely those who are least able to detect it or understand it. It
is not good professional practice.
More than that, the industry itself needs to come to a widespread
realization that our ciphers are not proven secure, and thus may not
be secure. That means right now, not sometime in the future. We
simply have no way to know what the other guy can do.
Being willing to bet on the future is fine, but that bet is without
scientific basis.
>I would very much like to see a scalable cipher. This too would be a
>pretty major advance for the art. But until it comes along, I'll do
>what everyone else does: use ciphers that *look* secure *now*.
I have produced scalable ciphers, and I have described them on
sci.crypt, so they have been around for years. They would have even
been a part of AES, except that NIST demanded ciphers with no
intellectual property rights. Indeed, I could not even compete
without promising to give up my rights -- presumably because I might
win -- and that is something I chose not to do.
I would be more understanding of the NIST position had they said that
all implementations of the cipher designs also must be free. But as
it is, while the designers get no compensation, the implementors get a
free ride and added profit. That is not "free," it does not help the
poor, and it also does not establish a basis for a continuing industry
of for-profit cipher design.
My scalable designs are covered by my patents, but I have long
encouraged non-commercial experimentation by making the descriptions
available.
So scalable ciphers do exist, and have for some years, but oddly have
yet to be academically investigated. Scalable ciphers are no panacea,
but they are a significant aid to analysis.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Andreas Sewe" <[EMAIL PROTECTED]>
Subject: Re: IV for arfour
Date: Wed, 2 Aug 2000 22:44:29 +0200
"David A. Wagner" wrote:
> Andreas Sewe <[EMAIL PROTECTED]> wrote:
> > Well, any stream-cipher needs an IV, and in most cases it is altogether
> > sufficant to XOR the key K with the IV to get the session-key K_s.
> I dispute this claim.
Perhaps you are right, concerning chosen-key-attacks, but
that is not the point of my question about RC4.
> Anyhow, your proposal was to use K o IV as the session key, where the
> permutations K,IV on 256 elements represent the master key and
initialization
> vector, respectively. But this requires a truly huge IV. Were you really
> proposed to transmit a 256-byte array as your IV, for each packet?
Right, 256 bytes per IV.
> That seems like an enormous transmission overhead, so I'm assuming that
> can't be right. Did you intend to generate the IV permutation somehow
> from a shorter value? If so, how? The details matter to the security
> analysis.
Well, the basic thing is the IV-to-Packet ratio. An IV that large is truly
ugly
for encrypting network traffic, but for larger packets and larger offline
applications it seems okay to me. Hope, you agree.
Andreas Sewe
PS: A pretty lengthy explanation to avoid any confusion of yours was posted
by me in this thread also some minutes ago.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Elliptic Curves encryption
Date: Wed, 02 Aug 2000 20:54:37 GMT
On Wed, 02 Aug 2000 22:19:09 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>[...]
>Just a question: How is the term 'scalability' to be exactly understood?
>(Do we need to consider efficiency issue, etc.?) Thanks.
I have been discussing this on sci.crypt for years. If you want a
definition, see, for example:
http://www.io.com/~ritter/GLOSSARY.HTM#Scalable
which is as follows:
Scalable
A cipher design which can produce both large real ciphers and
tiny experimental versions from the exact same construction rules.
Scalability is about more than just variable size: Scalability is
about establishing a uniform structural identity which is
size-independent, so that we achieve a strong cipher near the top, and
a tiny but accurate model that we can investigate near the bottom.
While full-size ciphers can never be exhaustively tested, tiny
cipher models can be approached experimentally, and any flaws in them
probably will be present in the full-scale versions we propose to use.
Just as mathematics works the same for numbers large or small, a
backdoor cipher built from fixed construction rules must have the same
sort of backdoor, whether built large or small.
For block ciphers, the real block size must be at least 128
bits, and the experimental block size probably should be between 8 and
16 bits. Such tiny ciphers can be directly compared to keyed
substitution tables of the same size, which are the ideal theoretical
model of a block cipher.
Potentially, scalability does far more than just *simplify*
testing: Scalability is an enabling technology that supports
experimental analysis which is otherwise *impossible*.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.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
******************************
