Cryptography-Digest Digest #54, Volume #9 Mon, 8 Feb 99 13:13:03 EST
Contents:
Re: hardRandNumbGen (R. Knauer)
Re: GPL'ed RNG (Peter Gutmann)
Re: RNG Product Feature Poll (Herman Rubin)
Re: GPL'ed RNG (Mok-Kong Shen)
Re: RNG Product Feature Poll (Michael Sierchio)
Re: Is there a SHA implementatin in Visual Basic? ("Vonnegut")
Re: IDEA Rounds ("Wm. Toldt")
Towards a Wolrdwide Security Lingua Franca ([EMAIL PROTECTED])
Re: New search utility for this group (Paul Crowley)
Re: *** Where Does The Randomness Come From ?!? *** ("PAC")
Re: Press release - The Crypto Controversy: no problem (Dale R Worley)
Re: Cracking 128bit (Volker Hetzer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Mon, 08 Feb 1999 15:01:01 GMT
Reply-To: [EMAIL PROTECTED]
On 8 Feb 1999 09:13:28 -0500, [EMAIL PROTECTED] (Herman Rubin)
wrote:
>>I am still having a problem relating this "deviation from randomness"
>>you are testing for and the indeterminancy inherent in a TRNG. You are
>>claiming that a property for infinite numbers applies to finite
>>numbers, albeit with less than probability one.
>There is a language problem, and it does cause confusion.
Indeed!
>ANY physical device producing bits is a TRNG,
Not necessarily the kind of True Random Number Generator that produces
proper sequences for the OTP cryptosystem.
>in the sense that there
>is a joint probability distribution of all the bits produced. It
>does not follow from this that the probability that any k of the
>bits form any particular k-element sequence is exactly 1/2^k.
A TRNG has a specific definition - it must be capable of generating
all possible finite sequences equiprobably. The best example of a TRNG
is a fair coin toss.
>Your generator, or any other physical generator, produces random
>bits.
Not necessarily the kind of random bits that a TRNG produces to
satisfy the requirement above.
>The question remains as to whether they have the particular
>properties needed to use these bits as if they had the ideal
>properties. It is THIS which is being tested.
Here is the crux of the position I am maintaining. I agree that
statistical tests can be used for diagnostic purposes to demonstrate
that a RNG is not a TRNG to within a certain level of confidence. Even
then you can reject a perfectly good TRNG if you do not subject it to
a large number of tests. But that is not where the real danger lies -
the worst is that you will reject properly working TRNGs.
The danger comes about when you attempt to use statistical tests to
demonstrate that a RNG is a crypto-grade TRNG. Even if a RNG passes
your statistical tests, you still do not know if it is a properly
working TRNG or not.
Therefore the very thing you are testing the RNG for, namely its
suitability for use with the OTP system, is not determinable. You
might be able to determine that a RNG is not suitable, but you cannot
determine that an RNG is suitable.
>One cannot possibly do better. It is not possible to get certainty,
>and one can only do so much to balance the probabilities of the
>various kinds of error. This balancing of risks is what theoretical
>statisticians study, so that one can decide what can be done and how
>well it can be done.
You cannot determine with *any* level of confidence that a TRNG is
working properly just because it passes your tests. You can only
determine with a certain level of confidence that it is not working
properly because it does not pass your tests.
>This is harder than one thinks.
I know that.
>There are arguments for PRNGs, among
>them being the fact that transmitting them involves much smaller band
>width. For cryptography, the criterion is vulnerability of the
>transmitted message. For simulation, the criterion is the accuracy
>of the calculated results. In neither of these case is the source
>of the "random numbers" important, unless it causes the criterion
>not to be met.
I disagree with your statement for purposes of the OTP cryptosystem.
The security of the OTP relies on the fact that the pad is
constructed from the output of a TRNG. If you use a source of
"randomness" that does not meet the specification of the TRNG, you
could suffer a probabilistic attack.
Only if the numbers come from a completely nondeterministic random
number generator can there be no "leakage" of information.
>>You made the most fundamental mistake when you assumed that
>>statistical testing could certify a TRNG to within any arbitrary level
>>of precision. You cannot use deterministic algoritmic tests to certify
>>if numbers are being generated by an indeterministic process. You can
>>only use such tests to certify that the process is not deterministic.
>>Therefore you can not certify that you have a TRNG or a SOG. But that
>>determination is crucial to producing ciphers that are proveably
>>secure.
>What you say is correct.
Finally! I got someone to agree with me on something!
>But the type of TRNG you think you have does
>not exist, only approximations of it can exist. And it is necessary
>to test if the approximations are good enough.
You can never know if they are good enough, only that they are bad
enough.
I realize that an actual TRNG will not be perfect, but I believe it
can be made to specification such that it will not cause any
significant amount of information to "leak".
That may also be the case for some stream ciphers, such as using the
least significant bits of text and hashing them to high entropy
density. Even though the latter is not a nondeterministic TRNG, it may
not leak cause enough information to leak for practical purposes.
My concern is that statistical tests cannot be used to determine
whether ANY method of random number generation is suitable for the OTP
system. All it can be used for is to reject those RNGs that do not
pass, and then only probabilistically. The only way you can certify a
TRNG for use with the OTP system is to do a full audit of the
generation method.
>Your physical process is not going to be that constant. This is why it
>is necessary to make lots of assumptions and test intelligently to hope
>to achieve this.
I believe it is possible to build a TRNG that can be be certified to
be properly working based on subsystem diagnostics and the knowledge
of the random process that gives it its nondeterminancy - without
having to resort to statistical tests on the output sequences.
Bob Knauer
"The world is filled with violence. Because criminals carry guns,
we decent law-abiding citizens should also have guns. Otherwise
they will win and the decent people will loose."
--James Earl Jones
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: GPL'ed RNG
Date: 8 Feb 1999 15:00:22 GMT
[EMAIL PROTECTED] () writes:
>Is there a GPL or LGPL random number generator that produces "good"
>random numbers? rand() just isn't cutting it :P
The next release of cryptlib, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/,
will contain the code for the RNG (described in my 1998 Usenix Security
Symposium paper) under a dual license (Berkeley-style or GPL, take your
pick). It's been under this license for awhile, I just haven't got round to
documenting it.
Peter.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: RNG Product Feature Poll
Date: 8 Feb 1999 09:23:44 -0500
In article <[EMAIL PROTECTED]>,
Michael Sierchio <[EMAIL PROTECTED]> wrote:
>"R. Knauer" wrote:
>Knauer -- I think that you're either being disingenuous or stupid. Most
>of your posts lead me to believe that you're intelligent, so I think
>you're intentionally misconstruing the point.
>> >Reasonable statistical properties are more than enough for cryptography,
>> You will have to prove that assertion - I cannot take it on your word
>> alone. In particular, I would have to see how indeterminancy comes
>> from "reasonable statistical properties".
>Herman will correct me, but statisticians regard a sequence of outcomes as
>random if each outcome is independent of the previous ones. This is sufficient
>for crypto, and explains why PNRGs are inadequate -- if you include choice of
>initial conditions in "previous outcomes."
Random is used in many ways. Many times this is assumed, but it is not
necessarily the case. Sampling without replacement violated this assumption,
and there are other models. Queuing models, birth and death processes,
diffusion processes, and many others violate independence.
Perfection is not attainable; if we can assume that the probability that
a bit is 1, given all previous bits, is between .49 and .51, the maximum
channel capacity, assuming that this probability is known for each bit,
is less than .0003. It is hard to use the full channel capacity, but
this would enable one to get about 3000 bits of information in transmitting
an encyclopedia volume.
>> The half life of a radioactive isotope is a measure of indeterminancy
>> in time of when it will decay, and the spectral half width of the
>> energy spectrum is a measure of indeterminancy in energy of what
>> energy it will have when it decays.
>Sorry, that's not only not a definition, it's wrong. A radioisotope's
>half life isn't any kind of "measure of indeterminacy" -- it's
>a "characteristic." It's of no value in determining the approximate
>entropy in the series of decay events.
The decay rate, even if there is no subatomic interference, still
changes. After an atom decays, there is one less atom.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: GPL'ed RNG
Date: Mon, 08 Feb 1999 16:34:48 +0100
[EMAIL PROTECTED] wrote:
>
> Is there a GPL or LGPL random number generator that produces "good"
> random numbers? rand() just isn't cutting it :P
I have designed a compound PRNG with code in Fortran 90 available.
See
http://www.stud.uni-muenchen.de/~mok-kong.shen/#paper9
M. K. Shen
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: RNG Product Feature Poll
Date: Mon, 08 Feb 1999 08:16:21 -0800
Reply-To: [EMAIL PROTECTED]
Herman Rubin wrote:
> The decay rate, even if there is no subatomic interference, still
> changes. After an atom decays, there is one less atom.
Of course it does -- there are many "continuous" phenomena that
behave this way as well -- the rate is proportional to the quantity
left. Cf. Newton's Law of Cooling. There's plenty of entropy, even
if it isn't linear.
------------------------------
From: "Vonnegut" <[EMAIL PROTECTED]>
Subject: Re: Is there a SHA implementatin in Visual Basic?
Date: Mon, 8 Feb 1999 11:12:15 -0500
Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha!!!!!!!!!!!!!!!!!
------------------------------
From: "Wm. Toldt" <[EMAIL PROTECTED]>
Subject: Re: IDEA Rounds
Date: Mon, 08 Feb 1999 08:48:17 -1000
Dirk Mahoney wrote:
>
> Hi everyone,
>
> Are there any known problems (security-wise) of arbitrarily increasing
> the number of rounds used when encrypting plaintext with the IDEA
> algorithm? The default is 8 rounds, but if I were to be a little on the
> paranoid side, would there be any harm in increasing this to 12 for
> example?
>
> Thanks in advance,
> - Dirk
Yes, increase the rounds. Inform anyone who will decrypt the file about
the number of rounds they should use. When you distribute the key, also
vary the number of rounds by telling recipients about the round count
needed for the key. If your round count varies randomly from 8 to 520,
this adds 9 bits to the key length.
------------------------------
From: [EMAIL PROTECTED]
Subject: Towards a Wolrdwide Security Lingua Franca
Date: Mon, 08 Feb 1999 16:11:30 GMT
List:
The 1998 Wassenaar Arrangement [WA] was signed by 33 countries which propose
to restrict the worldwide export of cryptography with more than 56-bits of
secret-keys -- and, widely regarded to negatively impact worldwide Internet
interoperability, privacy, security and e-commerce. The WA also brought to
the front the delicate question of protection against brute-force attacks to
a ciphertext sent through an open and public network such as the Internet --
when the attacker has the full ciphertext plus routing information and enough
resources to try out all keys, in an exhaustive search.
Indeed, the WA can be seen as actually defining a current lower limit for the
bit-length security parameter of symmetric ciphers, which should be larger
than 64-bits. However, ciphers that obey this very limit cannot be freely
exported to be used on the worldwide Internet -- due to the export limitation
of 56-bits imposed by the WA.
Technically, to accept this limitation is to accept that security sytems must
now be designed to fail -- certainly -- in a competitive global economy.
To route around this limitation, two questions are presented to the designer:
(i) how to protect one's data against a brute-force attacker that has almost
unlimited resources and, (ii) Can this be done under the current secret-key
export-free bit-length restrictions of the WA?
Apparently, the answer to both questions together must be negative. As
answered by the very existence of the WA itself -- or one may believe that 33
countries decided to face even mutual privacy concerns and propose an
ineffective rule. Indeed, there must be an underlying technical reasoning
which was considered to be correct and ascertained the effectiveness of the
very limitation proposed -- secret-key bit-length -- to control security as
desired even among the participants, as a type of "fair handicap". Thus,
given the authoritative status of its proponents and renowed technical
expertise and resources in cryptography, one would expect a negative answer
to both questions taken together -- after all, the very purpose of the WA
limitations on cryptography depends on this negative answer.
However, 50 years ago Claude E. Shannon, an American scientist, published an
application of his Information Theory (then, called "Communication Theory") to
Cryptography -- which, in my opinion, cn be used to derive positive and
practical answers to both questions (i) and (ii) above, together.
This subject is continued in the exposition "Unicity, DES Unicity, Open-Keys,
Unknown-Keys" at http://www.mcg.org.br/unicity.htm -- with the following
Abstract:
|This exposition revisits the concept of unicity in cryptographic systems and
|applies it to show that: (i) key-length is not the limiting parameter that
|controls the security of cryptographic systems as explicit in the Wassenaar
|Arrangement and US export controls , (i) ciphers can be much weaker than
|hitherto imagined as exemplified by showing that DES can be broken with just
|three letters of text and not 20, (iii) there are two new security concepts,
|called Open-Keys and Unknown-Keys, which can increase security even within
|secret-key 56-bit length limitations imposed by the Wassenaar Arrangement.
|As an application of unknown-keys, Section 5.2 discusses a protocol called
|M-DES, based on a single 56-bit DES encryption per block, which can afford
|70-bits or more of perceived key-length to an attacker, but within current
|export limitations of 56-bits. This offers offers a practical way to achieve
|worldwide standards for 70-bit cryptography or much more -- today -- which
can |positively impact Internet e-commerce and interoperability. By allowing
the |secure use of smaller secret-keys, the Open-Key/Unknown-Key concepts can
also |have other applications, such as in smart-cards, digital signatures,
|authentication, non-repudiation protocols, etc.
Thus, the above exposition is not only a "proof of principle" that key-length
export restrictions are a technical moot issue but also offers a practical way
to achieve worldwide standards for 70-bit cryptography or much more -- today.
Which can positively impact Internet e-commerce and interoperation.
This work is being done within the stated objectives of the MCG, the
Meta-Certificate Group -- an Internet open group on Certification and
Security, currently with participants from 28 countries -- to use public
discussions to develop a worldwide security lingua franca. It is important
to note that this is not intended as an attempt to violate any law in any
country, but to allow the technical concepts of privacy and security to be as
transparent as possible in regard to any national legislation in existence or
in planning.
Comments are welcome.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck [EMAIL PROTECTED]
http://novaware.cps.softex.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: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: New search utility for this group
Date: 8 Feb 1999 10:22:38 -0000
[EMAIL PROTECTED] (Dale R Worley) writes:
> In article <[EMAIL PROTECTED]> BH <[EMAIL PROTECTED]> writes:
> New search utility for this group
> at:
>
> http://patriot.net/~bhakiz/
>
> It looks like a spam; I tried "panama" and got nothing related to the
> Panama crypto algorithm that was discussed here a month ago.
The Panama reference implementation is here:
http://www.esat.kuleuven.ac.be/~rijmen/daemen.html
(the paper is misssing the ".html" bit on the end). You may already
know this, of course. The source includes a URL at which the paper
can be found but I haven't tried it:
http://standard.pictel.com/ftp/research/security
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
------------------------------
From: "PAC" <[EMAIL PROTECTED]>
Crossposted-To: sci.philosophy.meta,sci.physics,sci.skeptic
Subject: Re: *** Where Does The Randomness Come From ?!? ***
Date: Mon, 8 Feb 1999 08:39:19 -0800
R. Knauer wrote in message <[EMAIL PROTECTED]>...
>On Sun, 7 Feb 1999 20:31:05 -0800, "PAC" <[EMAIL PROTECTED]> wrote:
>
>>> Half the universe seems to be syntax, the
>>> other half semantics.
>
>> You mean we're all words?
>
>Nope. We're all numbers.
>
>But then, words are numbers, aren't they.
>
>Bob Knauer
>
>"The world is filled with violence. Because criminals carry guns,
>we decent law-abiding citizens should also have guns. Otherwise
>they will win and the decent people will loose."
>--James Earl Jones
I'm not answering my phone for the time being. All complaints will
have to be referred to the proper channels or to my secretary. Surf's up .
. .
Peace,
Phil
------------------------------
Crossposted-To: alt.security.pgp,mics.legal.computing,talk.politics.crypto
From: [EMAIL PROTECTED] (Dale R Worley)
Subject: Re: Press release - The Crypto Controversy: no problem
Date: Sun, 7 Feb 1999 05:18:52 GMT
In article <78rls5$i13$[EMAIL PROTECTED]> [EMAIL PROTECTED] (test) writes:
I guess that the only consolation for the authorities is that
traffic analysis can still be used. I would imagine that under
certain circumstances, traffic analysis can yield pretty useful
information.
Well, if you are an "authority" attempting to control terrorism, drug
dealing, political dissent, or most any other type of "antisocial"
behavior, traffic analysis gets you most of what you want -- once you
know which 100 people to target, traditional human intelligence
techniques will do. (I.e., if there are only 100 targets, you can bug
their rooms rather than their telephones.)
As another poster mentions, certain Internet technologies make traffic
analysis very hard. This suggests that strong cryptography combined
with packet-switching communication may have more implications for
"antisocial behavior" than strong cryptography combined with
circuit-switching communication.
Dale
Dale Worley [EMAIL PROTECTED]
--
I can't figure out how to work this life - it came with the wrong
instructions - maybe I should just plug it in and see what happens,
but I can't find an outlet...
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Cracking 128bit
Date: Mon, 08 Feb 1999 17:21:33 +0100
Jim Gillogly wrote:
>
> Volker Hetzer wrote:
> > Anonymous wrote:
> > >
> > > I had been under the assumption that good 128 bit encryption
> > > would take billions of years to crack.
> > > But then I came across this
> > >
> > > http://www.securitydynamics.com/products/datasheets/securpc.html
> > >
> > > "...Cracking a single 128-bit RC4 key is an effort costing an
> > > estimated half billion dollars and taking more than six months to
> > > achieve."
>
> > Well, there are good and bad algorithms. The good ones get
> > more security out of 128 Bit than the bad ones.
>
> True enough. Do you have any reason to believe RC4 is in the "bad
> ones" category, putting it closer to the "six months" end than to
> the "billions of years" end? I haven't seen anything to suggest
> there's been an attack that would make that big a difference.
> Schneier's estimate for 128 bits of 1995 brute force includes a
> value of a trillion dollars for a run-time of a trillion years.
> Obviously hardware will get better and cheaper, but that's a lot
> to make up.
I would suggest they weakened the implementation.
Like storing the key RSA-encrypted somewhere and chosing a
(relatively) small RSA-key length.
However, I'm just guessing.
Volker
------------------------------
** 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
******************************
