Cryptography-Digest Digest #945, Volume #8 Fri, 22 Jan 99 06:13:03 EST
Contents:
Re: Who will win in AES contest ?? ([EMAIL PROTECTED])
Re: Pentium III... (".ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ.")
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available) (Darren New)
Re: 3DES in EDE mode versus EEE mode (Scott Fluhrer)
Re: simple symetric encrypt <-> decrypt (fungus)
Help: Which secret key cipher? (Graham Jones)
Re: Pentium III... ([EMAIL PROTECTED])
Re: what is AES ?? ("Brian Gladman")
Re: Crack in Export Laws?? (Paul Rubin)
Re: Metaphysics Of Randomness ("R H Braddam")
Re: Metaphysics Of Randomness ("Douglas A. Gwyn")
Re: Who will win in AES contest ?? ("Sam Simpson")
Re: Help: Which secret key cipher? (Graham Jones)
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available) (Fabrice Noilhan)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Who will win in AES contest ??
Date: Fri, 22 Jan 1999 00:30:32 GMT
In article <[EMAIL PROTECTED]>,
Robert Harley <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] (Piotr Kulinski) writes:
> > What do you think who will win in AES contest ???
> > My type is Twofish....
>
> Why do you think it would be Twofish? Because Bruce Schneier wrote a
> very popular book? Twofish is quite a complex, non-obvious cypher. No
> offense intended to its inventors, but I don't think it is a
> "front-runner". If you care about speed first and security second
> then Mars or RC6 are likely candidates. If you care about security
> first and speed second then DFC looks good.
>
> Anyway, the current stage in the process is to pick 5 candidates to
> survive to the next stage...
>
> Rob.
>
The winner will be one of the entries that the NSA has entered
which to the public will seem secure. If the method was any good
then it would not be so easily available. The US government would
never allow something to be used that it can not easily break.
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: ".ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ." <[EMAIL PROTECTED]>
Subject: Re: Pentium III...
Date: Thu, 21 Jan 1999 19:03:56 -1000
David Boreham wrote:
>
> > I spoke to Intel about this last year. I informed them
> > that I invented this 13 years ago while I was working at Intel. I
> > invented a random number generator for Intel and I proposed the
> > non-volatile memory scheme for holding chip serial numbers. I invented
> > the "single-poly EPROM cell" for storing ID numbers, etc. using the
> Pretty cool. But couldn't they use laser-zapped fuses
> for the chip ID ? EPROM technology is certainly capable
> of interesting things, but for the task at hand
> (configure a unique ID at backend test time), you
> don't _need_ an EPROM cell.
Laser blown fuses are a possibility. I have not seen the
Pentium III chip yet, so the speculations I am making are
only based on years of experience at Intel and 12 years out
of there. One problem with fuses for cryptographic keys or
for security serial numbers is that they are visible under
a microscope. A second problem is that they cause reliability
problems if extra processing steps are not taken: the laser
blast cracks open the top oxide layers and lets contaminations
in. That is why I told Intel to use the single poly EPROM cell
in 1986 for serial numbers on the 80386. I am glad they
finally have taken my advice (or maybe they re-invented the
idea).
The random number generator I had patented at Intel is probably
similar to the one on the Pentium III: several oscillators
combine their outputs and that odd waveform is sampled
asynchronously. Switched capacitors change the loading on each
oscillator with the switches controlled by the random bits that
are accumulated in a shift register. The oscillators each have
different responses to power supply noise, temperature,
capacitance change, noise due to thermally induced voltage
irregularities, and small processing irregularities. A heater
near one oscillator is switched on and off to produce a thermal
history that is different from that of the other oscillators.
When the chip comes out, people who evaluate it should look for
the single poly EPROM cells that are shaped like ping-pong
paddles made of polycrystalline silicon. The handle is the gate
of an MOS transistor, the paddle is the capacitor that stores
the floating charge. High voltages are applied during wafer
sort to this poly capacitor to cause avalanche injection to
program the serial numbers through a bond pad that is not
connected to the package the customer uses. It will be placed
under a metal power bus for added security.
The cells also store wafer ID info so that statistical analysis
can be done and failure tracking can be done years after retail
sales. This would facilitate recalls of chips from bad fab runs.
That's my guess.
An Un-named Source
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: Fri, 22 Jan 1999 03:51:40 GMT
> This is the great thing about Java - it unfreezes the code. As JVMs
> and JIT compilers get more advanced then every single Java program
> you own will go faster - no recompile needed.
Bwa ha! You must be kidding. :-)
That might be true if Java 1.0 code actually ran reliably on Java 1.2
JVMs, for example, but it doesn't. It's *almost* as flakey as Microsoft
code. ;>
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"You could even do it in C++, though that should only be done
by folks who think that self-flagellation is for the effete."
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: 3DES in EDE mode versus EEE mode
Date: Fri, 22 Jan 1999 00:39:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] wrote, in part:
>
>>The
>>question is: if I always want to use three different keys with the full 168
>>bits of entropy, is there any advantage in the EDE mode as compared to the
>>more "natural" EEE mode?
[Obligatory note: you may get 168 bits of key, but the key is really "only"
about 113 bits strong, if the attacker has a whopping big memory device]
>
>No, and, of course, there's the slight disadvantage that keys where
>one of the two E keys is identical to the D key are all equivalent to
>single-DES, while that never happens in EEE mode.
Oops, never say never. In EEE mode, if the first two E keys are identical
weak keys (or corresponding semiweak keys), then the entire operation is
identical to single-DES with the third E key. Rather less likely than the
situation you listed with EDE, but it is still a nonzero probability. And,
because it can be done delibrately:
>The only EDE advantage is interoperability.
Actually, the only advantage 3 key EDE has is that it's backward compatible
with 2 key EDE.
--
poncho
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: simple symetric encrypt <-> decrypt
Date: Thu, 21 Jan 1999 23:05:20 +0100
Daniel Feurle wrote:
>
> Have anyone of you an idea how i can encrypt and decrypt a simple
> integernummer.
> with a symmetric cryptosystem and without using -> x mod m
> modulo???
>
> example: 1234 -> encrypt -> (like) 3121239 -> decrypt -> 1234
>
How about "add 3120005"?
So long as nobody knows what number you added then this system
is *completely secure*. There's no way anybody can look at the
result (3121239) and work backwards to the original number without
knowing the secret number.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Graham Jones <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt
Subject: Help: Which secret key cipher?
Date: Fri, 22 Jan 1999 10:04:49 +0000
I plan to encrypt and send a single message using a shared secret key
scheme. I do not intend to send subsequent messages using this scheme.
Could someone please point out to me the advantages of using a block
cipher such as DES, over a simple algorithm such as an exclusive-or of
the plaintext against the key. Note that the key length can be equal to
the length of the plaintext.
I realise that by using the XOR technique, the key can easily be
recovered once the plaintext is known, but I'm not concerned about this
in a one-shot situation.
Also, I have little concern over the speed at which an XOR can be
performed in comparison to DES. The application of the message involves
a lengthy checking process; hence if an attack involved the trial of
each key combination, then the time taken to check each recovered
message would far outweigh the duration of each decryption pass.
Any advise would be very much appreciated.
--
Graham Jones
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pentium III...
Date: Fri, 22 Jan 1999 08:48:54 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] () wrote:
>
> Hmm. The serial number on the chip is to assist in copy-protection
> schemes, creating a market for cryptographic techniques...
> and a hardware random number generator on the chip will be useful to
> cryptography programs.
>
> So useful, I'm surprised they included such a feature (yes, I know dice
> aren't export controlled) since they probably have enough headaches
> getting approval to export their latest and greatest microprocessors.
>
> John Savard
>
John, the random number generators found in hardware and software today are
almost always 32-bit generators, meaning they have only 32-bit internal
states. This is equivalent to a 32-bit crypto key, which is far too small to
make a secure cryptographic system. Nobody will worry about exporting such a
chip.
If you are looking for something more secure, see my article "One-Time Pad
Cryptography" in the Oct. 1996 Cryptologia.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: what is AES ??
Date: Fri, 22 Jan 1999 08:10:41 -0000
team wrote in message <01be3ffb$182a0220$LocalHost@packard-bell>...
>Someone could explain me what is this algorithm, AES, or where can i find
>the source code or a description??
>
>thanks
> Jarod
Source code for all 15 AES candidates is available on my page at:
http://www.seven77.demon.co.uk/aes.htm
I also compare their performance on the Pentium Pro/PII
Brian Gladman
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Crack in Export Laws??
Date: Fri, 22 Jan 1999 10:33:40 GMT
In article <[EMAIL PROTECTED]>, Kazak, Boris <[EMAIL PROTECTED]> wrote:
>Anybody having a comment on the following, which is posted
>at Netscape's site, please don't keep it secret!
This is called Server Gated Cryptography. It's present in
Netscape Navigator 4.x and MSIE 4.x browsers and there's a
patch for MSIE 3.x to support it. In order to enable it,
your web server needs a special certificate (an SGC certificate)
which at the moment is only available from Verisign (Global ID).
Global ID's are available only to US corporations and overseas
companies and banks under certain circumstances. See the
Global ID page in the web server security section of www.verisign.com
for more info. Basically, you're allowed to get these certificates
and enable strong cryptography in exportable browsers only in
applications that the US goverment approves of--and that's been
the case all along. It's just a little more streamlined now.
Interestingly, I've been hearing from some server vendors that
they can't get Global ID's without a crypto export license--even to
ship servers to domestic US customers, even if the servers will
connect only to domestic US clients, so no exporting is involved.
What a pain!
------------------------------
From: "R H Braddam" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Thu, 21 Jan 1999 22:15:48 -0600
R. Knauer wrote in message
<[EMAIL PROTECTED]>...
>On Wed, 20 Jan 1999 08:48:15 -0500, "Trevor Jackson,
III"
><[EMAIL PROTECTED]> wrote:
>
>>Here's what is wrong. There is no lower limit on the
triviality of the operation
>>you can perform on the number K to "remove" its
randomness. For example, (bad) L
>>= K + 1. K is the only number that produces L when
one is added, thus K is no
>>longer random.
>
>>(Worse). K = K + 0. K is the only number that
produces K under additive
>>identity, thus K is not random.
>
>>(Worst) K = K. K is the only number with the value
K, thus it is not random, it
>>is K, thus K is not random.
>
>In each of those examples, producing a result that is
unique destroys
>the randomness of the key K. If I tell you what a
number Y is, and
>tell you that it was created, say by adding the number
one to it like
>above, then K is no longer random - it is a unique
number given the
>value of Y and the method of computing Y. Similarly
for the identity
>operation above.
>
>What I am trying to get across is that is appears (and
this is only a
>speculation on my part) that once a random number K is
used in an
>encryption operation, it loses its randomness because
then it becomes
>unique in the context of that operation.
>
>There is only one key possible that will reproduce the
message, and
>that makes K unique, not random since it is no longer
just one of the
>possible outputs from a TRNG. Only the key K can do
that, and that
>makes it special, not random.
>
>The fact that you may not know what K is, is not a
measure of
>randomness but a measure of obscurity. And we all know
that obsurity
>has nothing to do with true randomness per se -
although obscurity is
>confused with randomness all the time.
>
>Before K is used to encrypt the message, it is totally
random - it can
>be any sequence out of a pool of equiprobable
sequences of given
>length. But once you use it to form the ciphertext, it
loses that
>characteristic of randomness by virtue of its
uniqueness in the new
>context in which it has become entangled. And when the
inverse
>operation of decryption takes place, it is returned to
the pool of
>random numbers, because it is no longer entangled in
any context.
>
>
>Bob Knauer
>
I am not a mathematician or a cryptographer, and find
all that very confusing. On the one hand, you start
with a random number and a plaintext, and encrypt the
plaintext by XORing it with the random number. Then the
random number looses its random property because it can
be used to recover the plaintext?
How about the fact that the plaintext can be used to
recover the random number in the same way? Doesn't that
make the random number "computable" because you can get
it by XORing the cipertext with the original plaintext?
It seems to me that the random number lost its
"randomness" as soon as you selected it from the pool
of available random numbers. Until you selected the
number, each number in the pool had equal probability
of being the one to encrypt/decrypt the message. After
you selected it, all the other numbers' probabilities
went to zero, and the selected number's probability
became a certainty.
All that won't make it any easier for an attacker to
select the same random number (it will still be random
to them, unless and until they select it). Maybe that
means that randomness depends as much on where you are
as it does on the properties of that of which you are
considering the randomness.
All pretty complicated. I don't think I'll ever get it.
Rick [EMAIL PROTECTED]
Murphy's Law is the only sure thing in the universe.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Fri, 22 Jan 1999 08:12:34 GMT
R H Braddam wrote:
> I am not a mathematician or a cryptographer, and find
> all that very confusing. On the one hand, you start
> with a random number and a plaintext, and encrypt the
> plaintext by XORing it with the random number. Then the
> random number looses its random property because it can
> be used to recover the plaintext?
Like most things to do with knowledge, randomness is contextual.
The key is not "random" *with respect to the ciphertext it was
used to produce*. You can easily demonstrate that by using it
to with confidence decipher the ciphertext (to a highly coherent
plaintext), something a number "chosen at random" has little
chance of doing.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Who will win in AES contest ??
Date: Fri, 22 Jan 1999 10:32:03 -0000
Robert Harley wrote in message ...
>
>[EMAIL PROTECTED] (Piotr Kulinski) writes:
>> What do you think who will win in AES contest ???
>> My type is Twofish....
>
>Why do you think it would be Twofish? Because Bruce Schneier wrote a
>very popular book? Twofish is quite a complex, non-obvious cypher.
I thought TwoFish looked quite good from a conceptual point of view.
I was surprised how much emphasis Bruce et al put on speed in respect of
TwoFish. If you look at his comments before AES:
"This is serious business. Any algorithm proposed in 1997 won't be approved
until at least 2000. It will be a standard for 20-30 years, in legacy
systems for at least another ten, securing data that might need to be
secured for another 20. This means we are trying to estimate security in
the year 2060. I canšt estimate security ten years from now, let alone 60.
The only wise option is to be very conservative."
(1997/04/15 posting to sci.crypt)
One would expect an ultra-conservative cipher, right?
> No offense intended to its inventors, but I don't think it is a
>"front-runner". If you care about speed first and security second
>then Mars or RC6 are likely candidates. If you care about security
>first and speed second then DFC looks good.
RC6 is nice and simple and appears to be a logical progression from RC5. I
guess it depends on whether you trust data dependant rotations...
I personally don't like MARS much at all....
Rijndael should appear in the last 5... Its based on a good cipher (Square)
and is reasonably fast.
If you _really_ want to be conservative and go primarily for security (which
seems pertinent in view of BS's comments), then isn't Serpent the obvious
choice?
Cheers,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
------------------------------
From: Graham Jones <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt
Subject: Re: Help: Which secret key cipher?
Date: Fri, 22 Jan 1999 10:49:59 +0000
BTW, I forgot to add: The message I wish to encrypt contains only raw,
'formless' data i.e. not subject to structural analysis as, for
instance, the text of a particular spoken language would be.
--
Graham Jones
------------------------------
From: [EMAIL PROTECTED] (Fabrice Noilhan)
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: 22 Jan 1999 10:58:29 GMT
According to Jason Stratos Papadopoulos <[EMAIL PROTECTED]>:
> The opposite is also true. Sun cc only uses 16 FPU registers in Ultra-
> SPARC code, even if you ask it to compile for the UltraSPARC. But the
> Ultra has 32 FPU registers, and using them in hand-hacked assembly
> gives an enormous speedup.
OK, for sure you may have a speedup using assembly. But, this is not
always the case, and the cost is really higher. It depends on the
complexity of the algorithm you're programming.
> Anyway, I'm a nutcase, and when half the runtime ends up in one
> routine I automatically drop into assembly.
I usually check the assembly that the compiler generates and if it seems
reasonable give away. If not, I go to the assembly level.
Fabrice
------------------------------
** 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
******************************
