Cryptography-Digest Digest #944, Volume #8 Thu, 21 Jan 99 21:13:04 EST
Contents:
Re: Metaphysics Of Randomness (Darren New)
Who will win in AES contest ?? (Piotr Kulinski)
Re: steganography algorithm ("John Feth")
Re: Pentium III... (Anthony Naggs)
Re: Is speed of public-key algorithms important? (Bodo Moeller)
Re: 3DES in EDE mode versus EEE mode (John Savard)
Re: Pentium III... (A [Temporary] Dog)
Re: what is AES ?? (A [Temporary] Dog)
Re: 3DES in EDE mode versus EEE mode (Paul Schlyter)
Re: simple symetric encrypt <-> decrypt ([EMAIL PROTECTED])
Re: 3DES in EDE mode versus EEE mode ([EMAIL PROTECTED])
Re: Pentium III... ([EMAIL PROTECTED])
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available) (Jason Stratos
Papadopoulos)
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available) (Jason Stratos
Papadopoulos)
----------------------------------------------------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Tue, 19 Jan 1999 18:09:39 GMT
R. Knauer wrote:
>
> On Mon, 18 Jan 1999 23:36:44 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >> A Turing Machine program has memory associated with it - the tape. Yet
> >> whether any particular program halts or does not halt is totally
> >> random. See Chaitin, op. cit.
>
> >Ridiculous.
>
> Says you. You won't mind terribly if I take Chaitin's word for it
> instead of yours. Unless, of course, you are prepared to argue
> conclusively against Chaitin's theories.
Uh, I hate to point this out, but the fact that the halting problem is
in general unsolvable doesn't mean there are no programs for which
halting can be proven. I'm not sure what percentage of 2^N programs N
bits long would halt (obviously it would depend on the machine), but
it's pretty easy to see that one can calculate an arbitrarily tight
bound on the percentage of programs that halt, simply by simulating all
the machines in parallel, knowing how many there are (2^N) and how many
have halted so far. The longer you let it run, the more
programs-that-will-ever-halt will have halted.
There's a whole class of programs that I can prove always halt: those
containing a halt instruction and no jump instruction (or, alternately,
those with no while loops without variants). There's a whole class of
programs I can prove never halt, as well, equally trivially. And then
there's the class of programs that I can't tell, of course.
I think any cryptographic randomness concepts based on whether programs
halt has to be viewed in light of the fact that whether a program halts
is *not* random; it's 100% deterministic. Now, pick a 100% random
program, and try to determine whether it halts, and you might not get an
answer. But you might get an answer, too.
--
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: [EMAIL PROTECTED] (Piotr Kulinski)
Subject: Who will win in AES contest ??
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Jan 1999 19:25:05 GMT
What do you think who will win in AES contest ???
My type is Twofish....
------------------------------
From: "John Feth" <[EMAIL PROTECTED]>
Subject: Re: steganography algorithm
Date: 21 Jan 1999 22:43:33 GMT
Thanks for the pointer. This is an amazingly complete site.
Regards
jf
Steven H. McCown <[EMAIL PROTECTED]> wrote in article
<785n9k$nb$[EMAIL PROTECTED]>...
> For some good overviews, see:
>
> http://www.jjtc.com/Steganography/
>
>
>
------------------------------
From: Anthony Naggs <[EMAIL PROTECTED]>
Subject: Re: Pentium III...
Date: Thu, 21 Jan 1999 23:03:12 +0000
After much consideration ? decided to share these wise words:
>
>> Intel has announced that the Pentium III will have a built in hardware
>> random number generator, and individual serial number on each chip.
>
>The primary use for a processor serial number seems like it would be to
>enforce software licenses.
IMO The primary use for a unique processor serial number is for easy
identification of stolen processors, i.e. through software without
dismantling suspect PCs & removing heatsink assemblies.
--
BAD COMPUTER! That's my registry file you've trashed.
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Is speed of public-key algorithms important?
Date: Thu, 21 Jan 1999 10:26:55 GMT
> [EMAIL PROTECTED] (Charles Blair):
>> My understanding is that PGP and other protocols do the following:
>> (1) Create a cryptographically strong hash of the plaintext. The
>> size of the hash does not depend on the size of the plaintext.
>> (2) Use the hash to create a key for a PRIVATE-key system, such as
>> IDEA or something like DES. Encrypt the plaintext using this system.
This method of creating the symmetric key is not advisable: If
guessing the plaintext is feasible for the attacker (i.e. if there are
some possibilites whose probability exceeds, say, 1 / 2^80; note that
usually those probabilites should be measured from hindsight when the
attacker may have seen the decrypted messages or derivates of them),
then they can do trial encryptions and possibly find the plaintext --
i.e. that method does not make good use of the available keyspace.
And often, guessing the plaintext _is_ feasible.
Instead of selecting the symmetric key deterministically as a function
of the plaintext, the software should use a random number generator.
Some operatin systems (FreeBSD, Linux, and possibly others) come with
a kernel-level randomness generator (accessable as /dev/random,
/dev/urandom) which collects "entropy" from various sources such as
interrupt timings, thus pretty much solving the randomness problem for
applications. If this kind of operating system service is not
available, then the difficult task of randomness generation is the
duty of the software.
The approach taken by PGP (and many other programs) for random number
generation is to maintain a random number generator state in a file
(in the case of PGP 2.x: randseed.bin), into which randomness is
mixed whenever possible and from which the internal random number
generator is initialized at program start. If the contents of this
file are sufficiently unpredictable to an attacker, then the pseudo
random numbers created by the software random number generator are
unpredictable as well.
In order to update randseed.bin, PGP 2.x includes a hash of each
encrypted message (plus some other data) into its random number seed;
so, similar to your suggestion, a hash of the message is in fact used,
but it is not considered the most important input to random number
generation. If an attacker snoops your randseed.bin _and_ can guess
the plaintext of the next message(s) that you encrypt afterwards, then
they can decrypt that message or those messages. For the especially
security sensitive task of key generation, such attacks are precluded:
PGP does not rely on the inpredictability of randseed.bin then, but
tries to collect the required amount of randomness by measuring the
timing between keystrokes.
>> (3) Use the public-key system only to create an encryption of the
>> private key.
>> (4) Send the ciphertexts created in (2) and (3).
>> If I have this right, step (3) works on a plaintext of a size that
>> does not depend on the size of the original message. This suggests
>> that efficiency of step (2) is much more important than step (3).
> Correct, although it depends on the size of the message. If the
> public key operation is about 500 times as slow as the block cipher,
> than (for DES or IDEA) a 4K message will be 50% block encryption and
> 50% public key encryption.
> Bruce
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: 3DES in EDE mode versus EEE mode
Date: Thu, 21 Jan 1999 22:17:47 GMT
[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?
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.
The only EDE advantage is interoperability.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (A [Temporary] Dog)
Subject: Re: Pentium III...
Date: Thu, 21 Jan 1999 23:27:08 GMT
On Thu, 21 Jan 1999 13:18:47 +0100, fungus
<[EMAIL PROTECTED]> wrote:
>
>Do random number generators fall under export restrictions? I would
>say "only if they can be seeded and synched with other machines". If
>this isn't the case then I don't see how they can have problems. I'm
>sure a company like Intel has thought this through pretty carefully....
How difficult would it be to cripple the random number generator to
make an export version of the chip?
- A (Temporary) Dog |"There are people who can
The Domain is *erols dot com* |live and have many diverse
The Name is tempdog |experiences and learn
|nothing" - overheard
Put together as name@domain |in record store
------------------------------
From: [EMAIL PROTECTED] (A [Temporary] Dog)
Subject: Re: what is AES ??
Date: Thu, 21 Jan 1999 23:36:43 GMT
On Thu, 21 Jan 1999 15:26:35 -0500, "Michael T. Richter"
<[EMAIL PROTECTED]> wrote:
>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??
>
>AES is the (eventual) replacement for DES. Nobody can provide you with any
>source code or description of it because the algorithm hasn't yet been
>selected. There are a handful of algorithms being evaluated to become AES.
>(Things like CAST-256, RC6, TwoFish, etc.)
Check out http://csrc.nist.gov/encryption/aes/aes_home.htm . You can
get complete documentation on all the AES candidates there. You can
also order a free CD with the documentation, and , if you're a US
citizen, a free CD with both documentation and source code.
- A (Temporary) Dog |"There are people who can
The Domain is *erols dot com* |live and have many diverse
The Name is tempdog |experiences and learn
|nothing" - overheard
Put together as name@domain |in record store
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: 3DES in EDE mode versus EEE mode
Date: 22 Jan 1999 01:20:26 +0100
In article <7880d2$[EMAIL PROTECTED]>,
Frank Gifford <[EMAIL PROTECTED]> wrote:
> This is similar to how FM stereo is transmitted over the air. If it were
> designed today from scratch, a natural way to do it is to have the left
> and right channels broadcast separately on slightly different frequencies.
Nope -- instead it would be transmitted digitally.
> But, as it turns out, you broadcast the combination of them one one
> frequency, and the difference on another frequency.
Not quite -- they are broadcast on the same frequency, but the difference
is broadcast on a subcarrier on the main carrier.
> This allows the left and right halves to be extracted. Why the fuss?
> It's because some people only had mono FM receivers, but didn't want to
> pick up only one channel.
Color TV had the same problem: old B&W TV receivers should still
work. Therefore, instead of sending three R,G,B images separately on
three channels, a B&W image is broadcast as usual, and within that
color information is encoded such as to disturb the B&W images as
little as possible.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: simple symetric encrypt <-> decrypt
Date: Fri, 22 Jan 1999 01:01:43 GMT
In article <OZYo2.571$[EMAIL PROTECTED]>,
"Daniel Feurle" <[EMAIL PROTECTED]> 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
>
> I'm looking forward to hear from anyone!
The simplest way is to get your key K and xor it (binary exclusive or)
with your integer I, ie, K ^ I. To decrypt, do the exact same operation,
K ^ I. This is probably the most basic, easiest way to encrypt, and is
the basis for a good chunk of many 'homegrown' cryptosystems.
Saul Sabia
[EMAIL PROTECTED]
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 3DES in EDE mode versus EEE mode
Date: Fri, 22 Jan 1999 01:01:48 GMT
In article <7880d2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Frank Gifford) wrote:
> In article <787qga$ujf$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> > ... 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?
>
> There shouldn't be. The stated reason I've seen is the case where you
> effectively want a single key, but without having to reprogram the chip.
>
When just one key is used in 3-DES EDE, key schedule cannot be simply
repeated 3x in exaustive key search, which affords a slightly higher workload
per searched key than EEE in specialized hardware (and in software, of
course) that could pre-compute the key schedule just once for all 3x.
> This is similar to how FM stereo is transmitted over the air. If it were
> designed today from scratch, a natural way to do it is to have the left
> and right channels broadcast separately on slightly different frequencies.
> But, as it turns out, you broadcast the combination of them one one
> frequency, and the difference on another frequency. This allows the left
> and right halves to be extracted. Why the fuss? It's because some people
> only had mono FM receivers, but didn't want to pick up only one channel.
>
Actually, there are some further advantages to the way it currently is. When
you have a weak FM signal, interference from nearby stations, ghost
reflections from moutains (eg, on the road), you can turn stereo off -- which
then increases the signal/noise ratio; you get more range and less
interference from shadow reflections (mountains, buildings, etc.). Also, the
difference channel requires less bandwidth in adaptive digital systems --
since it is mainly a low-entropy correction signal. Last but not least, small
FM receivers are usually mono -- mainly because of lack of speaker space but
also to increase range with a cheaper product.
> So using EDE may be more a means of backward compatability as opposed to EEE
> being any weaker.
BW compatibility is a strong point, indeed, and I agree with you. But, as
above, EDE also makes attacks a bit more difficult for 3-DES than EEE, with
one-key, and specialized brute-force attack hardware less efficient.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck [EMAIL PROTECTED]
http://novaware.com.br
--- Meta-Certificate Group member -- http://www.mcg.org.br ---
============= 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: Fri, 22 Jan 1999 01:15:31 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Thu, 21 Jan 1999 19:37:32 GMT, [EMAIL PROTECTED] wrote:
>
> >It's pretty easy to generate extreemly high quality random numbers on a
> >typical PC at rates of 1000 bits/second.
>
> How is that be done such that no one can crack the resulting cipher
> given sufficient resources?
The method of random session key generation has nothing to do with ease of
brute force attacks on a specific cryptographic cipher. Cracking a 56-bit DES
key will take exactly the same computing effort (22 hours on Distributed.net)
no matter what the source of the key.
> For example, if you have a laptop with sensitive business material on
> it, and a competitor steals it, he may decide that it is worth 1
> million dollars to decipher your files.
I agree, long key's are good. None of the enhancements Intel has announced
will have any effect on the security of your data. Adding a thumbprint reader
or smart card reader or Dallas iButton reader (see http://www.ibutton.com)
would.
If anything, I think there is danger of a false sense of security. Just
because some computer has a Pentium III, with a processor serial number and
hardware random number generator doesn't mean it's any more or less secure
than a system with say an AMD K6-2 processor.
> Can the kind of random number generator you allude to above be
> adequate to prevent all but the most concerted attacks, like from the
> NSA?
Yes, I believe it's possible to generate very high quality random numbers,
without thermal noise hardware, like Intel is planning to add to the Pentium
III. Random number generators are used for key generation.
I have quite a lot of experience in this specific issue. I've written about
five generations of cryptographic random number generators for assorted
applications on Intel machines. The latest generation I believe makes
extreemly high quality random numbers.
> >The primary use for a processor serial number seems like it would be to
> >enforce software licenses. If I read the Microsoft OS license correctly, your
> >NOT allowed to move a copy of the OS from an old machine to a new machine.
> >The OS is licensed to a specific machine, which might be interpreted as a
> >specific processor.
>
> Just great! You buy a computer with an installed OS, the processor
> dies from infant morality, and now you got a major hassle on your
> hands.
>
> You would think the industry learned its lesson from the old days of
> closed architectures, key-based S/W, dongle keys, etc. I can just see
> Ziff Davis refusing to test anything that is Pentium III based.
At least a dongle would work with your replacement processor. Of cource if
your dongle breaks (or you loose it) you may be stuck. I like thumbprint or
retina scans more and more every day. Or a smart card, with a duplicate in
your safe deposit box (SDB).
- Jan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Jason Stratos Papadopoulos)
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: 22 Jan 1999 01:41:57 GMT
Fabrice Noilhan ([EMAIL PROTECTED]) wrote:
: According to <[EMAIL PROTECTED]>:
: > I find it hard to belive a pure C version could run any faster
: > if you allowed the assembly version to run on the same processor.
: > Sure maybe it goes 25% faser on the 68030 hardware than the
: > assembly on the 68020 but that might be due to HARDWARE speed
: > increased and not SOFTWARE.
: This was experienced for the DFC algorithm very recently. DEC's cc was
: faster than an assembly code. The reason is that this assembly-coded
: program was optimized for the 21064 and the compiler was good enough to
: do optimizations on the 21164. So, C code was faster than assembly code
: on the 21164 (on account of new instructions and different pairing).
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. What little assembly code I've written for
the Ultra runs over four times faster than what Sun cc generates
(and about 6x faster than gcc, which seems to write code for older
Sparc architectures exclusively).
OTOH, some careful C that I wrote runs 15% faster on the Pentium II than
a custom asm version, even though the asm runs stall-free on the Pentium.
Getting the C to run that fast in the first place, however, required
intimate knowledge of the assembly code djgpp generates. The same C code
takes twice as long when compiled for the Pentium with VC++, even with
full optimizations.
Unfortunately, the HLL-vs-assembly battle is a never-ending one, and we're
not going to resolve it here. My (wishy-washy) point of view is "don't
write in asm if you don't want to, but if you know how it can only help".
Anyway, I'm a nutcase, and when half the runtime ends up in one routine
I automatically drop into assembly.
jasonp
------------------------------
From: [EMAIL PROTECTED] (Jason Stratos Papadopoulos)
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: 22 Jan 1999 02:06:30 GMT
Jason Stratos Papadopoulos ([EMAIL PROTECTED]) wrote:
: Anyway, I'm a nutcase, and when half the runtime ends up in one routine
: I automatically drop into assembly.
Correction: if I optimize like nuts at a high level and half the
runtime *still* ends up in one routine I automatically drop into
assembly.
Bruce Schneier has written that the fastest Twofish code looks very
different on different flavors of Pentium; maximum performance by
necessity will be processor-dependent to some degree.
jasonp
PS: If this stuff is remotely interesting to you, follow some of the
links at Paul Hsieh's web page, in particular "The Great Debate".
------------------------------
** 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
******************************
