Cryptography-Digest Digest #805, Volume #11 Thu, 18 May 00 04:13:01 EDT
Contents:
Re: AEES-Cascade (David Blackman)
NSA hardware evaluation of AES finalists (Ken Lamquist)
Re: AES final comment deadline is May 15 (David Blackman)
random.org? ("RecilS")
Re: Interesting differentials in BREAKME (Raphael Phan)
Re: Definition of "Broken" Cipher (wtshaw)
Re: AES final comment deadline is May 15 ("Scott Fluhrer")
DNA Cheated? ("Ryan Phillips")
Re: random.org? ("Jacques Willekens")
Re: DNA Cheated? ("Ryan Phillips")
Re: About Hardware RNG ("Steve and Darla Wells")
----------------------------------------------------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: AEES-Cascade
Date: Thu, 18 May 2000 13:29:00 +1000
[EMAIL PROTECTED] wrote:
>
> AEES-Cascade is 640-bit DES-like block cipher, where
> cascade of F-funcrions is used instead of rounds.
>
> Performance of AEES-Cascade excluding I/O operations was measured
> sending for encryption 410Mb in a loop. It is 931 Kb/sec.
Assuming you are using a modern fast PC, this seems quite slow.
>
> There is followning architecture of F-fubction:
> 256 byte key length
> S-box is multiplication table of a group of the order 256
> 16 sub-key-dependent S-boxes
> 16 sub-keys 256 bytes length
> IP and inverse one are sub-key dependent
> EP and P are sub-key dependent
> XOR with current sub-key
> XOR with left part of input
>
> The Avalanche Effect of AEES-Cascade.
>
> A desirable property of any encryption algorithm is that a small
> change in either the plaintext or the key should produce a
> significant change in the ciphertext. For 64-bit block DES change
> only one bit gives 34 bit change in ciphertext. This makes 53%.
> To be able to compare AEES-Cascade implementation (640-bit) with
> DES (64-bit) we should change the same amount of information namely
> 10 bits. Two ciphertexts encrypted with AEES-Cascade differ in 303
> bits, which makes 47,3%.
>
> With two keys that differ in only one bit position in DES
> we have about 50% of the bits in the ciphertext differ.
> In AEES we are using 2048 bits key. To be able to compare
> key avalanche effect with DES we should change 37 bits.
> Again, the results show that about half of the bits in the
> cipher text differ.
You should get pretty close to 50% change with a one bit change in input
or key. Otherwise the big boys will break your cypher pretty easily, as
soon as they can be bothered trying.
------------------------------
From: [EMAIL PROTECTED] (Ken Lamquist)
Subject: NSA hardware evaluation of AES finalists
Date: Thu, 18 May 2000 03:33:45 GMT
The NSA report on the comparisons of hardware implementations of
the AES candidates is now on the web site. The URL is:
http://csrc.nist.gov/encryption/aes/round2/NSA-AESfinalreport.pdf
It's unfortunate that it appeared on the last day of the public
comment period, since it means that the public comment mechanism
cannot be used to point out any limitations or flaws of the analysis.
The original plan was for the results to be produced six months
after the start of round two, which would have resulted in the
report being available in the first half of March.
* * *
The encryption times of the AES finalists differed significantly, as
you can see from the following table. Rijndael is well ahead of the
others, which in my view makes it the leading candidate.
time area transistors
Rijndael 288.8 46.36 1029,046
Serpent 632.6 23.27 345,483
Twofish 1223.2 23.04 377,599
RC6 1233.2 21.66 430,436
Mars 2256.9 127.43 1950,277
This shows the fastest encryption times in nanoseconds to perform a
128 bit key encryption or decryption for each of the candidates. It
also shows the circuit size in square millimeters and in number of
transistors.
The above table is for implementations that support 128 bit keys only.
It is interesting to consider the additional cost of using hardware
which supports all key lengths. The following table shows the
percentage increases in size and encryption time imposed by such
hardware when used with 128 bit keys.
time area transistors
Rijndael 36.7% 37.0% 60.4%
Serpent 0.0% 0.0% 0.0%
Twofish 0.5% 43.0% 43.0%
RC6 -0.9% 12.5% 40.1%
Mars 0.0% 0.5% 0.4%
Twofish encryption has a longer critical path when longer key lengths
are used, which requires a slower clock speed. Rijndael requires more
rounds, and thus more clock cycles, when using a longer key. If system
design considerations prevent the use of varying speed encryption, then
the cost of supporting all three key sizes in a system using Rijndeal
or Twofish is:
time area transistors
Rijndael 89.5% 37.0% 60.4%
Twofish 30.5% 43.0% 43.0%
The upshot of this is that if Serpent or Mars is selected as the AES,
I expect to see hardware that supports all three key size predominate.
If any of the other three, but most particularly Rijndael or Twofish,
becomes the AES, I expect 128 bit key only designs to predominate,
effectively eliminating the 196 and 256 bit key versions of the AES
from consideration where hardware designs are concerned.
I now turn to implementation cost for the various finalists. The
following table gives information on minimal size implementations.
Area transistors time
Twofish 9.15 134,997 2104.00
Serpent 13.78 204,617 775.18
RC6 13.97 217,008 6674.62
Rijndael 20.74 275,485 472.1
Mars 51.99 742,403 3872.26
Twofish wins this one. I am not sure how important this metric is. I
don't expect to see AES encryption and decryption instructions being
built into microprocessors any time soon regardless of which candidate
is selected.
A related but different issue is how much throughput can be provided
by an algorithm in applications where many blocks can be encrypted in
parallel. There is no hard limit on the throughput in this case, since
we can always increase the throughput by adding more encryption units,
but in practice there will always be budget limitations. So the
relevant metric here is throughput per unit area.
bps/area depth latency
Serpent 52.587 32 773.12
Rijndael 43.988 10 222.8
RC6 19.289 20 1165.40
Twofish 17.076 20 1240
Mars 11.236 34 2290
All these numbers are based on pipelined implementations. The depth
column shows the depth of the pipeline, and the latency column shows
the time to encrypt one block. (I estimated the last two latency
values from a graph in the report, since numerical values were not
provided.) Serpent wins here, largely due to a deep pipeline.
Some applications require frequent key changes. Rijndael suffers
here because before decrypting with a key it is necessary to run
through the key schedule in the forward direction, so switching
decryption keys is slow. However, the decryption itself is fast
enough that a key switch followed by a single decryption marginally
faster with Rijndael than with Serpent, its nearest competitor.
Switching keys for encryption has zero cost with Rijndael. An
application which performs only decryption might precompute the
forward pass through the key schedule, and save the result instead
of the original key. This would allow zero cost switching between
decryption keys.
In summary: Rijndael has the shortest encryption/decryption time.
Serpent is more attractive than Rijndael on some other measures, but
is signficantly slower than the other candidates when implemented in
software. Therefore, I believe that Rijndael provides the best
performance of all the candidates when both hardware and software
performance are taken into account.
Kenneth Almquist
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Thu, 18 May 2000 13:53:49 +1000
Michael Scott wrote:
>
> It seems to be between Twofish and Rijndael at this stage. I much prefer the
> latter, but Twofish has undoubtedly been marketed rather better.
>
> Would others agree that its a two horse race? (I nearly typed "two fish
> race").
>
> Mike Scott
Rijndael only if it gets extended to at least 16 rounds and preferably
20. That would put a dint in it's speed advantage, but it still looks
ok.
If they only consider unmodified entries, only Twofish and Serpent are
any good.
------------------------------
From: "RecilS" <[EMAIL PROTECTED]>
Subject: random.org?
Date: Thu, 18 May 2000 00:22:46 -0400
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Does anyone know the quality level of random.org? It explains what
random numbers are and that it retrieves them from radio wave noise,
but fails to mention whether you're getting fresh numbers, rehashes,
etc.
Also, does anyone know of a real-time stock market level server (Dow
Jones preferably but any will do)?
Obviously I'm trying to find a good source of online random numbers
so any other sources would also be appreciated.
Thanks
- - RecilS
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOSNwFBJETAFqh0RgEQIg+wCcC2Az75F6Sbdb/aUTKtXvo6Q5J70AoKek
ejnla5OiBOyFVOlCqiNWoYY+
=Tpd2
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 18 May 2000 12:51:48 +0800
From: Raphael Phan <[EMAIL PROTECTED]>
Subject: Re: Interesting differentials in BREAKME
Hi,
Tom St Denis wrote:
> the probability of a differential is measured over the input size, like
> in DES a diff of '14' corresponds to 14/64 not 14/16.
Ok, Mark, so how did you manage to get a differential of 32/256? Could you
enclose your difference distribution table for us?
RAphael
--
" Contentment is not the fulfilment of what you want, it is the
realization of how much you already have. "
" When you were born, you cried and the world rejoiced.
Live your life in such a manner that when you die,
the world cries and You rejoice... "
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Definition of "Broken" Cipher
Date: Wed, 17 May 2000 22:32:17 -0600
In article <8fvj7g$mep$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> What exactly is a broken cipher. Obviously we have went in circles
> over what we already know, finite machines are finite in their
> complexity.
>
> Whoopy-doo. The argument at hand is when does a cipher become invalid
> in it's role to sufficiently randomize the input.
>
Having weaknesses does not mean that a cipher is broken if it still does
its job in its circumstances. Demanding that a cipher do a specific job
and seeing that it cannot, means that for that job it is broken. Some
ciphers are broken for more circumstances than others.
--
Secrets that are told or available are not secrets any more, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Wed, 17 May 2000 22:24:57 -0700
Michael Scott <[EMAIL PROTECTED]> wrote in message
news:5tCU4.25835$[EMAIL PROTECTED]...
> It seems to be between Twofish and Rijndael at this stage. I much prefer
the
> latter, but Twofish has undoubtedly been marketed rather better.
>
> Would others agree that its a two horse race? (I nearly typed "two fish
> race").
>From what I can see, it does look like a horse race, but between Serpent and
Rijndael.
Serpent has (more accurately, is perceived to have) the best security
margin, and performance that's reasonable, if not great.
Rijndael has very good performance just about everywhere, and security
that's (to the best of public knowledge) sufficient.
Which one gets picked depends on the exact prejudicies of the pickers:
whether extreme security or rather better performance is more important.
Twofish loses by having a security margin that's perceived to be not quite
as good as Serpent, and performance that's not quite as good as Rijndael.
Even though one would think this would make it a good middle-of-the-road
candidate, I expect that NIST will go after one extreme or the other.
RC/6 and Mars lose by being lousy in hardware, and in software if you don't
have a fast multiply and variable rotate, and by not being perceived as
having that great a security margin as compared to Serpent or Twofish. I'd
be very surpised if NIST picked one of those two.
Just my $0.02
--
poncho
------------------------------
From: "Ryan Phillips" <[EMAIL PROTECTED]>
Subject: DNA Cheated?
Date: Wed, 17 May 2000 22:41:20 -0700
Who cheated who?
I just got my new edition of Popular Science June 2000. On page 82/83 there
is an article entitled: "A Strand of Genius" by Gunjan Sinha. It mentions
that a young girl named Viviana Risca won the Intel Science Talent Search
when she revealed her DNA Stegonography paper. The 'prize' was $100,000
scholarship. The article goes into the background of what she likes to do,
etc.
My problem:
Intel's web site gives you the details to the algorithm she 'came' up
with. you can find it here:
http://www.intel.com/pressroom/archive/releases/ed031300.htm
I quote, "She encrypted the message,'JUNE6_INVASION: NORMANDY,' inserted
it in the gene sequence of a DNA-strand, and flanked it by two secret
"primer" DNA sequences. Then she combined the molecule with many other
similar molecules. The hidden message could be retrieved only by someone
knowing the two secret primer sequences - the keys to the code. Because
the pair of primers provides a trillion trillion options, she concludes that
the code is
essentially unbreakable."
Problem #2:
I found it really suprising that this article:
http://www.infowar.com/class_2/99/class2_061599a_j.shtml says that a person
named Carter Bancroft first developed a DNA 'microdot'. I might as well
quote the rest of the article because its there.
"Bancroft first assigned each letter of the English alphabet, as well as
each number and a few punctuation marks, to a simple three-letter DNA
sequence
-- such as CGA for `A' and CCA for `B' -- roughly analogous to the way
nature creates amino acids, the building blocks of proteins, from three-unit
sequences.
For the first test message, Bancroft used perhaps the best-kept secret
of World War II, the Allied invasion of Normandy, to prove the transmission
method could work.
He created special message-bearing DNA molecules containing the
encrypted words as well as a DNA ``hook'' -- a so-called ``primer
sequence'' --
to mark the beginning and end of the message.
Each of these molecules was then mixed in with some 30 million other
molecules of ``concealing DNA.'' The solution was then transferred to filter
paper, from which a ``microdot'' was cut out and pasted over a period
in a printed letter.
Tests showed the hidden message could be sent through the mails and
remain legible to a collaborator who knew both the encryption key and the
DNA
``hooks'' needed to fish out the message: ``June 6 Invasion:
Normandy.''
What is the difference in these two algorithms. In my mind this is too much
the same. Opinions?
-Ryan Phillips
Student California State University Sacramento
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Jacques Willekens" <[EMAIL PROTECTED]>
Subject: Re: random.org?
Date: Thu, 18 May 2000 08:05:52 +0200
RecilS <[EMAIL PROTECTED]> wrote in message
news:8fvr58$vf2$[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Does anyone know the quality level of random.org? It explains what
> random numbers are and that it retrieves them from radio wave noise,
> but fails to mention whether you're getting fresh numbers, rehashes,
> etc.
> Also, does anyone know of a real-time stock market level server (Dow
> Jones preferably but any will do)?
> Obviously I'm trying to find a good source of online random numbers
> so any other sources would also be appreciated.
>
> Thanks
> - - RecilS
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBOSNwFBJETAFqh0RgEQIg+wCcC2Az75F6Sbdb/aUTKtXvo6Q5J70AoKek
> ejnla5OiBOyFVOlCqiNWoYY+
> =Tpd2
> -----END PGP SIGNATURE-----
You may take a look at http://fourmilab.ch/hotbits/
------------------------------
From: "Ryan Phillips" <[EMAIL PROTECTED]>
Subject: Re: DNA Cheated?
Date: Wed, 17 May 2000 23:08:35 -0700
Sorry about that, Its just that Pop Sci. didn't give credit to Carter
Bancroft.
It says on this page that they worked as a team:
http://news.bbc.co.uk/hi/english/sci/tech/newsid_365000/365183.stm
my mistake
-Ryan Phillips
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Steve and Darla Wells" <[EMAIL PROTECTED]>
Subject: Re: About Hardware RNG
Date: Wed, 17 May 2000 21:07:11 -0700
"Mike Rosing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > I was wondering (being spoiled as I am) does anyone have a bread-boarded
> > version of
> >
> > http://world.std.com/~wware/hw-rng.html
> >
> > Using either a 18v input or on-board 9v batt supply?
> >
> > That you can spare? I want to try it out, but I don't know how to read
> > the diagram properly (I know the basic symbols....).
>
> Not on me. But that's really an RF receiver, not a RNG. The "not
> connected"
> pin is an antenna. You want a source that's more secure, like a battery
> inside a shielded box. You also want the ability to balance the output.
> that circuit isn't tunable.
>
> Breadboards are expensive. See if you can find some stuff at Radio
> Shack
> (or get a real parts catalog like DigiKey). Hardware is fun, but just
> as
> time consuming as software :-)
>
> Patience, persistence, truth,
> Dr. mike
>
It is interesting that a good radio has good signal and low noise. A good
RNG has good noise and low (no!) signal. Both are very very hard to design
and require specialists with years of background and a few good failures
under their belt. A bad design can be used for either ;-)
---Steve
------------------------------
** 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
******************************
