Cryptography-Digest Digest #160, Volume #13 Tue, 14 Nov 00 21:13:00 EST
Contents:
Re: hardware RNG's (Terry Ritter)
Re: Thoughts on the sci.crypt cipher contest ("Paul Pires")
Re: Thoughts on the sci.crypt cipher contest ([EMAIL PROTECTED])
Re: hardware RNG's (David Schwartz)
Re: Thoughts on the sci.crypt cipher contest (Paul Crowley)
Re: The SHAs (Stephan T. Lavavej)
Re: hardware RNG's ("Paul Pires")
Re: hardware RNG's (David Schwartz)
Re: voting through pgp (Greggy)
Re: Secret sharing in practice (David A Molnar)
Re: Thoughts on the sci.crypt cipher contest ([EMAIL PROTECTED])
Re: Black Market Internet Information - my visits and tradeshows (Futurist)
Re: On an idea of John Savard (Tom St Denis)
Re: hardware RNG's ("Paul Pires")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: hardware RNG's
Date: Tue, 14 Nov 2000 23:11:09 GMT
On Tue, 14 Nov 2000 13:21:36 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt David Schwartz
<[EMAIL PROTECTED]> wrote:
>"Douglas A. Gwyn" wrote:
>
>> David Schwartz wrote:
>> > Tim Tyler wrote:
>> > > To my mind a sequence that is one 80% 2s hardly qualifies as "random" or
>> > > "unpredictable".
>> > Then what about a sequence that is 50% 1's?
>
>> If nobody defines his terms, then this degenerates to a lot of
>> uninformed opinion. Statisticians have a general agreement on
>> the meaning of a "random process" -- note, it is a process --
>> which certainly encompasses generation of biased distributions.
>> The usual cryppie term for a *uniform* random distribution is
>> "flat random", and that seems to be what Tim Tyler has in mind.
>
> I use "random" (in a cryptographic context) to mean unpredictable (by
>an attacker with a specific presumed set of resources). How random
>something is is the same question as to what extent a hypothetical
>attacker could predict it.
But an attacker can predict *any* value; there is nothing about any
particular value which could prevent prediction.
It is better to say that an "unpredictable" bit can be predicted
correctly only 50 percent of the time. Any value other than this
involves some amount of useful prediction. Useful cryptographic
weakness does not require 100 percent predictability.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Thoughts on the sci.crypt cipher contest
Date: Tue, 14 Nov 2000 15:15:45 -0800
Paul Crowley <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Pires wrote:
> > What would be interesting from a large block size standpoint?
> > Are we talking 8x (512bits) or x^2? Any interesting points
> > along the way?
>
> For disk encryption the important thing is the 4096-bit block size. The
> other tricky consideration is that you need not just one random
> permutation for each key, but a whole family, one for each sector of the
> disk. You could use incrementing keys across the disk, but only if you
> can achieve truly outstanding key agility.
>
> A truly variable size block cipher, applicable to 1 or a million bits,
> would be a useful primitive to have though. Note that if the key
> agility is good (or the cipher accepts a "spice" or randomiser alongside
> the key) then a 1-bit block cipher could be useful under some
> circumstances.
>
> > New stream cipher ideas would be worthwhile
> > but aren't they harder to analyze?
>
> I guess. Partly I wish there was more analysis and discussion of stream
> ciphers designed to be efficient in software, designed using the lessons
> from block cipher cryptanalysis, and I hoped sci.crypt could have fun
> getting the ball rolling. There are sometimes equivalent ways of
> weakening stream ciphers; RC4, for example, has obvious variants on the
> size of the output word (8 bits in full RC4). But you're right, the
> lack of an obvious family of variants of varying strength to attack
> could be a serious problem.
The process would be part of the solution. I have learned much from
the conversations of analists debating the merits of one approach vrs
another. Seeing someone else's logic and the judgement exercized in
going one way vrs another is priceless. This is missing in the area of
Stream ciphers. An egg hunt would be valuable, regardless of the
quality of the entrants, just to observe the "big guns" euthanasia techniques.
Who knows... the horse might learn to sing.
Paul
>
> --
> __
> \/ o\ [EMAIL PROTECTED]
> /\__/ http://www.cluefactory.org.uk/paul/
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Thoughts on the sci.crypt cipher contest
Date: Tue, 14 Nov 2000 23:13:29 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> I wasn't around for the sci.crypt cipher contest when it was
announced:
That's ok, I never entered because I don't believe in writing
decryption routines, simply for the reason that creating them makes it
possible to easily use them commercially, and let's face it, it's most
likely weak.
Anyway, I'd also like to see a large block cipher arrangement. I'm
personally examining one that is interesting me, and I can do either a
64 byte (probably disk sector) or 48 byte (ATM block) version quite
easily. I can do others), but I haven't examined them in the slightest.
Basically it's just a curiosity cipher to explore the behavior of like-
systems, but it's proving interesting to me. Either way I won't be
writing a decryption function.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Tue, 14 Nov 2000 15:25:05 -0800
Terry Ritter wrote:
> > I use "random" (in a cryptographic context) to mean unpredictable (by
> >an attacker with a specific presumed set of resources). How random
> >something is is the same question as to what extent a hypothetical
> >attacker could predict it.
> But an attacker can predict *any* value; there is nothing about any
> particular value which could prevent prediction.
Huh? Sure there is. If the person trying to predict the value doesn't
know enough about the generation process, he can't predict it. A lucky
guess is not the same thing as a prediction. I think it's quite clear
that I'm using 'prediction' in the cryptographic sense, not in the sense
in which astrologers and psychics use it.
> It is better to say that an "unpredictable" bit can be predicted
> correctly only 50 percent of the time. Any value other than this
> involves some amount of useful prediction. Useful cryptographic
> weakness does not require 100 percent predictability.
Probably no system imaginable can ensure meet the 50% level of perfect
unpredictability. So while this might be a useful definition
theoretically, it's useful in practice. Heck, by this definition, RC5's
PRNG isn't unpredictable. Accepting this definition would be as
senseless is accepting a definition of 'secure' for which only an OTP
could qualify.
This definition would even reject most radioactive-decay based RNGs.
The rate of radioactive decay is gradually decreasing over time. One
system that measures two decay intervals and outputs a '1' if the second
interval was larger outputs a '1' about 1 in 10^13 more often than a '0'
because of the change in rate of decay. While this shouldn't be ignored,
it certainly doesn't render the final output predictable!
One can reasonably attempt to meaure how predictable or unpredictable
something is for imagined attackers with varying knowledge and
capability. Certainly _any_ predictability may be of concern in a given
practical application. But it's senseless to say that you don't have an
unpredictable bit stream simply because one may be able to make certain
predictions about it with various odds of succeeding.
The important thing is to understand exactly how predictable or
unpredictable your data stream is before you use it. That way, you can
pick the appropiate 'massaging' of to ensure that what you do with the
data stream has the resulting unpredictability you actually need.
For example, if I had a stream of bits which were random but biased
such that one in every 20 bits was a '1' and I needed one unbiased
random bit, I could take a series that went '1-0's-1-0's-1' and output a
'1' if the first run of 0's was larger and a '0' if the second run of
0's was larger (skipping this entire range if the two were equal).
Now, if you insist on your original definition of "unpredictable", I've
just performed a major miracle. I've taken a predictable input stream
and deterministically produced an unpredictable output stream from it!
DS
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Thoughts on the sci.crypt cipher contest
Date: Tue, 14 Nov 2000 23:42:53 GMT
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Paul Crowley <[EMAIL PROTECTED]> wrote:
> > I wasn't around for the sci.crypt cipher contest when it was
> announced:
>
> That's ok, I never entered because I don't believe in writing
> decryption routines, simply for the reason that creating them makes it
> possible to easily use them commercially, and let's face it, it's most
> likely weak.
We can't stop people deploying weak ciphers by keeping ours secret,
they'll just make up their own weak ciphers. The best we can do is make
with the big disclaimers that say "Use Rijndael if you want a cipher
that actually works!"
> Anyway, I'd also like to see a large block cipher arrangement. I'm
> personally examining one that is interesting me, and I can do either a
> 64 byte (probably disk sector) or 48 byte (ATM block) version quite
> easily. I can do others), but I haven't examined them in the slightest.
>
> Basically it's just a curiosity cipher to explore the behavior of like-
> systems, but it's proving interesting to me. Either way I won't be
> writing a decryption function.
The whole point of the contest is to make curiosity ciphers that are fun
to make and fun to break. If any really neat ideas come out of it,
maybe someone will use them to create a cipher good for practical use,
but that's not the primary goal.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: stl/*This_is_a_comment*[EMAIL PROTECTED] (Stephan T. Lavavej)
Subject: Re: The SHAs
Date: Tue, 14 Nov 2000 23:44:38 GMT
The SHA-1 hash of the million-a file is documented in the standard
itself, I don't know why you're asking for it. Better to use a
nastier test file, like a billion-a file. That catches errors dealing
with how counters are implemented (long bad, long long good).
-*---*-------
Stephan T. Lavavej
http://quote.cjb.net
stl/*This_is_a_comment*[EMAIL PROTECTED]
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Tue, 14 Nov 2000 15:44:27 -0800
David Schwartz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Terry Ritter wrote:
>
> > > I use "random" (in a cryptographic context) to mean unpredictable
(by
> > >an attacker with a specific presumed set of resources). How random
> > >something is is the same question as to what extent a hypothetical
> > >attacker could predict it.
>
> > But an attacker can predict *any* value; there is nothing about any
> > particular value which could prevent prediction.
>
> Huh? Sure there is. If the person trying to predict the value doesn't
> know enough about the generation process, he can't predict it. A lucky
> guess is not the same thing as a prediction. I think it's quite clear
> that I'm using 'prediction' in the cryptographic sense, not in the sense
> in which astrologers and psychics use it.
>
> > It is better to say that an "unpredictable" bit can be predicted
> > correctly only 50 percent of the time. Any value other than this
> > involves some amount of useful prediction. Useful cryptographic
> > weakness does not require 100 percent predictability.
>
> Probably no system imaginable can ensure meet the 50% level of perfect
> unpredictability. So while this might be a useful definition
> theoretically, it's useful in practice. Heck, by this definition, RC5's
> PRNG isn't unpredictable. Accepting this definition would be as
> senseless is accepting a definition of 'secure' for which only an OTP
> could qualify.
>
> This definition would even reject most radioactive-decay based RNGs.
> The rate of radioactive decay is gradually decreasing over time. One
> system that measures two decay intervals and outputs a '1' if the second
> interval was larger outputs a '1' about 1 in 10^13 more often than a '0'
> because of the change in rate of decay. While this shouldn't be ignored,
> it certainly doesn't render the final output predictable!
>
> One can reasonably attempt to meaure how predictable or unpredictable
> something is for imagined attackers with varying knowledge and
> capability. Certainly _any_ predictability may be of concern in a given
> practical application. But it's senseless to say that you don't have an
> unpredictable bit stream simply because one may be able to make certain
> predictions about it with various odds of succeeding.
>
> The important thing is to understand exactly how predictable or
> unpredictable your data stream is before you use it. That way, you can
> pick the appropiate 'massaging' of to ensure that what you do with the
> data stream has the resulting unpredictability you actually need.
>
> For example, if I had a stream of bits which were random but biased
> such that one in every 20 bits was a '1' and I needed one unbiased
> random bit, I could take a series that went '1-0's-1-0's-1' and output a
> '1' if the first run of 0's was larger and a '0' if the second run of
> 0's was larger (skipping this entire range if the two were equal).
>
> Now, if you insist on your original definition of "unpredictable", I've
> just performed a major miracle. I've taken a predictable input stream
> and deterministically produced an unpredictable output stream from it!
It seems to me that you have refined a usable output stream from a poor
input stream by rejecting enough input to correct for it's flaws. You have not
made a good output, just thrown out some bad. Can you deterministically fix it
and leave the input/output ratio at 1:1?
Paul
>
> DS
>
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Tue, 14 Nov 2000 15:55:03 -0800
Paul Pires wrote:
> It seems to me that you have refined a usable output stream from a poor
> input stream by rejecting enough input to correct for it's flaws. You have not
> made a good output, just thrown out some bad. Can you deterministically fix it
> and leave the input/output ratio at 1:1?
Yes, assuming by "input/output ratio" you mean the ratio of input
entropy to output entropy.
The point is, if the input stream is deterministically fixable, then it
contained sufficient randomness. Otherwise no deterministic process
could fix it.
DS
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: voting through pgp
Date: Tue, 14 Nov 2000 23:59:51 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Greggy wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> > > binary digit wrote:
> > >
> > > > Imagine if everyone had pgp in the world and voted through pgp,
> > every single
> > > > vote could be verrified and everyone would be happy, and there
> > wouldnt be
> > > > this problem that is going on now in florida
> > >
> > > And anonymity would be lost and many arms & legs broken from
overly
> > enthusiastic
> > > political persuasion.
> >
> > Good. Then they might decide to exercise their second amendment
rights.
>
> There are four civic boxes. Looks like you have the order wrong.
>
> They are soap, ballot, jury, and ammo. It is critically important
that ammo
> come last becasue it is trump.
>
Confused? Those are all offensive boxes. I was referring to self
defense.
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Secret sharing in practice
Date: 15 Nov 2000 00:47:31 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
> "Matt Timmermans" <[EMAIL PROTECTED]> writes:
>> The best way to do secret sharing seems to depend on the size of the secret
>> involved.
>>
>> Does anyone actually use secret sharing in the real world? If so, then what
>> are the "common" applications, and how big are these secrets, typically?
> The natural and obvious thing to share is a secret cryptography key
> used for decrypting other stuff. This is typically around 168 bits
> (3DES symmetric key) or 1024 bits (RSA secret key).
In fact, people do this in at least two cases I've heard of
* dedicated hardware for holding a root CA's private key. The key is
created and immediately shared into several tamper-resistant modules.
The modules are designed to wipe the key if an adversary is too clumsy
tampering with them.
* "proactive security" -- a key is shared between n servers and then
"re-shared" periodically. the assumption is that an adversary can be
found and thrown out between re-sharings and that said adversary never
corrupts "enough" of the servers between re-sharings.
Amir Herzberg et. al. had a paper in a recent ACM CCS conference detailing
an actual system they had built to do this.
there are also protocols in the works from Integrity Sciences and Verisign
which distribute pieces of an authentication database over n
authentication servers such that all of them must be compromised in order
to reveal the secret.
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Thoughts on the sci.crypt cipher contest
Date: Wed, 15 Nov 2000 00:59:27 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> We can't stop people deploying weak ciphers by keeping ours secret,
> they'll just make up their own weak ciphers. The best we can do is
make
> with the big disclaimers that say "Use Rijndael if you want a cipher
> that actually works!"
But we can make it much easier for them to use Rijndael because all the
necessary routines are implemented, that is my goal. Besides it helps
make sure I don't get somehow listed as an author on some snake-oil.
> The whole point of the contest is to make curiosity ciphers that are
fun
> to make and fun to break. If any really neat ideas come out of it,
> maybe someone will use them to create a cipher good for practical use,
> but that's not the primary goal.
I certainly agree, I just make small efforts to make it as difficult as
possible for the uninformed to wrongfully use a weak cipher. I would of
course be willing to share the cipher design if anyone would like to
look at it (e-mail me at [EMAIL PROTECTED], I haven't written any code,
but I can fairly quickly have a human readable version). Barring that,
if this cipher exploration gets underway, I will submit the cipher, I
just won't do a decrypt function.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Futurist <[EMAIL PROTECTED]>
Crossposted-To: alt.security,alt.2600,comp.security
Subject: Re: Black Market Internet Information - my visits and tradeshows
Date: Wed, 15 Nov 2000 01:20:34 GMT
In article <8urjnj$1lr$[EMAIL PROTECTED]>,
Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
>
>
> In many Internet tradeshows I have purposefully requests to purchase
> the customer and other traffic information from many backbone ISPs and
> domain name services / controllers. These requests have resulted in
the
> following conclusion: In all cases people were willing to sell their
> customer and other traffic information. So if I can do it by myself
> alone, what can an intelligence agency such as the CIA, NSA, FBI,
> Mossad to do with their thousands of employees. My recommendation: The
> strongest possible encryption of all personal, official, business and
> other communications without implementing the NSA crackable AES
> (Advanced Encryption Standard). The reality: "Who wins the crypto war,
> wins the whole war."
>
> Markku
>
> P.S. Did you know that the CIA and Mossad have very close tie and
share
> satellite and other intelligence information daily and very regularly.
> In addition, the Jewish communicaty in the U.S.A. operates as a
> facilitator to enable improved Mossad intelligence activities. Did you
> also know that Mossad actually kills people. In addition, when I made
> negative comments regarding to Jews in 1999 I was attacked by Jews and
> the U.S. Government. The U.S. Government seems to think that it has
the
> greater responsibility to protect Jews than ordinary people.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Did you know that third world scum blew up the U.S.S. Cole in another
cowardly act because they know if they actually came out in the open
and attacked the U.S. every last one their little brown bodies would be
FRIED? Nuke the Middle East!!
--
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Wed, 15 Nov 2000 01:33:29 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> >
> [snip]
> > However I would be inclined to agree that it is at least as secure
if,
> > instead of arbitrary interleaving, the interleaving was done at full
> > round boundaries. In a balanced Feistel cipher, this point of
interest
> > is easily found, and the result is (using the notation above):
> [snip]
>
> Do you mean two rounds? If yes, I thought that I have
> indicated that with the term 'cycle', which for DES-like
> cipher is two rounds, i.e. a point where both halves get
> processed once.
Note that in DES two rounds are not "complete".
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Tue, 14 Nov 2000 17:48:40 -0800
David Schwartz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Paul Pires wrote:
>
> > It seems to me that you have refined a usable output stream from a poor
> > input stream by rejecting enough input to correct for it's flaws. You have
not
> > made a good output, just thrown out some bad. Can you deterministically fix
it
> > and leave the input/output ratio at 1:1?
>
> Yes, assuming by "input/output ratio" you mean the ratio of input
> entropy to output entropy.
No. I meant 1:1 input to output bit size. It is clear that output entropy only
comes
from input entropy. I wanted to know if you were saying something else. It seems
to me that there are two axis to the problem. Make better input/Make better
post processors. The latter seems less ideal since by definition, it requires
trashing some of your hard earned entropy or a complex proccess to refine
what you have in a way minimizing the loss. The quality of the "Miracle" you
performed See:
>>Now, if you insist on your original definition of "unpredictable", I've
>>just performed a major miracle. I've taken a predictable input stream
>>and deterministically produced an unpredictable output stream from it!
is less astounding when it is seen to be simple surgery.
>
> The point is, if the input stream is deterministically fixable, then it
> contained sufficient randomness. Otherwise no deterministic process
> could fix it.
How can Something contain "Sufficient Randomness"? Kinda paradoxical.
If you know it is, it isn't cause it wouldn't be random. "Sufficient
unpredictability"
is better but not much. How do you determine it's sufficiency and therefore know
if
you have fixed it? I'm not raggin on you, I actually feel the same way but it
does
me no practical good. The problem is still there. If it starts out bad and you
say
you fixed it, how do I know?
If I fix it, I don't have a problem cause I know what a clever fellow I am.
Paul
>
> DS
>
------------------------------
** 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
******************************
