Cryptography-Digest Digest #997, Volume #8 Fri, 29 Jan 99 11:13:03 EST
Contents:
Re: Random numbers from a sound card? (R. Knauer)
Re: hardRandNumbGen (Patrick Juola)
Re: what do u think about this algorithm of mine? (Patrick Juola)
Re: Random numbers from a sound card? (Patrick Juola)
Re: Random numbers generator and Pentium III (Mok-Kong Shen)
Re: Random numbers generator and Pentium III ([EMAIL PROTECTED])
Re: Random numbers generator and Pentium III (Mok-Kong Shen)
Re: Strong cryptography: the many ways we can trust a key
([EMAIL PROTECTED])
Re: hardRandNumbGen (Mok-Kong Shen)
Public Key encryption ("Phil Sumner")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers from a sound card?
Date: Fri, 29 Jan 1999 13:37:25 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 29 Jan 1999 11:47:15 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>> The only way you can prove the crypto-grade randomness of a finite
>> number is to consider the method of generation. If the generator is a
>> TRNG, as we have defined it here several times recently, then the
>> numbers it generates are crypto-grade random numbers.
>Ah! Finally one knows exactly what the term 'crypto-grade random
>numbers' you employ means: These are DEFINED to be the output
>from a hardware generator. If follows obviously then that there
>is NO need whatsoever of testing the sequences obtained, since they
>are BY DEFINITION 'crypto-grade'!
Are you being deliberatly obtuse - or does it come naturally?
Nothing that you said above follows from what I said. A TRNG is not a
True Random Number Generator just because it is a hardware device.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 29 Jan 1999 09:12:24 -0500
In article <[EMAIL PROTECTED]>,
Kurt Wismer <[EMAIL PROTECTED]> wrote:
>R. Knauer ([EMAIL PROTECTED]) wrote:
>: Learn what crypto-grade randomness is. The concept is deceptively
>: simple once you understand it. But first you have to give up all other
>: definitions of randomness from other fields like statistics.
>
>: The key to understanding is that randomness depends on the generation
>: process, not the numbers themselves. The number 000...0 fails all
>: sorts of statistical tests, but can be a random number if it is
>: generated by a TRNG. Until you analyze the method of generation, you
>: cannot know.
>
>this is the definition i've used for years... strangely, nothing i ever
>learned in statistics ever suggested i was wrong...
Possibly because it isn't. 8-)
On the other hand, it also looks suspiciously like the result of
an incompetent engineer *trying* to build a RNG.
Which is it? Your call. You know the engineers that you hired....
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: what do u think about this algorithm of mine?
Date: 29 Jan 1999 09:10:04 -0500
In article <[EMAIL PROTECTED]>,
Klaus Rohde <[EMAIL PROTECTED]> wrote:
>i don't know anything about encryption, but one day i was thinking about
>it and had an idea for an algorithm which, as far as i can see, is
>unbreakable.
>
>you take byte n of a text stream and XOR it with byte n of the key to
>produce byte n of the cipher text.
>
>to me this seem's unbreakable, because by applying the right key any
>cipher text can be decoded into literally anything of the same length,
>meaning that unless someone has the key, they can't gain anything out of
>the cipher text.
>
>any thoughts or ideas (or proof that what im saying is nonsense) would be cool.
Nice idea except for the fact that the text stream, which you are
treating as a key stream, is almost certainly way too predictable.
If you used a good source of random numbers, you have just reinvented
the OTP, which *is* provably unbreakable.
However, as is, if you can manage to figure out one likely word or
phrase to appear in the plaintext (in the context of a sci.crypt
posting, for instance, I'd guess "cipher", "cypher", "security",
"breakable", and "algorithm", then if you just XOR that word with
every possible location in the cyphertext, eventually you'll see a
readable part of the key appear. You can use this to guess the
next (or previous) few key words, use those to unbutton the
plaintext, &c.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Random numbers from a sound card?
Date: 29 Jan 1999 09:14:11 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>R. Knauer wrote:
>>
>
>>
>> You cannot prove the crypto-grade randomness of a finite number
>> algorithmically. You can for an infinite number, but that is useless.
>>
>> The only way you can prove the crypto-grade randomness of a finite
>> number is to consider the method of generation. If the generator is a
>> TRNG, as we have defined it here several times recently, then the
>> numbers it generates are crypto-grade random numbers.
>
>Ah! Finally one knows exactly what the term 'crypto-grade random
>numbers' you employ means: These are DEFINED to be the output
>from a hardware generator.
No. Not all hardware generators are TRNG.
-kitten
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator and Pentium III
Date: Fri, 29 Jan 1999 15:39:28 +0100
R. Knauer wrote:
>
> You have to define "scientifically precise" first.
>
> Or will you accept "mathematically precise"?
>
> They are not the same thing.
Say something in detail, whatever your definitions of these are,
rather than giving categorical and meaningless statements. If the
majority of readers of the group don't agree with you in matters
of definitions, they will criticize you or correct your assertions.
That is the way of genuine scientific discussions!
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random numbers generator and Pentium III
Date: Fri, 29 Jan 1999 14:29:44 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (R. Knauer)
writes:
> On Fri, 29 Jan 1999 11:38:12 +0100, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
>
>>> >Do you have ANY scientifically precise (quatifiable through exactly
>>> >defined and practically executable measurement methodologies)
>>> >'characterization' of crytp-grade randomness??
>
>>> Yes.
>
>>Then let the readers of this group know these and say clearly and in
>>detail, PLEASE.
>
> You have to define "scientifically precise" first.
Pretty strange quibble. Yes, he's got a characterization. A
scientifically precise one. But he can't give it to us because he
doesn't think Mok-Kong Shen has defined "scientifically precise". In
spite of the parenthetical definition that appears in the quoted text.
And in spite of the fact that he already said "Yes" without asking for
any further definitions.
Perhaps R. Knauer needs to define what he means by "Yes".
"Yes" = "Oui" = "Wee". R. Knauer makes wee wee on your question.
"No" = "Know". If he'd said that, it would have meant he knew the answer.
John Briggs [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator and Pentium III
Date: Fri, 29 Jan 1999 15:50:21 +0100
R. Knauer wrote:
>
> It is called "crypto-grade" to distinguish it from the other kinds of
> randomness that confuse this discussion.
>
> You do know the difference, don't you?
Unless there are scientific tests to determine the 'crypto-grade'
in terms of figure of merits or the like in quantifiable terms
nobody (exepting perhaps you) will be able to know the difference!
> The concept of crypto-grade randomness is not profound at all (on the
> surface anyway). To understand it all you have to do is unlearn all
> your prejudices that you got from thinking you knew what a random
> number is, accept the fact that there are different kinds of
> randomness, and that crypto-grade randomness is not the same as what
> you were taught before.
Are you suggesting one should forget what scientists have achieved
through the centuries and 'believe' the religious statement of some
person that everything from a hardware generator is crypto-grade???
This group is not the right place for clergymen.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Strong cryptography: the many ways we can trust a key
Date: Fri, 29 Jan 1999 14:27:03 GMT
In article <78r0k6$9e6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> The example of Section 5.2 in [Ger99] will be explained below under
> the general framework laid out above -- which I believe will provide
> a more illuminating insight into the method. The example is based on
> the usual 56-bit DES cipher plus M-bits of Unknown-Keys (i.e., using
> the method's last variant) -- in what was called M-DES. The TCAI
> 4-level trust system will be used, as quoted above, but please note
> that "Ignore" or "Ignored" are oftentimes used in lieu of "Ignorance"
> (for text continuity).
>
List:
I received some private comments on the proposed method, illustrated by the
example below, which I will address to the list since they are of a general
scope and seem very useful for a better understanding of the method itself.
> 2. EXAMPLE
>
> Bob needs to send a message to Alice, using export-free 56-bit DES
> and the M-DES protocol with M = 14 (which he decides is good enough).
>
The question is -- how does Bob decide on M?
Implictly, because Bob is not interested on M per se -- Bob's concern is
security versus cost, for which Bob needs to define a threat model. Let us
suppose that Bob's threat model is dominated by a brute-force attack for X
years under currently estimated military technology -- this directly implies
a minimum key-length K0, needed to defend against such threat within an
acceptable confidence level (e.g., 99.999% per key). Obviously, Bob wants an
effective key-length that is at least equal to K0 -- which value he inputs to
M-DES. To find the effective key-length, M-DES solves a decision problem
which depends at least on two independent variables: plaintext statistics and
M. For a given statistics and M, is the effective key-length larger than K0?
Yes or no? If not, and possible, increase M. Some of these issues are
discussed in [Note-2] and lead to the following table for some values:
| MESSAGE Entropy M effective key-length
|
| English text 1.2 0 56
| English text 1.2 14 70
| random text 8 0 120
which shows that small M does not necessarily mean "low security" -- it all
depends on the plaintext statistics. Of course, one could also include the
maximum allowed average latency-time for the recipient to discover the
unknown-key as a constraint in the decision problem -- which will restrict the
range of M.
> Bob chooses one key at will from a publicly known list of 64-bit keys
> that has a total of 2^14 keys. Note that, to any observer, including
> Alice and an attacker, the key chosen by Bob is unknown and has
> 14-bits of entropy -- even if that key list is just a sequential
> numbering from 1 to 2^14. In other words, the "Unknown-Key" is
> Ignored by Alice and any attacker, within 14-bits of choice.
>
How can a known list of sequential numbers have entropy?
Because you do not know which number was chosen -- entropy pertains to
freedom of choice, not what each choice is. For example -- you surely know
all numbers and can immediately name any number, however if I tell you that I
will randomly toss a fair heads/tails coin (which is a 1-bit coin) you will
not be able to predict the outcome better than with a 1-bit uncertainty
(entropy). Likewise, if I toss a 14-bit coin the uncertainty will be 14-bit
-- even I know all the possible outcomes, since I cannot predict which will
be produced.
Why use unknown-keys with 64-bits, if their entropy is just M < 64, for
example 14? Why not simply use unknown-keys with 14-bits?
Could have been so -- in fact, I can just use the *first* 14-bits of the
64-bit space and leave the rest empty. This was not specified and does not
need to be because DES will avalanche even one-bit change in the ciphertext
into a 50% probability of changing any bit of the deciphered plaintext.
But, specifying 64-bits opens another very large source of variability --
50-bits of it, for a third key. This third key however needs to be secret, not
unknown, since the workload to discover it would be unreasonable. True, such
extra-secrecy would not allowed under Wassenaar export-free terms, but... does
not mean it cannot be used inside the US (for example) or even exported by a
non-Wassenaar country such as Tanzania or Brazil (for example). This is
commented in the paper, at http://www.mcg.org.br/unicity.txt and turns M-DES
into a 120-bit cipher.
Thus, since M-DES uses the chosen key and XOR'ed with a DES ciphertext block
-- which has 64-bits -- the method already leaves room to place those 14-bit
numbers anywhere in the 64-bit space, which allows one to use 120-bit DES.
> In any desired way for a 56-bit DES protocol, both Bob and Alice have
> Trust on a 56-bit secret-key, which key value is Ignored by any
> attacker.
How was this secret-key exchanged?
As noted in the paper, it is not relevant here how Alice knows the DES
secret-key she shares with Bob, and why the attacker does not. This will be
the subject of another exposition, as it pertains to a similar discussion of
security for asymmetric cryptography -- public/private-key pairs also limited
by the WA. For the moment, just suppose that Bob and Alice met and Alice
received the secret-key (or, for example they exchanged floppies with
1,000's of 56-bit DES keys to be used in sequence).
>
> The difference begins now, with an additional protocol that allows
> Alice to quickly develop Trust on what she Ignored, the 14-bit
> "Unknown-Key", much sooner than any attacker that needs to develop
> Trust on (56 + 14) bits. Note that the attacker faces 2^56 more
> variability then Alice -- a very large difference.
>
> Regarding attack time, this difference is of the order of 75 years,
> as calculated below, even for the fast EFF DES-cracker [EFF98]. And,
> under usual "Personal Computer resources", Alice should not take more
> than a few seconds to calculate the "Unknown-Key" -- which she only
> needs to do once for several messages [Ger99].
>
My computer would take 30 seconds to calculate such 14-bit key!
No problem ;-)
If you so configure M-DES, then it shoud tell Bob in an automatic cipher
negotiation phase, that you only accept at most M = 9 -- this gives you less
than one second of latency time and an effecive key-length of 65-bits! Not
bad, considering that is not export-allowed even with a license, under WA
terms.
BTW, can anyone share how much their computer/software combination needs to
encipher 64K byte of data? This will be (roughly) the latency-time for
key-discovery in a 70-bit M-DES protocol.
> But, Bob already Trusts the 14-bit key -- he does not need to "find"
> it! Thus, Alice can use the same 14-bit when replying to Bob. Bob has
> no time loss, not even for first message. Bob and Alice are now
> communicating with a 70-bit secret-key, bootstrapped from a 56-bit
> key.
>
> Thus, at the end of the full M-DES protocol, a two-way communication
> channel with a Trusted secret-key of 70-bits is thus formed between
> Bob and Alice. Which secret-key is Ignored in all 70-bits by an
> attacker.
>
> 3. SECURITY
>
> A different question is: what is the expected lifetime of this secure
> channel, for total plaintext length L under a single 70-bit key, as a
> function of the attacker's resources?
>
> The attacker needs to solve an average of 2^69 DES decryptions for
> one block of length 8 bytes (with the revised DES unicity presented
> in [Ger99], not three as usually quoted). To have an idea how much
> this is in time, suppose the EFF DES-cracker [EFF98] would take an
> average of 40 hours (for 50% search) to break 56-bit DES. Then, the
> same DES-cracker would take about 27,307 days to break the discussed
> 70-bit scheme -- approximately 75 years.
>
> Thus, Alice and Bob can enjoy 70-bit protection with export-free
> 56-bit DES, for a v e r y l o n g time ;-)
>
But, what happens if Wassenaar changes and restricts this method?
The proposed method depends on Ignorance -- no one has ever been able to limit
Ignorance ;-) You cannot limit what is not known.
As some regulations show, BTW.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Fri, 29 Jan 1999 16:20:20 +0100
R. Knauer wrote:
>
> Your comments are directed at showing reasons for suspecting that a
> generator is not random. What do you do if your statistical tests
> indicate that it IS random?
Since you have been all the time disclaiming the usefulness of
statistical tests, the formulation of your question surprises me.
For it possibly indicates that you are rather unfamiliar with
such tests (apology if I am wrong). With statistical means you
can NEVER expect to 'prove' something 'is' or 'is not' (in the
absolute sense). Elsewhere Parick Juola has given good exposition
of the essence of statistics. With my very humble knowledge I
certainly can't do better. But perhaps I could attempt to give
the following as a supplement to the topic of what a statistical
test performs: One has a hypothesis H_0 and wants to investigate
it statistically. One takes a sample. Given a confidence level
alpha, one evaluate the value t of a test function T corresponding
to the hypothesis and see if t is in the critical domain D of T
for the given value alpha. If yes, H_0 is rejected (at the given
confidence level). Otherwise one can only conclude that result
of the test does not contradict H_0 (but it does NOT prove H_0!)
So you see people doing statistical tests are very prudent and
very modest ones. They never say anything categorically ('for sure',
IS or IS NOT) but rather say 'something is fairly unlikely to be
true' or 'there is not enough evidence to believe that it is false'.
(Compare such categorical statements as 'anything from software
IS not crypto-grade' and 'everything from hardware IS crypto-grade'.)
M. K. Shen
------------------------------
From: "Phil Sumner" <[EMAIL PROTECTED]>
Subject: Public Key encryption
Date: Fri, 29 Jan 1999 15:39:34 -0000
I am not entirely sure if this is apporpriate for this group, but I am stuck
for other sources...
I am a 1st year student at Uni and I took it upon myself to try and improve
my A-Level encryption program (which used very basic translation as it's
encryption) so that it could use public key encryption... My question is,
where could I find a reasonably detailed description of how to implement
such an idea? I have searched some already but most of the sites are either
way over my head (i.e. - presuming detailed knowledge of maths) or way below
the standard that I need...
Any help would be much appreciated
Phil Sumner
--
[EMAIL PROTECTED] | msn.uk.forums.grapevine
Phil-99 on #chatquiz1, | msn.uk.forums.chatquiz.*
publicchat.msn.com | ICQ # - 3320949
"Faith Manages"
------------------------------
** 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
******************************