Cryptography-Digest Digest #136, Volume #9 Thu, 25 Feb 99 07:13:05 EST
Contents:
Re: Define Randomness (Patrick Juola)
Re: Define Randomness (Patrick Juola)
Chat with Lois Gresh (The Termination Node), 2/24 at 6:00 pm Pacific (Steve Brock)
Re: Define Randomness ("Trevor Jackson, III")
Re: True Randomness - DOES NOT EXIST!!! (Matthias Meixner)
Re: Another extension to CipherSaber (Paul Rubin)
Re: A New Public-Key Cryptosystem (Somniac)
Q: is there any SRP/SSH/encrypted telnetd/encrypted ftpd SERVER (not client) for
Windows NT? (KloroX)
ElGamal key generation ("Erwin Molendijk")
Re: Define Randomness (R. Knauer)
Quantum Computation and Cryptography ("Benjamin Johnston")
Re: Pentium III Hardware Random Numbers ("Jay")
Re: RC4 40 bit compared to RC4 128 bit. (EKR)
Re: Snake Oil (from the Feb 99 Crypto-Gram) (Peter Gutmann)
Re: VxD Crypto - Win 95/98/NT (Peter Gutmann)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Define Randomness
Date: 24 Feb 1999 17:33:41 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Wed, 24 Feb 1999 16:31:56 -0500, "Trevor Jackson, III"
><[EMAIL PROTECTED]> wrote:
>
>>> That generator is not crypto-grade random. If you used keystreams from
>>> that RNG you would leak significant amounts of information.
>
>>Not true. There are simple transforms that will remove the bias without
>>imposing any additional order (bias) on the sequence. The biasless
>>transformed sequence will not leak any information.
>
>As I commented earlier, such anti-skewing procedures must be included
>into the specification for the TRNG.
>
>Now here's the question for you - do these anti-skewing procedures
>introduce correlations into the keystream? After all, they are
>algorithmic, which means they produce a pattern.
i) Algorithmic doesn't mean that they produce a pattern. It just
means that they operate in a predictable fashion in the patterns
randomly (and spuriously) found in data.
ii) The von Neuman pairwise transformation provably does not introduce
a bias into a stream *if* the stream is composed of independent events.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Define Randomness
Date: 24 Feb 1999 16:04:00 -0500
In article <7b1mru$[EMAIL PROTECTED]>,
Alan DeKok <[EMAIL PROTECTED]> wrote:
>In article <7b14dd$qb9$[EMAIL PROTECTED]>,
>Patrick Juola <[EMAIL PROTECTED]> wrote:
>>In article <7b13hs$[EMAIL PROTECTED]>,
>>Alan DeKok <[EMAIL PROTECTED]> wrote:
>>>
>>> And from Chaitin, there is no one method by which to determine the
>>>difference between a PRNG and a TRNG. So *any* tests are necessarily
>>>incomplete.
>>
>>Possibly incomplete. But the incompleteness is largely theoretical
>>when you're talking about design analysis.
>
> *necessarily* incomplete. You point this out below, where you
>state:
Oh, only possibly. There's also the possibility that the tests
might be incorrect (or inconsistent). 8-)
>>It's reasonable to claim that "an indistinguishable difference
>>doesn't make a difference." But you can't then go on and define
>>an acceptable set of methods for distinguishing.
>
> That's what I said, in different words.
>
>>There's a big difference between inspecting the design of a generator
>>and examining only the output sequences produced by a generator.
>
> Oh, of course. However, the set of methods/tests for distinguishing
>PRNG from TRNG also includes methods of analyzing the design of
>generators, so you're stuck. :)
>
> That being said, it's a lot easier to analyze algorithms than huge
>bit streams.
And most of the time you don't want a complete test anyway. A tri-state
test : provably acceptable, provably unacceptable, unknown, is fine
for most purposes. Just don't use anything provably unacceptable *or*
unknown.
-kitten
------------------------------
Crossposted-To:
alt.2600,alt.fan.cypher,rec.arts.sf.announce,rec.arts.sf.fandom,rec.arts.sf.written,talk.politics.crypto
From: [EMAIL PROTECTED] (Steve Brock)
Subject: Chat with Lois Gresh (The Termination Node), 2/24 at 6:00 pm Pacific
Date: Thu, 25 Feb 1999 05:45:28 GMT
Chat with Lois Gresh
Wednesday, February 24 at 6:00 pm PT - Lois Gresh in #Reading_1. Gresh's new
book is "The Terminal Node." Internet security specialist Judy Carmody has
never seen anything like the cyberheist that instantly vaporized the assets
of a major bank. And the masterminds intend to stay hidden--by eliminating
anyone who could possibly stop them.
To get to the chat room, launch your favorite chat software, connect ro
server chat.msn.com, and go to room/channel #Reading_1. Hope to see you
there.
Steve Brock
Community Manager
Books and Reading Community
Microsoft Network
http://communities.msn.com/reading
------------------------------
Date: Wed, 24 Feb 1999 23:53:30 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Define Randomness
R. Knauer wrote:
> On Wed, 24 Feb 1999 16:38:52 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >> You need an unbiased generator for it to be crypto-grade random.
>
> >Not quite. Any biased generator that captures entropy can be transformed
> >by the addition of a post filter into an unbiased generator. The
> >generation cost goes up as the inverse of the filtration ratio. In essence
> >we can retain the entropy of the output and discard the redundancy in the
> >output.
>
> See my earlier comments. The anti-skewing procedure becomes part of
> the TRNG specification.
>
> >The entropy density goes down as the bias goes up. So the data rate
> >(bits/time)of a derived unboased generator will be 1/999 of the biased data
> >rate, but the information rate (entropy/time) will be the same.
>
> What about the possibility of introducing fatal correlations by
> anti-skewing procedures?
>
> >> Therefore in order for a TRNG to be *capable* of outputting a normal
> >> number, it cannot have any bias in its implementation.
>
> >No. This conclusion is unwarranted.
>
> I insist that the anti-skewing procedure be part of the overall TRNG
> specification. Otherwise the TRNG cannot meet specs. IOW, the TRNG
> specification is "out of the box". You can use the output directly
> without any further processing.
>
> But, I do not trust algorithmic post processing. You will have to
> convince me that anti-skewing does not introduce unwanted correlations
> which can wreck the security of the TRNG significantly.
Rather than demanding that someone prove a negative for you, consider offering
an example of the problem you suspect exists.
------------------------------
From: [EMAIL PROTECTED] (Matthias Meixner)
Subject: Re: True Randomness - DOES NOT EXIST!!!
Date: 25 Feb 1999 08:15:51 GMT
BRAD KRANE ([EMAIL PROTECTED]) wrote:
>
>
> True randomness does not exist. It always depends on some variable
> at some *FIXED* time. FIXED times are not anywhere near random.
> **EVERY** thing that goes on in the universe is hapening because of all
> the forces of **EVERY** thing else in the entire universe. If you where
> to take mesurements at one place in time in one universe and recorded
> it. Then lets say you where able to re-create exactly the universe you
> where just in some where else and you took the exact same measurement
> the so called random number that you recorded before would be the exact
> same as though you took the measurement in the first universe. As
> everyone knows the universe is CONSTANT if you have events that lead up
> to a conclusion and if those exact same events happened again you would
> obtain the same result. You cant acheive TRUE randomness, you can only
> push the odds so far back that the average number of times it would take
> for some one to "find" the same result that you came up with would take
> and incredible ammount of time and energy that it is infeasible to even
> attempt to get that result.
>
So you say everything is predetermined, since it totally depends on all
forces of every thing else in the universe.
So your post and my answer are predetermined.
If I kill you, its not my fault, since it is also predetermined.
You can make a religion out of it and nobody can prove it to be wrong of
course, it is just a matter of believe.
--
Matthias Meixner [EMAIL PROTECTED]
Technische Universit�t Darmstadt
Rechnerbetriebsgruppe Telefon (+49) 6151 16 6670
Wilhelminenstra�e 7, D-64283 Darmstadt, Germany Fax (+49) 6151 16 4701
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Another extension to CipherSaber
Date: Thu, 25 Feb 1999 07:29:34 GMT
In article <7au2s0$[EMAIL PROTECTED]>, Jay <[EMAIL PROTECTED]> wrote:
>Also, regarding the earlier suggestion of ASCII armoring, we already have
>universal standards (like binhex or UUEncode) which accomplish this.
>Ciphersaber is primarily meant to be easily implemented, and interoperable,
>adding another level of complexity works against this critical function.
I don't think the existence of standards like binhex or UUEncode
should matter much for Ciphersaber. If we're going to assume
access to software that implements every known standard, we may
as well use standard crypto protocols like PGP or S/mime.
I feel the spirit of Ciphersaber is to make something that can be
quickly reimplemented from scratch in just about any programming
environment and give a way to make interoperable encrypted messages.
Since binary files don't interact well with mail systems and since
encoding methods like binhex or uuencode only work on systems which
include them or let you install them somehow, it's best if Ciphersaber
doesn't use binary *and* doesn't depend on any external armoring
programs.
So I believe Ciphersaber should do its own armoring. Either a 6-bit
per char encoding or straight hexadecimal (4 bits/char) are reasonable
choices, hex being less efficient but easier to implement. Hex might
reasonably be considered to be more in the ultra-simple Ciphersaber
spirit. If both people have access to external software in addition
to Ciphersaber, they can data-compress (e.g. gzip) both the input
and the output and get smaller files that way.
------------------------------
From: Somniac <[EMAIL PROTECTED]>
Subject: Re: A New Public-Key Cryptosystem
Date: Thu, 25 Feb 1999 02:18:35 -1000
Lowball61 wrote:
>
> Can anyone answer any of the questions posed in the short paper titled "A New
> Public-Key Cryptosystem?" posted in sci.crypt.research?
> Charles Larry Craig
A New Public Key System
This brief paper discusses the possibility of extending the Hill
cipher to
function as a public-key cryptosystem (PKC). Since the public-key would
be a
series of tables derived from a rectangular matrix, and since the
encryption
process consists of selecting an entry from each of the tables and XORing
the
selected entries together, a fundamental question arises as follows:
given a
block of encrypted text and the public key, can one derive the entries
that
were selected
and XOR'd together to produce the encrypted text at a reasonable cost in
terms
of work factor. The author of this paper believes that, to accomplish the
decrypt in an unprohibited time span, a rectangular matrix similar to the
table-generating matrix must be derived first. Even then, another
fundamental
question remains: could the rows which were XOR'd together to produce the
selected entries be determined within a reasonable time span.?
What follows is a brief introduction to the extended Hill cipher,
without
going into its details.
The Hill cipher encrypts by multiples (mod i) the transform of a
vector,
P', by a non-singular matrix M:
P'M = C'
The vector C' is decrypted by multiplying it by the inverse of M, N:
C'N = P'
Given M, N can be computed.
If i=2 (so that adds are exclusive-ors and all multiplies are just
row
selections or omissions) then M can be disguised by pre-adding all
combinations
of a number of rows together. Then with a set of elements from P',
performing a
series of table-lookups, the product P'M can be obtained by just adding
together the results of all the table-lookups because
(((a+b)+c)+d)+... = (a+b)+(c+d)+...
where a+b is the results of the first table-lookup (or the product of the
first
k elements of P' and the first k rows of M, and so forth.
Although this disguises M to some extent, the basic for M can still
be
computed, perhaps obtains M* instead of M. From M*, N* could be computed
and
C' could be decrypted by
C'N* = P'
Now suppose M was not a square matrix but the product of a
rectangular
matrix R of a special form and a non-singular, disguising square matrix
D.
RD = M
Further suppose that a non-linear transform J, interrelated with R,
is
first performed on P' to produce Q', an expanded vector which has as
many
elements as M has rows. Then Q' is encrypted by multiplying it and M
together
Q'M = C'
The vector C' is decrypted by first multiplying it by a square
matrix N
(the inverse of D)
C'N = W'
to obtain W' on which the combination of the inverse of the non-linear
transform of J and inverse of the multiplication by R can be obtained
(inverse of J and R)(W') = P'
Now, from the nature of J and R, if their nature were widely known,
one
might crack the code by generating some square matrix N*, which when
multiplied
by M, products a matrix R* of the same general form as R
MN* = R*
Then C' might be decrypted by multiplying it by N* to product W*
C'N* = W*
and performing the inverse operation
(inverse of J* and R*)(W*) = P'
However, suppose that M is disguised by pre-adding all combinations
of a
number of rows together to produce a series of tables allowing
table-lookups to
be performed, using a series of sets of elements of V', in such a manner
that
the non-linear transform J was simultaneously accomplished. Then suppose
that
the results of the series of table-lookups could be added together to
product
the same C' as generated previously.
Suppose further that M is pre-multiplied by a "shuffle" matrix S (an
identity matrix I that has been "shuffled") to obtain M*
SM = M*
from which the series of tables are generated. This tactic effectively
hides
those elements of P' are used in the series of table-lookups (that is, it
hides
which elements of P' are used each of the table-lookups, from the
perspective
of not being able to determine the characteristics of R ).
In view of the foregoing, would such a cipher system be secure as a
public
key (the series of tables being the public key) even if the general
nature of
the non-linear transform J and the interrelated matrix R were known (but
not
their particulars)? Is there some general algebraic method of solving
for P',
given C' and the series of tables? If so, what is it?
Charles Larry Craig
________________________________________________
Dear Mr. Craig, what is Mrs. Hill's first name?
Where was the Hill algorithm published?
Do you have a website where more details are given?
Is there an on-line copy of the Hill paper?
------------------------------
From: [EMAIL PROTECTED] (KloroX)
Subject: Q: is there any SRP/SSH/encrypted telnetd/encrypted ftpd SERVER (not client)
for Windows NT?
Date: Thu, 25 Feb 1999 11:00:55 GMT
Reply-To: [EMAIL PROTECTED] (this is spam bait)
I have been saked to look for and install secure telnet/ftp/rlogin
services on an NT server. I am already aware that there are several
freeware/shareware/commercial client applications (which are not the
subject of this request), but I found nothing at all for server
software running under Windows NT. All I found are dozens of Unix and
Linux packages. Can anyone help?
------------------------------
From: "Erwin Molendijk" <[EMAIL PROTECTED]>
Subject: ElGamal key generation
Date: Thu, 25 Feb 1999 11:17:15 +0100
I want to generate a key for use with the ElGamal public-key encryption
algorithm.
To generate a key pair, one uses this formula:
y=(g^x) mod p
Where p is a prime, g and x are random numbers smaller than p.
The public key is: y,g and p
The secret key is: x
My questions:
1. Since p is public, can I use the same prime for all keys?
2. What size (in bits) should the p, g and x have? (eg. 2048?)
Regards,
Erwin
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Define Randomness
Date: Wed, 24 Feb 1999 22:06:21 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 24 Feb 1999 16:38:52 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> You need an unbiased generator for it to be crypto-grade random.
>Not quite. Any biased generator that captures entropy can be transformed
>by the addition of a post filter into an unbiased generator. The
>generation cost goes up as the inverse of the filtration ratio. In essence
>we can retain the entropy of the output and discard the redundancy in the
>output.
See my earlier comments. The anti-skewing procedure becomes part of
the TRNG specification.
>The entropy density goes down as the bias goes up. So the data rate
>(bits/time)of a derived unboased generator will be 1/999 of the biased data
>rate, but the information rate (entropy/time) will be the same.
What about the possibility of introducing fatal correlations by
anti-skewing procedures?
>> Therefore in order for a TRNG to be *capable* of outputting a normal
>> number, it cannot have any bias in its implementation.
>No. This conclusion is unwarranted.
I insist that the anti-skewing procedure be part of the overall TRNG
specification. Otherwise the TRNG cannot meet specs. IOW, the TRNG
specification is "out of the box". You can use the output directly
without any further processing.
But, I do not trust algorithmic post processing. You will have to
convince me that anti-skewing does not introduce unwanted correlations
which can wreck the security of the TRNG significantly.
Bob Knauer
"Democracy is the theory that the common people know what they
want, and deserve to get it good and hard."
--H.L. Mencken
------------------------------
From: "Benjamin Johnston" <[EMAIL PROTECTED]>
Subject: Quantum Computation and Cryptography
Date: Thu, 25 Feb 1999 21:27:08 +1100
I read somewhere, a while ago, that Quantum computers, if or when they are
created, will turn an otherwise difficult factorization into a trivial task.
Will all the current cryptosystems be outdated, the instant a stable and
practical quantum computer is created?
Are there any cryptographic algorithms designed to be secure against quantum
computers?
What about algorithms secure against quantum computer cryptanaysis, but
require a quantum computer for encryption?
Does anybody have any personal opinions/predictions about the ramifications
of such new technology/s.
Thanks,
Benjamin Johnston
[EMAIL PROTECTED]
------------------------------
From: "Jay" <[EMAIL PROTECTED]>
Subject: Re: Pentium III Hardware Random Numbers
Date: Thu, 25 Feb 1999 06:19:21 -0500
Terry Ritter wrote in message <[EMAIL PROTECTED]>...
>
>On Wed, 24 Feb 1999 21:19:15 GMT, in
><7b1qca$akc$[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED]
>wrote:
>
>>Is there some compelling reason why we should trust Intel?
>
>Nope. No more than we would trust, say, Schneier.
>
Schneier has a consistent history of supporting privacy. Intel, as we have
recently seen, does not.
Also, I wonder about the assumptions in this list of "thermal noise=good."
Theoretically yes, but with mass produced hardware needed to support the
thermal noise generator, the signal coming out of such a generator is at
best pink. In fact, the individual characteristics of particular chips may
actually produce an inadvertent signature in the bit stream.
Jay
------------------------------
From: EKR <[EMAIL PROTECTED]>
Subject: Re: RC4 40 bit compared to RC4 128 bit.
Date: 24 Feb 1999 20:30:12 -0800
"Steve Sampson" <[EMAIL PROTECTED]> writes:
> I believe that Netscape uses only 128 bit RC4, and for export versions it
> uses a 40 bit key, with the rest of the 128 bits being NULL.
This is incorrect. SSL uses 128 bit RC4. The key is created
using a message digest of a large shared secret. In 40-bit
mode, only 40 bits of secret data are used as input to the
key derivation function. There are a lot more inputs, but
they're public. No key bits are set to zero.
RC4 is an adjustable length cipher so the keys are also variable
length. So it's possible to use RC4 with a 40 bit key. However,
this is not how SSL works, and it's generally a bad idea because
it's susceptible to a table driven attack where you precompute
the keystream for all 2^40 keys.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Snake Oil (from the Feb 99 Crypto-Gram)
Date: 25 Feb 1999 10:25:56 GMT
[EMAIL PROTECTED] (Lutz Donnerhacke) writes:
>* Mark Andreas wrote:
>>Bruce Schneier wrote:
>>> Some companies claim "military-grade" security. This is a meaningless
>>> term. There's no such standard. And at least in the U.S., military
>>> cryptography is not available for non-government purposes (although
>>> government contractors can get it for classified contracts).
>>
>>The first time I remember seeing this phrase was when using the
>>command-line version of PGP 2.6 using the -kg switch to generate a key.
>>Choice #3 was:
>>3) 1024 bits- "Military" grade, slow, highest security
>That's why PGP 2.6.3(i)n changed this to:
> 1024 bit - User grade
> 1535 bit - SubCA and RA grade
> 2048 bit - CA grade
... which those for whom it's most important (nontechnical types) will have
absolutely no understanding of. Although the term "military-grade security"
is meaningless, it seems to be one of the better ways to tell J.Random Luser
that this is the strongest level of security available in a program. Having
said that, I'd never use it in anything I wrote.
Peter.
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: VxD Crypto - Win 95/98/NT
Date: 25 Feb 1999 10:33:06 GMT
"R H Braddam" <[EMAIL PROTECTED]> writes:
>Eatpages.VxD could also serve as a starting point for a
>secure memory allocator for Crypto functions. A VxD can
>map a pointer to its page-locked memory to an
>application's address space. A lot is needed to convert
>it to a memory allocator and manager, though.
Both parts of this already exist, all you need is someone to glue the two
together. The VxD allocator is the SCNSM driver, available from
http://soundcode.com/content/download/products/scnsm/, the memory manager (or
at least the one I'd use) is Doug Lea's malloc,
http://gee.cs.oswego.edu/dl/html/malloc.html. I looked at combining the two a
few months back, but other things kept getting in the way.
Peter.
------------------------------
** 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
******************************
