Cryptography-Digest Digest #76
Cryptography-Digest Digest #76, Volume #9Sat, 13 Feb 99 00:13:03 EST
Contents:
Re: New high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
Re: RNG Product Feature Poll (R. Knauer)
Re: Transforming RC4 into a one-way hash function (Bauerda)
WW-2 German Enigma Machine For Sale (webb)
Re: New high-security 56-bit DES: Less-DES ("lyal collins")
Re: Transforming RC4 into a one-way hash function ("Peter K. Boucher")
Re: Program Idea (Casey Sybrandy)
Re: SCOTT COMPRESSION ("Eric W Braeden")
Re: RNG Product Feature Poll (Patrick Juola)
Re: hardRandNumbGen (Patrick Juola)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: RNG Product Feature Poll (Patrick Juola)
Re: *** Where Does The Randomness Come From ?!? *** (Patrick Juola)
From: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Fri, 12 Feb 1999 23:29:29 GMT
[EMAIL PROTECTED] wrote:
2. To send a message to Alice, Bob forms the first part of his
desired message as a plaintext block of 64 bits:
M1 = 0123...63
I'd suggest the first block should carry 64-M bits of plaintext
(like the others) and M bits of random padding, in order to
resist known plaintext attack. If we can't add random bits, for
fear they will be deemed "key", we could defend against partially
known plaintext by taking the M-bit pad from a hash of the entire
message.
The Less-DES protocol may answer concerns regarding possibly
diverging interpretations of export-free or WA terms -- since there
is no additional key in Less-DES, of any kind, not even ignored, when
security is enhanced from the 56-bit level.
Alas, the way the regulations are implemented in the US, it's the
government's interpretation that carries the day. The rules do not
say that 56-bit or even 40-bit encryption systems are freely
exportable, and neither does the latest statment of intentions to
"relax" export restrictions.
Instead, there's a "one-time review". The various agencies are under
no obligation to permit export based on adhearence to the letter of
the WA or even the agencies' own guidlines. If one wants to argue
that a system falls within legal limits, he'll be making that argument
to government cryptographers.
In 1995, Kent Briggs sought to export of a system using 40-bit
Blowfish. He was told he'd have to cut it to 32 bits. Given the
relative key agility of Blowfish versus ciphers that did receive
fast-track export approval, we can conclude that the reviewers
looked at how long the system would actually take to break, and
not merely at technical conformity to key length limits.
Since that time, export authority for civilian encryption
software has ostensibly moved to the Department of Commerce. In
practice this means that people who know nothing about crypto have
a chance to deny (but not approve) export before the request even
crosses the desk of anyone who knows what he'd doing.
--Bryan
= Posted via Deja News, The Discussion Network
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Sat, 13 Feb 1999 00:33:38 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 12 Feb 1999 15:02:45 -0700, "Tony T. Warnock"
[EMAIL PROTECTED] wrote:
The probability of a 1-bit is 1/2. The probability of a 0-bit is 1/2. These are
taken over the entire sequence. The excess of 1-bits over 0-bits in the first N
bits is approximately N/log(N). This means that the frequency is 1/2 + 1/Log(N)
for 1-bits.
I thought the Champernowne number was only defined for an infinite
number of bits.
The absolute excess grows but the relative excess (which is the
probability in the limit) goes to zero.
1) What is meant by "absolute excess"?
2) What is meant by "relative excess"?
3) What does any of this have to do with the infinite Champernowne
number?
Bob Knauer
"The one thing every man fears is the unknown. When presented with this
scenario, individual rights will be willingly relinquished for the guarantee
of their well being granted to them by their world government."
--Henry Kissinger
--
From: [EMAIL PROTECTED] (Bauerda)
Subject: Re: Transforming RC4 into a one-way hash function
Date: 13 Feb 1999 00:35:51 GMT
You want to overcome RC4's weakness that the last few bytes of a long
key have less effect than the first few bytes, right? What do you think
of the following?
1) At the time your hashing software is being developed, generate 1013
"random" bytes, R, and hard-code them into your software.
Why bother with that many? I would say that only 8 to 256 bytes would be more
resonable.
2) At run-time,
a) take the message, M, and make a copy in the reverse-order, call it
rM
b) XOR M and rM together, making xM.
I don't like this. M is not used any where else, so if it has any symetric
Cryptography-Digest Digest #77
Cryptography-Digest Digest #77, Volume #9Sat, 13 Feb 99 12:13:01 EST
Contents:
SFS Iomega (Michael Hortmann)
Re: What is left to invent? (Gurripato (x=nospam))
Re: RNG Product Feature Poll (Dave Knapp)
Re: New high-security 56-bit DES: Less-DES (TONY BARTOLETTI)
Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come From
?!? *** ) (Seisei Yamaguchi)
Re: Tell-Tale DES Byte-Length Encoding ([EMAIL PROTECTED])
Re: Java random ("Else")
Re: New high-security 56-bit DES: Less-DES ("Steve Sampson")
Re: RNG Product Feature Poll (Herman Rubin)
Re: SCOTT COMPRESSION ([EMAIL PROTECTED])
Re: Metaphysics Of Randomness (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
Re: RNG Product Feature Poll (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
From: [EMAIL PROTECTED] (Michael Hortmann)
Crossposted-To: alt.security.pgp
Subject: SFS Iomega
Date: Sun, 07 Feb 1999 09:47:19 +0100
I've been using Peter Gutmann's SFS (Secure File System)
for several years under DOS/Windows3.x/Windows95 to encrypt
a partition of my hard disks or diskettes. I'd really like
to use it for my Iomega ZIP and JAZ media, too.
Does anyone know of a way to do this?
Or is there another good cryptographic file system for
Windows95 which can be used instead?
Michael Hortmann
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Certified PGP Key http://www.trustcenter.de
--
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: What is left to invent?
Date: Fri, 12 Feb 1999 08:22:35 GMT
On Thu, 11 Feb 1999 01:09:43 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
"It is not a matter of what is true that counts, but a matter of
what is perceived to be true."
--Henry Kissinger
I knew Kissinger had a PhD, but didn´t know it was on quantum
physics!
--
From: Dave Knapp [EMAIL PROTECTED]
Subject: Re: RNG Product Feature Poll
Date: Sat, 13 Feb 1999 09:36:33 GMT
R. Knauer wrote:
On Fri, 12 Feb 1999 06:23:47 -0500, "Trevor Jackson, III"
[EMAIL PROTECTED] wrote:
A white, uniform generator might work, but that phrase will
trigger a lot of questions of the form "please define white"
and "please definer uniform".
I believe the term "uniform distribution" is well defined in
statistics. However, as Li and Vitanyi point out in their book on
Kolmogorov Complexity, it is not sufficient to characterize
randomness.
That's why you _specify_ a *random* uniform generator, instead of just a
uniform generator.
Random implies no correlation, and uniform implies no bias.
Why are you guys making this so complicated?
I understand that it is difficult, a priori, to establish whether a
particular source is random or not. But that complexity does NOT affect
the _definition_ of "random," which is quite solid. There are many ways
to express it; but fundamentally, it means lack of correlation.
-- Dave
--
From: TONY BARTOLETTI [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Sat, 13 Feb 1999 09:40:08 GMT
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
2. To send a message to Alice, Bob forms the first part of his
desired message as a plaintext block of 64 bits:
M1 = 0123...63
I'd suggest the first block should carry 64-M bits of plaintext
(like the others) and M bits of random padding, in order to
resist known plaintext attack. If we can't add random bits, for
fear they will be deemed "key", we could defend against partially
known plaintext by taking the M-bit pad from a hash of the entire
message.
The Less-DES protocol may answer concerns regarding possibly
diverging interpretations of export-free or WA terms -- since there
is no additional key in Less-DES, of any kind, not even ignored, when
security is enhanced from the 56-bit level.
Alas, the way the regulations are implemented in the US, it's the
government's interpretation that carries the day. The rules do not
say that 56-bit or even 40-bit encryption systems are freely
exportable, and neither does the latest statment of intentions to
"relax" export restrictions.
Instead, there's a "one-time review". The various agencies are under
no obligation to permit export based on adhearence to the letter of
the WA or even the agencies' own guidlines. If one wants to argue
that a system falls within legal limits, he'll be making that argument
to government cryptographers.
Yes, I tend to agree. They define what the rules mean, case-by-case.
But this argues for Ed's first (bit more cumbersome) proposal, M-DES.
Everyone just uses plain-old-already-approved DES. But there is an
"established" table of 2^14 64-bit "random" strings published.
I DES encrypt a message, but XOR all of the output blocks with one
string randomly selected
Cryptography-Digest Digest #78
Cryptography-Digest Digest #78, Volume #9Sat, 13 Feb 99 21:13:04 EST
Contents:
Re: RNG Product Feature Poll (R. Knauer)
Re: SCOTT COMPRESSION ("karl malbrain")
norton's for your eyes only (michael c henry)
Re: hardRandNumbGen ("karl malbrain")
Re: RNG Product Feature Poll (R. Knauer)
Microsft crypto headdump.cpp ("John")
Re: RNG Product Feature Poll (Dave Knapp)
Re: Intel's description of the Pentium III serial number (Peter Gutmann)
Re: Tell-Tale DES Byte-Length Encoding (wtshaw)
How does the Enigma Machine work? ("David")
Re: norton's for your eyes only (JPeschel)
Re: SSL Doc (Divon Lan)
Help! Cryptosystem needed. (Divon Lan)
Re: Help! Cryptosystem needed. (Ross Younger)
Re: How does the Enigma Machine work? ("Steve Sampson")
Re: How does the Enigma Machine work?
Re: Help! Cryptosystem needed. ("Steve Sampson")
Re: Tell-Tale DES Byte-Length Encoding ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Sat, 13 Feb 1999 16:12:58 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 13 Feb 1999 09:36:33 GMT, Dave Knapp [EMAIL PROTECTED] wrote:
That's why you _specify_ a *random* uniform generator, instead of just a
uniform generator.
Random implies no correlation, and uniform implies no bias.
The definition above is still circular. Using your concepts you would
want to specify an "uncorrelated uniform generator" to characterize a
TRNG. I believe that "uncorrelated" and "uniform" are sufficient to
specify a TRNG for use with the proveably secure OTP cryptosystem.
BTW, how would you propose testing for correlation?
Why are you guys making this so complicated?
That's because it is a complicated subject. The closest one comes to
crypto-grade randomness is Quantum Mechanics, a very complicated
subject indeed.
I understand that it is difficult, a priori, to establish whether a
particular source is random or not. But that complexity does NOT affect
the _definition_ of "random," which is quite solid.
There is only one defintion of the term "random" in cryptography with
regard to the proveably secure OTP system (which is what we are
discussing):
"A crypto-grade random number is one produced by a TRNG which is
capable of generating all possible finite numbers equiprobably."
Such numbers do not exhibit any correlation. Even the sequence that
starts off like 101010... can unpredictably shift to some other bit
sequence for absolutely no reason.
There are many ways
to express it; but fundamentally, it means lack of correlation.
Berry's Paradox: "A random number cannot be described by fewer bits
than its length."
Yet I just described a random number in 66 * 5 = 330 bits (using a
5-bit alphabet code), which I suppose that makes every number longer
than 330 bits non-random.
The point is that you cannot describe a random number or you end up
with a paradox. The best you can do is characterize the generation
process and that depends on the application.
In our case, the specification of a TRNG is the correct description
for the proveably secure OTP cryptosystem.
Bob Knauer
"The one thing every man fears is the unknown. When presented with this
scenario, individual rights will be willingly relinquished for the guarantee
of their well being granted to them by their world government."
--Henry Kissinger
--
Reply-To: "karl malbrain" [EMAIL PROTECTED]
From: "karl malbrain" [EMAIL PROTECTED]
Subject: Re: SCOTT COMPRESSION
Date: Sat, 13 Feb 1999 09:12:24 -0800
[EMAIL PROTECTED] wrote in message
news:7a3uko$9jv$[EMAIL PROTECTED]...
It is well known my English sucks. But I don't think I meant buffering.
(...)
But in the compression
program I am writing I will chop the file up so that one could either
(buffer) the
whole file or use the method on a(n) unbuffered conti(n)u()ous stream of
data. The first and
third pass will be all the way forward passes but the second pass will be
the
chopped (buffered) reverse pass (...)
In any event, again, from a LINEAR perspective, analysis depends only on
having access to all of the data EVENTUALLY. Any particular method of
CONFUSION can be REVERSED. Karl M
--
From: michael c henry [EMAIL PROTECTED]
Subject: norton's for your eyes only
Date: Sat, 13 Feb 1999 12:01:47 -0500
all,
recently i read a critical analysis of norton's
crypto product "for your eyes only".
now i can't locate it.
can anyone out there point me towards it?
thanks,
mike
--
--
Reply-To: "karl malbrain" [EMAIL PROTECTED]
From: "karl malbrain" [EMAIL PROTECTED]
Subject: Re: hardRandNumbGen
Date: Sat, 13 Feb 1999 09:28:03 -0800
R. Knauer [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
On 11 Feb 1999 15:42:48 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
(...)
Think of it this way. Assume you have a biased, but independent, bit
source that
