Cryptography-Digest Digest #403, Volume #12 Thu, 10 Aug 00 18:13:00 EDT
Contents:
EGD based on Yarrow for Windows?? (Ian Upright)
EGD's.. (Ian Upright)
Re: OTP using BBS generator? (Terry Ritter)
Re: Perfect double hashing of known data set (John Myre)
Re: 1-time pad is not secure... ("Tony T. Warnock")
Re: Destruction of CDs (Mok-Kong Shen)
Re: Multiple encryption passes (Mok-Kong Shen)
Re: Multiple encryption passes (Terry Ritter)
Re: 1-time pad is not secure... ("Trevor L. Jackson, III")
Re: Secrets and Lies: New Book by Schneier (Larry Kilgallen)
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: EGD's.. ([EMAIL PROTECTED])
Re: Destruction of CDs (tomstd)
Re: Secrets and Lies: New Book by Schneier (tomstd)
Re: BBS and the lack of proof (tomstd)
Re: newbie question on public key lengths ("Joseph Ashwood")
Re: BBS and the lack of proof (tomstd)
----------------------------------------------------------------------------
From: Ian Upright <[EMAIL PROTECTED]>
Subject: EGD based on Yarrow for Windows??
Reply-To: [EMAIL PROTECTED]
Date: Thu, 10 Aug 2000 21:06:14 GMT
I'm looking for an Entropy Gathering Daemon (that provides a socket for
generating random data), compatible with OpenSSL, and runs on Windows.
Ideally, something based on Yarrow. Does anyone know of anything like this
or where I could download it?
Thanks, Ian
------------------------------
From: Ian Upright <[EMAIL PROTECTED]>
Subject: EGD's..
Reply-To: [EMAIL PROTECTED]
Date: Thu, 10 Aug 2000 21:07:44 GMT
Where do I find out more about the exact protocol of the EGD daemon?
Is /dev/random and /dev/urandom also the same protocol?
Ian
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: OTP using BBS generator?
Date: Thu, 10 Aug 2000 21:12:06 GMT
On Thu, 10 Aug 2000 13:47:13 -0600, in <[EMAIL PROTECTED]>,
in sci.crypt John Myre <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
><snip>
>> * THERE IS NO QUESTION that if we select x0 at random, sooner or
>> later we *WILL* select a short cycle.
><snip>
>
>No.
>
>If an event has sufficiently low probability, then it is perfectly
>sane and reasonable to design a system assuming it will never
>happen. The system will have a finite lifetime. Depending on
>the actual probabilities, it is certainly possible that the
>unlikely will in fact fail to happen at all.
No. This discussion has not been concerned with practical weakness
per se, but instead the claim that such a system is "proven secure."
The examples have amply demonstrated that such a system may be weak.
So we find that the "proven strength" did not in fact imply strength
in every case, just in most cases.
The issue is "proof," and to understand that we need to know what
happens in *every* case, not just a handwave representing the majority
of cases. Claiming that reduced BB&S is secure in every x0 selection
is obviously just plain wrong. Knowing that, we can see that the most
the proof can possibly mean is that in *other* cases, BB&S is strong.
In practice, the whole reason for using BB&S is to get a proof of
strength; most people probably think means that there simply are no
weaknesses. Yet here we have a case -- and there is no reason to
think that short cycles are the only case -- where the system *is*
*unarguably* *insecure*, and that case is known but not even checked
for. In this situation, a claim of "proven secure" would be
inappropriate.
I suggest "proven almost never weak."
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Perfect double hashing of known data set
Date: Thu, 10 Aug 2000 15:02:14 -0600
(Actually I can't see the point here, but I'm answering anyway.)
Jim Idle wrote:
<snip>
> Using a fixed length 256 byte string, in which each byte can take the value
> 0x00 to 0xFB, is it possible to construct two hashing algorithms under the
> following contraints:
>
> 1) That for all possible inputs, the algorithms will not produce the same
> hash pair for two different inputs (note that if the output were two small
> numbers [for the sake of argument] then 4,5 and 5,4 are not considered the
> same pair);
>
> 2) That the two algorithms produce an output that collectively is less than
> (256*8)-1 bits;
<snip>
Calling the output a hash pair, and saying there are two algorithms,
doesn't seem to mean anything, because you have no requirements on
either algorithm/hash on it's own. So really you're asking for one
hash algorithm, with certain requirements.
Also, you don't define what you mean by "hash" here. In this newsgroup,
a "hash" is expected to be "cryptographically strong", which in turn
denotes properties that are useful in constructing secure systems.
On the other hand, "perfect hashing" is a term of art from computer
science, where a "hash" is defined quite differently, for quite
different purposes.
The only properties you have actually mentioned specifically is that
there should be no collisions on the 256-byte sequences you define,
and the output should be at least one bit shorter than the input.
Any lossless compression algorithm that actually compresses all of
your inputs by at least one bit satisfies these requirements.
An example would be to treat the input as a string of digits for
a number, represented in base 252 (0xFC). Compute the digits for
representing this number in base 256. This will take fewer bits.
JM
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Fri, 11 Aug 2000 03:15:04 -0600
Reply-To: [EMAIL PROTECTED]
"Trevor L. Jackson, III" wrote:
> Guy Macon wrote:
>
> > Mike Calder wrote:
> >
> > >It may be unpredictable, but does that make it random?
> >
> > For use as the key in a one time pad, isn't unpredictable good enough?
>
> Necessary in fact. If the sequence is truly random but predictable it is
> worthless. A truly random sequence is predictable if it has been revealed --
> using it as a key counts as revelation.
This is the "one" in one-time-pad. Any two encryptions (or computations) done
with the same set of [pseudo]/[quasi]/[truly]/[hopefully]-random streams are
correlated. 1=1=1=1=1=1=1=1=1=1=1=1....
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Destruction of CDs
Date: Thu, 10 Aug 2000 23:29:52 +0200
Mickey McInnis wrote:
>
> Melting/burning would be better, but I would be concerned about toxic
> byproducts. Stir the resultant puddle or ashes.
Dumb question: Of what kind of chemical materials are CDs made?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Multiple encryption passes
Date: Thu, 10 Aug 2000 23:29:47 +0200
ArchimeDES wrote:
>
> On Wed, 09 Aug 2000 16:25:52 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
> [...snip..-]
> >>Security by obscurity?
> >>Hmmm, the security of a cryptosystem is not given by the secrecy of
> >>the algorithm used, only by the secrecy of the key (Principle of
> >>Kerckoffs).
> >
> >Presumably, cipher selection would be part of the key.
> >
> >It would be known that the system used multiple different ciphers.
> >The group of ciphers from which some would be selected also might be
> >known. But the particular ciphers selected for use at a particular
> >time need not be known, because that could (should) be keyed.
> But in this way if I the attacker could guess the algorithm used, it's
> possible isn't it?, would know something new about the key used...
If you use block ciphers, your key can e.g. consists
of two parts, one part for selecting the algorithms and
the other for the ciphers, or you can choose some scheme
that is essentially equivalent. Does that cover your
question?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Multiple encryption passes
Date: Thu, 10 Aug 2000 21:20:27 GMT
On Thu, 10 Aug 2000 20:29:36 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt ArchimeDES
<[EMAIL PROTECTED]> wrote:
>On Wed, 09 Aug 2000 16:25:52 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>[...snip..-]
>>>Security by obscurity?
>>>Hmmm, the security of a cryptosystem is not given by the secrecy of
>>>the algorithm used, only by the secrecy of the key (Principle of
>>>Kerckoffs).
>>
>>Presumably, cipher selection would be part of the key.
>>
>>It would be known that the system used multiple different ciphers.
>>The group of ciphers from which some would be selected also might be
>>known. But the particular ciphers selected for use at a particular
>>time need not be known, because that could (should) be keyed.
>But in this way if I the attacker could guess the algorithm used, it's
>possible isn't it?, would know something new about the key used...
It is *always* possible to guess what the key is.
I suppose you mean that you might be able, in some way, to detect
which ciphers are being used, and thus know something about the key.
Surely we don't imagine using any current system which announces its'
identity; as far as I know, the issue is a sequence of ciphers per se,
not cipher systems. I'm tempted to say that if one can distinguish
one cipher from another, one of the ciphers is not what we want to
use.
Then, surely we imagine that good care will be taken to make the key
bits independent. Knowing some of the bits should never be allowed to
help in knowing others.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Date: Thu, 10 Aug 2000 17:43:18 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
This is the nature of Strange Attractors. It allows us to claim that we're not
repeating ourselves, but iterating the discussion ;-)
CMan wrote:
> I have noticed a fractal pattern in the frequency distribution of one time
> pad discussions on this newsgroup.
>
> Like weather patterns, these discussions crop up, raise a lot of dust and
> finally deteriorate into "oh yeah, so's yer old man".
>
> The average length is about 50 messages but often they buzz on for hundreds
> of off topic discussions. Nice source of entropy actually.
>
> JK
>
> --
> CRAK Software
> http://www.crak.com
> Password Recovery Software
> QuickBooks, Quicken, Access...More
> Spam bait (credit E. Needham):
> root@localhost
> postmaster@localhost
> admin@localhost
> abuse@localhost
> webmaster@localhost
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> <[EMAIL PROTECTED]> wrote in message news:8mth1u$vpt$[EMAIL PROTECTED]...
> > Here's a different viewpoint.
> >
> > I think all the crypto-books are wrong. One-time pad is only secure
> > based on the assumption that random numbers do exist.
> >
> > But can you prove that random numbers really exist? No.
> > Can you generate truely random numbers? No.
> >
> > It's like 1/x tends to zero but you'll never get zero, if you use
> > enough bytes to hold the number.
> >
> > One-time pad is only computationally secure, no difference than any
> > other systems. The key-generating process may be duplicated, if not
> > exactly, to some probability. And because the key is so long, getting
> > at least a portion of the key right will be easier than in systems with
> > a shorter key.
> >
> > Get the picture? You can duplicate the key-generating parameters:
> > computer model, OS, PRNG, date, time, location, hardware, software,
> > room temperature, humidity, magnetic field... The list goes on and on.
> > Then the longer the key, the higher possibility that you'll get
> > something right.
> >
> > --Sisi
> >
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Secrets and Lies: New Book by Schneier
Date: 10 Aug 2000 18:43:13 -0500
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> writes:
> Bruce Schneier <[EMAIL PROTECTED]> wrote:
>>Secrets and Lies: Digital Security in a Networked World
> I know you have to make a living but do you care to post some
> chapters online to show off what it looks like?
Isn't that what book reviews are for ?
Given that he has a track record as an author, I would think it would
be straightforward to find in a bookstore. My assumption would be that
if your local technical bookstore doesn't order it in general, they are
not doing their job. (I find it hard to imagine a bookstore buyer who
would look at some book Bruce wrote and make a reasoned decision that
on technical merits it did not deserve to be offered for sale.)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Fri, 11 Aug 2000 00:09:24 +0200
Terry Ritter wrote:
>
> <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >(1) If indeed one could (though I doubt) quantitatively
> >investigate the distribution of the cycle lengths of the
> >output of the congruence relation, then one could assess
> >the difference between the 'reduced' and the 'full' version
> >in quantitative terms and hence allows the user to do his
> >choice. Apparently, however, there is no way of doing that
> >in theory conveniently, let alone in practice.
>
> I think the math to do that does exist, for any particular N, and that
> presumably can be generalized into a distribution for "N" in general.
> But even if we do that we can't "guarantee" a secure system, and if
> not, then why use BB&S at all?
>
> I personally object to building ciphers with this sort of weakness,
> for then we are depending upon randomness to not produce a particular
> result when we know it might. That is weakness under our control; we
> can't blame the opponent if we make it easy.
In another follow-up I have tried to roughly compare the
issue here with weak keys, e.g. in DES. But I am not sure
how far such a comparison is appropriate, because I don't
know the magnitudes of the probabilities involved. If
indeed the two cases are comparable, then one could say
that the decision to use the full version of BBS corresponds
to checking weak keys in block ciphers and hence a user
who opts for checking weak keys should use the full version
of BBS, if he behaves consistently. (In the other case,
he uses the reduces version.)
I want on the other hand once again to stress that the
short (or long) cycles being very heatedly disputed up
till now in this thread are those of the direct output of
the congruence relation and NOT of the LSB. There need
not necessarily exist a mathematically definite and
practically useful relationship between these two types
of cycle lengths. Since the user is using LSB, ONLY the
cycle length of LSB is of interest to him. I sincerely
hope therefore that the energy of the discussion
partners will in future be largely spent on the cycle
length of LSB (rather than on the cycle length of the
direct output of the congruence relation) and, what
is at least of equal importance, on the remaining
statistical qualities of LSB, e.g. bias, correlations,
etc. For, a user can sensibly apply the BBS device in
his applications only if such knowldege is available.
Otherwise, even if we could tell him exactly what cycle
length of the direct output of the congruence relation
is for each and every configuration of BBS he happens
to choose, he can make NO use of our information at all.
I'll very much appreciate to be able to see posts about
all the statistical qualities of LSB of BBS in the near
future in this thread.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: EGD's..
Date: Thu, 10 Aug 2000 22:03:11 GMT
Ian Upright <[EMAIL PROTECTED]> wrote:
> Where do I find out more about the exact protocol of the EGD daemon?
> Is /dev/random and /dev/urandom also the same protocol?
No, /dev/random will only return "random bytes within the estimated
number of bits of noise in the entropy pool." That is, it maintains a
buffer of random bits from environmental noise (which may or may not
be environmental, some systems use various measurements of device
drivers, etc) and returns the requested amount of bytes from that pool
on a read(2). If the pool is empty, or the amont requested exceeds the
amount of random bytes remaining, read() will block until the pool
refills. (Possibly a _very_ long time)
/dev/urandom is guarenteed not to block. It will return as many bytes
as are available in the entrophy pool, then use an algorithm to
generate as many bytes as needed to fill the request.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
Subject: Re: Destruction of CDs
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2000 14:59:47 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
>Mickey McInnis wrote:
>>
>
>> Melting/burning would be better, but I would be concerned
about toxic
>> byproducts. Stir the resultant puddle or ashes.
>
>Dumb question: Of what kind of chemical materials are CDs made?
plastic and aluminum I think...
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Secrets and Lies: New Book by Schneier
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2000 14:59:15 -0700
[EMAIL PROTECTED] (Larry Kilgallen) wrote:
>In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> writes:
>> Bruce Schneier <[EMAIL PROTECTED]> wrote:
>>>Secrets and Lies: Digital Security in a Networked World
>
>> I know you have to make a living but do you care to post some
>> chapters online to show off what it looks like?
>
>Isn't that what book reviews are for ?
>
>Given that he has a track record as an author, I would think it
would
>be straightforward to find in a bookstore. My assumption would
be that
>if your local technical bookstore doesn't order it in general,
they are
>not doing their job. (I find it hard to imagine a bookstore
buyer who
>would look at some book Bruce wrote and make a reasoned
decision that
>on technical merits it did not deserve to be offered for sale.)
First off there is only one bookstore in Kanata (chapters) and
no they wouldn't have the book. They only have business/self-
help and 'everything for arses' books.
Second why not publish some chapters online? It would do a
service for the financially challenged. Those with moola will
not 'not buy' a copy just because it's online. Heck if I had 50
bucks I would go buy it now....
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: BBS and the lack of proof
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2000 15:01:21 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
>tomstd wrote:
>>
>> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >tomstd wrote:
>> >>
>> >
>> >> Given two primes
>> >>
>>
p=121012662526787295907262401512751757545611582897620391004818266
>> >> 981159050711
>> >>
>> >> and
>> >>
>> >>
>>
q=375132239070794634471679739337309743812131772704924806435878390
>> >> 190959014553
>> >>
>> >> and a starting x[0] of
1291842616032279148102643839788703561
>> >>
>> >> What is the period of this generator?
>> >
>> >You wouldn't get any figure of the period. I guess the answer
>> >is likely to comprise of: (1) According to the 'mathematics'
in
>> >the BBS paper, the output of the congruence relation is very
>> >very likely to be very very very big. (2) What the period of
>> >the LSB of the output is (a matter that interests you) does
>> >not belong to 'admissible' topics about BBS (because the
paper
>> >left open that question) and is hence 'by definition' of no
>> >interest, point.
>>
>> Well what if I was making a prng I would really like to know
the
>> period. How do you know the period is not just seven outputs?
>>
>
>Well, 'in principle' you can run the generator and determine
>the period, just like I have found (by hand) the cycle
>(38, 190, 152, 114) for n=209. In practice, you of course
>have troubles, if your generator is large. And after that
>you have further to determine the period of the LSB. (In my
>example it is 1). There appears to be in the case of BBS
>hardly any theory known that enables you to calculate
>or estimate the period of LSB, which is 'really' what you
>are interested in. So you are left to your own. On the other
>hand, it is possible in my humble view to 'realistically'
>fill the 'vacuum' left by the theory through performing
>extensive (hence probably expensive) experiments, thereby
>gaining certain (though not in the absolute sense) confidence
>of whether very short periods of LSB are likely to occur or
>not. Before some such data are available, I would in your
>place delay applying BBS and go meanwhile drinking some tea.
Of course you can't just run and 'find the period' with a 512-
bit modulus. But that's my point what the heck is the period?
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: newbie question on public key lengths
Date: Thu, 10 Aug 2000 15:02:20 -0700
There's some very fuzzy issues there, but in general, in n-bit RSA the
modulus is size n-bits, the public exponentis of size g-bits (determined by
programmer/RNG/just about everything but is not necessarily dependent on n),
and the private exponent is between n-g and n+g in size. None of these are
firm and I have known people who referred to the size of the key in bits by
the sum of the modulus bits plus the bits of the public exponent, people who
refer to it by the size of the certificate, etc. But in general we refer to
it by the size of the modulus.
Joe
"Ken Tomei" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've looked through a few texts for a direct answer to this without much
> luck, thought someone in this newsgroup could help. Is the precision of
> a public key always fixed? In other words, if I'm using a 1024-bit RSA,
> does that mean that all parameters (mod, exp, etc.) are exactly 1024-bit
> with the MSB set to 1? Or is the 1024-bit a maximum limitation, meaning
> they could range anywhere from 1 to 1024 bits? Please let me know.
>
> Thanks,
> Ken
>
------------------------------
Subject: Re: BBS and the lack of proof
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2000 15:02:55 -0700
lordcow77 <[EMAIL PROTECTED]> wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>>Therefore I submit that all BBS generators have a period under
>>10, prove me wrong without empiracle evidence.
>>
>
>IF all BBS generators have a period under 10, we can factor and
>decide quadratic residiousity for any composite. We select a non
>quadratic residue x such that Jacobi(x/n)=-1. We feed this x
>into the BBS generator, obtaining a first value of x_1 and use
>the guaranteed short cycle to find an x_prime leading back to
>x_1. x is a square root of x_1 mod n, as is x_prime. x!=x_prime
>because one is a QR and the other is not; this tells us that
>x^2=x_prime^2 mod n, the same relationship that we seek to
>obtain in the QFS or NFS. GCD(x-x_prime,n) will be a factor of
>n. We can factor n and consequently we can decide quadratic
>residiousity for n using your short cycle in *constant time*.
>Thus, computational complexity theory is turned upside down, you
>collect your Fields medal, you quickly become the richest person
>on this planet, and win everlasting fame.
Cool thanks :)
My point was 'what is the period'. Just being 'normally large'
is not sufficient. IT should be always larger and preferably of
known length...
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
** 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
******************************
