Cryptography-Digest Digest #637, Volume #14 Mon, 18 Jun 01 04:13:01 EDT
Contents:
Re: Is ECB truly more secure than CBC? (Tim Tyler)
Earpster AES: Updated Link ("James Wyatt")
Re: Is ECB truly more secure than CBC? (David Wagner)
Re: Anyone Heard of "Churning" (David Wagner)
Re: FIPS 140-1 test (Mark Wooding)
Re: Single-cycle sbox question (Benjamin Goldberg)
Re: 4 more inducted into NSA Hall of Honor ("John A. Malley")
Re: Single-cycle sbox question (SCOTT19U.ZIP_GUY)
Re: Single-cycle sbox question (Benjamin Goldberg)
Re: CipherText E-mail encryption (Bryan Olson)
New Directions in Cryptography (David Hopwood)
Re: SSL/TLS compression methods??? (Bryan Olson)
Re: New Directions in Cryptography (Nomen Nescio)
Speed of Hardware Encryption/Decryption ("S Hanks")
Re: Speed of Hardware Encryption/Decryption (Bob Deblier)
Re: Speed of Hardware Encryption/Decryption (Paul Rubin)
Re: Speed of Hardware Encryption/Decryption ("Panu H")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Jun 2001 22:21:38 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:>* Protocol can't cope with it - e.g.:
:> Multiple recipients, with new keys from a pad at midnight every night.
: I don't understand.
I was talking about the case where there's an existing protocol - and
you can't redesign it to include your key manipulations - since that would
create incompatibilities with the existing clients.
:>* Recipient or sender is an embedded device - with no PRF handy.
: If you can't handle a PRF, you can't handle encryption.
Yes sorry - I thought you were referring to a hash. On reflection even
if you had been, this objection would still be likely to be superfluous.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "James Wyatt" <[EMAIL PROTECTED]>
Subject: Earpster AES: Updated Link
Date: Sun, 17 Jun 2001 22:40:41 GMT
It has come to my attention that Yahoo does not like when you use their
briefcase feature to provide software. I only have about 1000 download off
of Download.com and they shut me down. So, if anyone would like to download
a simple DOS based Rijndael program with source code you can find it at:
http://www.geocities.com/jrwyatt79/Earpster.zip. Also, let me know what you
think. I'm just a poor IS student and Earpster is the first program I have
written that is of any use.
Peace,
Jim
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Is ECB truly more secure than CBC?
Date: Sun, 17 Jun 2001 23:01:53 +0000 (UTC)
Tim Tyler wrote:
>I was talking about the case where there's an existing protocol - and
>you can't redesign it to include your key manipulations - since that would
>create incompatibilities with the existing clients.
Ok. I assumed we were talking about a design question.
If it's an existing protocol, it seems unlikely that you'll
have any choice about whether to use ECB or CBC mode, since
changing the mode of operation would also create incompatibility.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Anyone Heard of "Churning"
Date: Sun, 17 Jun 2001 23:05:29 +0000 (UTC)
Stephen Thomas wrote:
>Apparently, ATM Passive Optical Networks (APONs) have standardized on
>an "encryption" algorithm refered to as "churning." Does anyone know
>anything about this?
No clue. The pointers you gave didn't give enough information
to evaluate it (although it looked like it might be a weak form
of substitution cipher on bytes; if this is correct, it would be
trivially insecure).
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: FIPS 140-1 test
Date: 18 Jun 2001 02:15:02 GMT
Peter Gutmann <[EMAIL PROTECTED]> wrote:
> As a followup question, has anyone ever looked at doing the tests
> which require an FPU in an (admittedly approximate) integer-only way?
> There are some embedded systems which don't do FP-maths too well.
My Catacomb library has draft-FIPS 140-2 tests in integers-only. It's a
very simple transformation to make on the bounds, and doesn't compromise
accuracy. (I have the FIPS 140-1 tests in my CVS repository...)
I don't have an integer-only version of Maurer's test, unfortunately. ;-)
-- [mdw]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Sun, 17 Jun 2001 23:53:47 -0400
Henrick Hellström wrote:
>
> See http://www.streamsec.com/createsc.asp The proof is incuded. I
> suppose that's where you got the idea in the first place.
No, I got the idea to create single-cycle sboxes in this manner from the
key schedule of the LJA1 cipher, which predates your code significantly.
And I'm sure that he got his code from somewhere else. Don't try to
steal credit from others.
> If you are using key data to create the permutation and want to avoid
> key collisions, you should use the algorithm at our homepage.
> Otherwise you would obtain each permutation n times, where n is the
> length of the permutation. Consequently:
In other words, you're saying that if there are 256 elements, my method
will end up mapping 256! unstructured permutations down to 255! cingle
cycle permutations, a collision factor of 256? Gee, what a surprise.
Are you saying that yours doesn't? Yeah, right.
> temp := a permutation of length n-1.
> J := n-1;
> for I := 0 to n-2 do begin
> X := temp[I];
> SBox[J] := X;
> J := X;
> end;
> SBox[J] := n-1;
This looks almost exactly like mine, offset by 1.
Mine [with the typos corrected] is:
temp = random_permutation
for( i = 0 to N-2 )
sbox[ temp[i] ] = temp[i+1];
sbox[ temp[N-1] ] = temp[0];
Yours is equivilant to:
temp = random_permutation
for( i = 0 to N-2 )
sbox[ temp[i-1 % N] ] = temp[i];
sbox[ temp[N-2] ] = N-1;
With the difference being that mine is correct. Yours has N-1 where it
should have temp[N-1]. Is this a typo? And if one is bothering to use
a temp value like your J value, then the last assignment can be gotten
rid of:
temp = random_permutation
j = temp[N-1];
for( i = 0 to N-1 )
j = sbox[ j ] = temp[i];
But I wouldn't write psuedocode like this, as it's not as clear what
it's supposed to be doing.
--
The longer a man is wrong, the surer he is that he's right.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: 4 more inducted into NSA Hall of Honor
Date: Sun, 17 Jun 2001 20:46:37 -0700
"Douglas A. Gwyn" wrote:
>
> The Hall of Honor occupies one wall of the National Cryptologic Museum.
> There was an induction ceremony Thursday for 4 more awardees (3 of whom
> are still alive and attended the ceremony, the 4th being represented by
> family). Read about the Hall at http://www.nsa.gov/honor/index.html
F.L. Bauer wrote in "Decrypted Secrets, Methods and Maxims of
Cryptology",
"...the literature and my personal contacts have shown me that
professional decryptors do not have an easy life...The work of the
professional cryptologist is thankless; he is not allowed to celebrate
his success in public or with his friends, and not even his family will
be allowed to know what he is doing. He is permanently in danger of
being abducted or blackmailed. Such restrictions usually persist even
after active duty." (pp 410-411)
It's great to see a public Hall of Honor for those who made such
important contributions to cryptology. The fact that three of the 2001
inductees get a chance to share their successes publicly with friends
and family makes it even better (and I am tickled pink to see an alumnus
from my alma mater!)
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Single-cycle sbox question
Date: 18 Jun 2001 03:48:42 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>Henrick Hellström wrote:
>>
>> See http://www.streamsec.com/createsc.asp The proof is incuded. I
>> suppose that's where you got the idea in the first place.
>
>No, I got the idea to create single-cycle sboxes in this manner from the
>key schedule of the LJA1 cipher, which predates your code significantly.
>
>And I'm sure that he got his code from somewhere else. Don't try to
>steal credit from others.
>
>> If you are using key data to create the permutation and want to avoid
>> key collisions, you should use the algorithm at our homepage.
>> Otherwise you would obtain each permutation n times, where n is the
>> length of the permutation. Consequently:
>
>In other words, you're saying that if there are 256 elements, my method
>will end up mapping 256! unstructured permutations down to 255! cingle
>cycle permutations, a collision factor of 256? Gee, what a surprise.
>Are you saying that yours doesn't? Yeah, right.
>
Actually I have been doing keyed S-boxes longer than either
of you. But I don't mess with small ones. try 19x19.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Mon, 18 Jun 2001 00:08:50 -0400
Tom St Denis wrote:
>
> "Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I know of two methods for generating a single-cycle sbox.
> >
> > The first one is:
> >
> > do { sbox = random_permutation } until( single_cycle(sbox) );
> >
> > The second one is:
> >
> > temp = random_permutation
> > for( i = 0 to N-2 ) {
> > sbox[ temp[i] ] = sbox[ temp[i+1] ];
> > sbox[ temp[N-1] ] = sbox[ temp[0] ];
> >
> > Now, while I know that method two is of course much, much, faster
> > than method one, I *don't* know whether or not it can produce all
> > possible single-cycle sboxes, or whether it is biased. I don't
> > *think* it's biased, but I'm not sure...
> >
> > Tom's sboxgen uses method 1. I plan on making a change in my own
> > copy to use method 2, but I want to first know that it will be
> > correct.
>
> Well you can always list a single cycle as (x y z) for example (3 2 1)
> which means 1 => 3, 3 => 2, 2 => 1, so the table would be { 3, 1, 2 }
>
> Just make a random sbox, then find the entries and see the next
> element. I.e search for 1 first, then 2, then 3... etc..
>
> Not too hard.
Huh? Searching for stuff sounds like it would take quadratic time.
My algorithm should take linear time wrt the number of elements.
--
The longer a man is wrong, the surer he is that he's right.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sun, 17 Jun 2001 21:59:49 -0700
Tom St Denis wrote:
[...]
> This is pure irony. I wrote the code to output fixed block sizes to make it
> simple (i.e KISS) then you propose to handle variable sized blocks.
I think you miss the point. For any octet string x, encoding x
then decoding that result should give us back x. I've now checked
your decode procedure. If we encode a single octet with the value
zero; the result is "aaaa". Decode "aaaa" and the result is three
octets long.
It looks like your code only works when the length of the original
octet string is a multiple of three.
--Bryan
------------------------------
Date: Mon, 18 Jun 2001 06:16:42 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: New Directions in Cryptography
=====BEGIN PGP SIGNED MESSAGE=====
Someone recently asked whether Diffie & Hellman's 1976 paper
"New Directions in Cryptography" was on-line. It is (without figures):
<http://citeseer.nj.nec.com/340126.html>
Well worth reading.
On the subject of early (1970s) papers on public-key cryptography, the
original papers on RSA, the Rabin cryptosystem, and the work of Ellis,
Cocks and Williamson at CESG/GCHQ, are also on-line:
<http://citeseer.nj.nec.com/rivest78method.html>
<http://hdl.handle.net/ncstrl.mit_lcs/MIT/LCS/TR-212>
<http://www.cesg.gov.uk/about/nsecret.htm>
- --
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
iQEVAwUBOy2OfjkCAxeYt5gVAQG3mggAywnIZEbW/Pqw3jy9p7JOHaGVdaCbBXgk
GyFXGIAXA+jo0vYSTZyZuEQrw2he+AKs6luNsaH3ezd44IvRw+JC3uS5/Tm3e54J
WPZQEywhwaB+BrsB1/V6+y24uLbPbxxrXQ/8iKC3Y0eadvHkAHjM+2i4xQeYZDAI
R6pycK906QcsnLC0YNwwVsO3Hk1m1n1jFfId8nq0B+oUr0raW9uNMyPFZsILVqkp
vwTuVU8kr7Br9y1hIaT9Rn8AMCHl+hhUyOx//qOGT3DLexS0duN7DRCh1czrLRdG
7Yl1SmOyeEjXTjLhwH+mxoA5benEJFpurKA8EjI8w8bPTZFWn/OGUQ==
=D78W
=====END PGP SIGNATURE=====
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: SSL/TLS compression methods???
Date: Sun, 17 Jun 2001 23:41:00 -0700
Erwann ABALEA wrote:
>
> On Sat, 16 Jun 2001, Ricardo wrote:
>
> > 1) Does anyone know which compression methods are used in SSLv3 and TLSv1?
> > (I only know two: gzip and zip)
>
> I think that no compression method is really defined. Compression can be
> enabled by the SSL and TLS standards, but the real mechanisms will be
> defined latter (in a future version).
Correct, though the standard takes a different point of view.
>From the TLS spec (RFC 2256)
There is always an active compression algorithm; however, initially
it is defined as CompressionMethod.null.
[...]
A CompressionMethod.null operation is an identity operation; no
fields are altered.
The RFC doesn't define any other compression methods, and currently
there are no others for standard SSL/TLS.
--Bryan
------------------------------
From: Nomen Nescio <[EMAIL PROTECTED]>
Subject: Re: New Directions in Cryptography
Date: Mon, 18 Jun 2001 08:47:16 +0200 (CEST)
> Someone recently asked whether Diffie & Hellman's 1976 paper
> "New Directions in Cryptography" was on-line. It is (without figures):
>
> <http://citeseer.nj.nec.com/340126.html>
>
> Well worth reading.
Didn't I see recently a listing for a talk with the same title by
one of the greats (maybe Shamir)? It was either a recent talk or one
coming up shortly. The implication was that it might be something cool.
Can't remember where I saw it though. Anyone?
------------------------------
From: "S Hanks" <[EMAIL PROTECTED]>
Subject: Speed of Hardware Encryption/Decryption
Date: Mon, 18 Jun 2001 00:05:27 -0700
Has anyone seen recent information that looks at how fast various processors
can handle the encryption/decryption of various algorithms?
For example, I'm looking for something that would show the speed that a
Pentium IV or Xeon or Sun processors could encrypt RSA, DES, or MD5 for
example. I'd also like to see similar information showing how fast they can
decrypt ciphers or how fast they can search the keyspace for various
algorithms.
If this information doesn't exist, I have the resources to do some of the
testing myself and can publish the results here. I'd like to get some ideas
though regarding what would be the best software to use for this test.
There is some data similar to this in "Applied Cryptography", however it is
alll about 5-6 years old and is based on the 486SX processor; I'd like
something a good deal more current. Any advice would be greatly
appreciated.
Thanks,
S Hanks
[EMAIL PROTECTED]
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Speed of Hardware Encryption/Decryption
Date: Mon, 18 Jun 2001 09:18:53 +0200
<posted & mailed>
S Hanks wrote:
> Has anyone seen recent information that looks at how fast various
> processors can handle the encryption/decryption of various algorithms?
>
> For example, I'm looking for something that would show the speed that a
> Pentium IV or Xeon or Sun processors could encrypt RSA, DES, or MD5 for
> example. I'd also like to see similar information showing how fast they
> can decrypt ciphers or how fast they can search the keyspace for various
> algorithms.
The BeeCrypt crypto library includes extensive benchmarks on a wide range
of processors. Not all of the code is fully optimized for each processor
yet, but you may find the file called 'BENCHMARKS' included in the source
distro useful, since it contains timings for modular exponentiations,
Blowfish, MD5, SHA-1 and SHA-256. If you're interested, have a look at
http://beecrypt.virtualunlimited.com/
Sincerely,
Bob Deblier
Virtual Unlimited
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Speed of Hardware Encryption/Decryption
Date: 18 Jun 2001 00:29:48 -0700
"S Hanks" <[EMAIL PROTECTED]> writes:
> For example, I'm looking for something that would show the speed that a
> Pentium IV or Xeon or Sun processors could encrypt RSA, DES, or MD5 for
> example. I'd also like to see similar information showing how fast they can
> decrypt ciphers or how fast they can search the keyspace for various
> algorithms.
> If this information doesn't exist, I have the resources to do some of the
> testing myself and can publish the results here. I'd like to get some ideas
> though regarding what would be the best software to use for this test.
I have a bunch of data like that but it's not systematically organized.
It would be nice if someone put it together. The simplest thing to do
is run "openssl speed" on a bunch of different computers.
Note: integer arithmetic on Sparcs is slow, so Sun computers with the
obvious public key implementations are a lot slower than comparably
clocked P3's. By reorganizing the computation to use Sun floating
point instructions it can run about the same speed as a P3. The P4
has a new and weird architecture and carefully tuned P3 code is
probably nonoptimal for it. However, I don't think much effort has
yet been put into careful P4 code for public key.
As for DES and MD5, I don't think they're all that interesting any
more. There are a bunch of benchmarks for carefully tuned Twofish
implementations on various processors on the Counterpane site.
Twofish didn't win the AES contest, but its timings probably reflect
how well those processors are likely to perform for other algorithms
too.
------------------------------
From: "Panu H" <panuh[@]cs.tut.fi>
Subject: Re: Speed of Hardware Encryption/Decryption
Date: Mon, 18 Jun 2001 10:52:19 +0300
Helger Lipmaa's homepage contains AES candidate implementations on different
platforms.
http://www.tml.hut.fi/~helger/aes/
--
Panu Hämäläinen
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
