Cryptography-Digest Digest #224, Volume #9 Thu, 11 Mar 99 14:13:04 EST
Contents:
Re: Limitations of testing / filtering hardware RNG's (R. Knauer)
Re: Quantum PRNG (Mok-Kong Shen)
Re: Estimate time? (Medical Electronics Lab)
Re: prob. of a given subsequence in a sequence (R. Knauer)
prob. of a given subsequence in a sequence ("Gustavo")
prob. of given subseq. in a random seq. ("Gustavo")
Re: Quantum Computation and Cryptography (R. Knauer)
ZKS Freedom Server ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (Patrick Juola)
Re: Funny mail? (Medical Electronics Lab)
Documentation for PGPsdk 1.1 (Missaka Wijekoon)
ZKS Freedom Server ([EMAIL PROTECTED])
Re: Quantum Computation and Cryptography (Richard Herring)
Re: Really Nonlinear Cipher Idea (John Savard)
Re: Really Nonlinear Cipher Idea (John Savard)
Re: Limitations of testing / filtering hardware RNG's (Mark Currie)
Re: Limitations of testing / filtering hardware RNG's (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Thu, 11 Mar 1999 15:33:40 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 11 Mar 99 14:37:03 GMT, [EMAIL PROTECTED] (Tom Thomson)
wrote:
>>The purpose of a TRNG is to circumvent those issues. It is a
>>stand-alone true random number generator. It does not need to have its
>>output tested (other than as a diagnostic warning) and it certainly
>>cannot tolerate having its output filtered.
>If that is true, a TRNG cannot be used to generate keys where the encryption
>algorithm used has a significant proportion of weak keys; since no such key
>can safely be used.
We are talking about the (proveably secure) OTP cryptosystem. In that
context, please define "weak key". (See comments below.)
>Nor can it be used to generate salts for stream encryption (since here
>filtering to eliminate duplicates is required).
>Really Bob, I think what you are trying to say is that statistical test on the
>output can tell you there's a problem
*potential* problem. After diagnosing the TRNG, it may be decided that
there was no problem after all.
> but can never tell you there's nothing wrong,
Statistical testing of the utput can never tell you anything
definitive about the operation of the TRNG. All it can do is alert you
to a potential problem on a probabilistic basis.
IOW, significant deviation from statistical randomness gives you a
probabilistic measure of *potential* problems, but it can never tell
you with absolute certainty that there is a real problem.
If so, then statistical tests could be used to break the casinos in
Las Vegas. As Li & Vitanyi point out, probability theory is only
meaningful when you are forced to place even money bets on the next
outcome. That is their tongue in cheek method of telling people who
worship the false god of statistical prediction to put their money
where their mouth is.
>and certainly can't be used to manipulate the output to "put it
>right".
Correct. Any manipulation of the output throws the TRNG out of spec.
>If that IS what you intend to say, i agree with you;
Pretty much so, with the minor changes above.
>but much of what
>you write seems to be asserting something much stronger than that - something
>which, as indicated by the two clear requirements for filtering pointed out
>above, is in fact patently untrue.
Those two "clear requirements" are not for filtering - they are for
diagnostic warnings.
There is nothing in the specification of the TRNG that says it must be
run continuously. It can be stopped for diagnostic evaluation anytime
- especially when the output has the characteristic of a severly
pathological condition, namely a grounded or floating output.
I realize that in effect this constituted filtering, since presumably
that "diagnostic" output will be discarded even if the TRNG proves not
to be malfunctioning. If it will make you feel any better, imagine
that you use that buffered output to continue the keystream, if you
discover that the TRNG is not malfunctioning.
There is an important issue (IMO) here that should be addressed, which
will circumvent the problem of a null run. Even though the standard
protocol for the OTP cryptosystem calls for simple XOR mixing of the
plaintext with the keystream, common sense obviates that practice. In
reality we should be talking about some kind of cryptographically
strong mixing scheme, such as those suggested by Terry Ritter, and
those found throughout the literature.
The authors of the book "Stream Ciphers and Number Theory" discuss
additive mixing schemes and point out their vulnerablilty. They go on
to recommend other mixing schemes to prevent such vulnerabilities.
Thus, a sequence of all 0s would not expose any cleartext message if
the mixing is cryptographically strong - the cryptanalyst would have
no reason to know that the keystream was composed of a run of 0s.
Maybe we need to call this form of OTP a "Strongly Mixed OTP" to avoid
any confusion. I just thought it was taken for granted in today's
crypto discussions.
Bob Knauer
"There's no way to rule innocent men. The only power any government
has is the power to crack down on criminals. Well, when there aren't
enough criminals, one makes them. One declares so many things to be
a crime that it becomes impossible to live without breaking laws."
--Ayn Rand
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Quantum PRNG
Date: Thu, 11 Mar 1999 16:48:24 +0100
R. Knauer wrote:
> Yes, that's the von Neumann anti-skewing algorithm. Has anyone proven
> that it does not result in a higher degree of correlation?
One of von Neumann's basic assumptions is that the random variables
are independent. For practical sequences this can't be absolutely
(perfectly) true and there exists some dependency leading to
correlations. Then it is certainly possible, even if the chance
is negligible, to have very special cases where the application of
the algorithm leads to a worse result. Note that it is easy
to 'construct' sequences (apparently not very regular) such that the
result of applying the algorithm gives e.g. all 1's.
M. K. Shen
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Estimate time?
Date: Thu, 11 Mar 1999 09:42:03 -0600
Jonas Th�rnvall wrote:
>
> I see no way to move slightly closer to the solution without to have the
> whole complete password.
> So if i use 10 byte for the password you have to tryout 256 exp10
> combination to figure it out.
>
> Brute force only way? I have hard to estimate amount of possible outcome
> streams, but i guess it will be close to the possible password combinations.
>
> How long time will it take to figure it out on a pentium pro 400mhz, if i
> use 15 bytes?
Brute force is not the only way. Use a dictionary, and set it up
with various patterns of capitals, smalls and some punctuation.
If each character can be one of 256, but the user picks only ascii,
you have a much better chance of "guessing" the password.
A passphrase that consists of several words is better, but most
people don't like to type that much :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: prob. of a given subsequence in a sequence
Date: Thu, 11 Mar 1999 17:34:02 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 11 Mar 1999 11:37:31 +0100, "Gustavo" <[EMAIL PROTECTED]>
wrote:
>Hi everyone.
>I would like to know how to compute the probability
>that a given subsequence of length S is part of a
>larger random sequence of length L.
>It seems that the probability depends on the sub-
>sequence (maybe on its autocorrelation properties?)
>but I have not been able to find the relation yet.
>Thank you very much for any help.
According to the book "Stream Ciphers and Number Theory" (Sec. 2.3.2,
p. 29), for a binary sequence of period ((2^n) - 1) there are 2^n runs
of various lengths in each periodic subsequence of length ((2^n) - 1).
A run is defined as a sequence of all the same digit, either all 1s or
all 0s.
1/2 the runs have length 1, 1/4 have length 2, 1/8 have length 3,
etc., until two runs have length n-2. For each of these runs there are
equally many having all 1s as there are having all 0s. There is one
run of all zeros of length n-1 and one run of all 1s of length n.
These are called Golomb's three randomness postulates.
If these runs were not equidistributed, the resulting ciphers would be
open to differential attack. Notice that the usual statistical tests
do not take patterns like this into account fully, and for that reason
they cannot be used to characterize a keystream for purposes of crypto
strength.
Bob Knauer
"There's no way to rule innocent men. The only power any government
has is the power to crack down on criminals. Well, when there aren't
enough criminals, one makes them. One declares so many things to be
a crime that it becomes impossible to live without breaking laws."
--Ayn Rand
------------------------------
From: "Gustavo" <[EMAIL PROTECTED]>
Subject: prob. of a given subsequence in a sequence
Date: Thu, 11 Mar 1999 11:37:31 +0100
Hi everyone.
I would like to know how to compute the probability
that a given subsequence of length S is part of a
larger random sequence of length L.
It seems that the probability depends on the sub-
sequence (maybe on its autocorrelation properties?)
but I have not been able to find the relation yet.
Thank you very much for any help.
Gustavo
------------------------------
From: "Gustavo" <[EMAIL PROTECTED]>
Subject: prob. of given subseq. in a random seq.
Date: Thu, 11 Mar 1999 11:38:57 +0100
Hi everyone.
I would like to know how to compute the probability
that a given subsequence of length S is part of a
larger random sequence of length L.
It seems that the probability depends on the sub-
sequence (maybe on its autocorrelation properties?)
but I have not been able to find the relation yet.
Thank you very much for any help.
Gustavo
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Quantum Computation and Cryptography
Date: Thu, 11 Mar 1999 17:49:54 GMT
Reply-To: [EMAIL PROTECTED]
On 11 Mar 1999 16:56:32 GMT, [EMAIL PROTECTED] (Richard Herring)
wrote:
>> My guess is that the precision you can get from
>> quantum-magic computation things is limited by Heisenberg's Uncertainty
>> Principle,
>> which says you shouldn't be able to get much more accurate than Plank's
>> Constant.
>It also says that (in principle) you can get as accurate as you like,
>provided that you don't care about the value of the conjugate observable.
There is a good writeup of the Uncertainty Principle in terms of
Quantum Information Theory in the paper by Cerf and Adami:
Title: Quantum Mechanics of Measurement
Authors: N. J. Cerf, C. Adami (California Institute of Technology)
quant-ph/9605002
http://xxx.lanl.gov/find/quant-ph/1/cerf/0/1/0/96/1/0
Basically the idea is that there is a certain amount of combines
entropy for a pair of conjugate variables, and if you arrange things
to lower the entropy of one of them, the other increases in entropy.
For example, if you make one variable completely knowable then the
other is completely unknowable.
The authors go on to derive a new uncertainty relation in entropic
terms that is stronger than the standard Heisenberg formulation that
is based on a dispersion calculation.
Bob Knauer
"There's no way to rule innocent men. The only power any government
has is the power to crack down on criminals. Well, when there aren't
enough criminals, one makes them. One declares so many things to be
a crime that it becomes impossible to live without breaking laws."
--Ayn Rand
------------------------------
From: [EMAIL PROTECTED]
Subject: ZKS Freedom Server
Date: Thu, 11 Mar 1999 14:39:56 GMT
Has anyone used this system? They gave a presentation at last year's Defcon.
It sounded interested, but in reality it would be pretty slow.
Basically it provides a way to use the Internet anonymously by having
multiple layers of encryption that passes through many servers. Each server
strips off a layer of encryption eventually getting to the data that is being
transmitted.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: 11 Mar 1999 10:00:17 -0500
First :
TREVOR, QUIT POSTING IN THIS FCSKING HTML! It's damn nearly unreadable.
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>HTML>
>Jim Gillogly wrote:
>BLOCKQUOTE TYPE=CITE>I haven't been following this whole thread, so if
>I'm being irrelevant
>BR>or redundant, I apologize.</BLOCKQUOTE>
>The topic is not irrelevant. YOU have not been redundant.
>BLOCKQUOTE TYPE=CITE>Trevor Jackson, III wrote:
>BR>> R. Knauer wrote:
>BR>> > On 9 Mar 1999 15:03:26 -0500, [EMAIL PROTECTED] (Herman
>Rubin)
>BR>> > wrote:
>BR>> > >Not just as diagnostics; if the outcome HAPPENS to be all 0's
>or all
>BR>> > >1's, you would not want to use this for cryptography. There
>are other
>BR>> > >outcomes which one would not want to use.
>BR>> >
>BR>> > If you filter the output as you suggest, then the TRNG is no longer
>BR>> > proveably secure in principle.
>BR>>
>BR>> Show me the leak. Otherwise stop repeating this nonsense.
>
>P>OK. Just to be definite, let's assume that you have some threshold
>BR>T where if you see T 0's in a row, you will remove all of them from
>BR>the random bit stream, then pick up and continue. To make the
>example
>BR>obvious, let's assume T=8, so that we know there will never be a run
>of
>BR>8 0-bits in a row.
>
><P>We now have a message coming in. The ciphertext starts "YNAQJ
>BFPGD".
><BR>Since we know that there are never 8 0-bits in a row, we know that
>the
><BR>first character of the plaintext is not Y, the second character is
>not
><BR>N, the third character is not A, and so on. This is precisely
>one of
><BR>the weaknesses of Enigma, which allowed the Allies to place guessed
><BR>plaintext. I can tell with certainty that this message did not
><BR>start with "YES" or "INREP LYTOY".</BLOCKQUOTE>
>In principle (theory) you are correct. However, in practice it is
>meaningless. Consider the 10 character message that you used as an
>example. A perfect OTP would allow any plsible decruption of those
>10 characters or N^10 possible decryptions where N is 64 or 256 depending
>on your alphabet. Let's say N=64 to give you the maximum benefit
>of the doubt.
>
><P>Given the above we're talking about a space of 2^60 possible messages;
>or 10^18. Of these you have ruled out all messages containg one or
>more characters of all zero, which amounts to 2^10 possible pads; or 10^3.
Except that you're not talking about a space of 2^60 possible messages
in all likelihood; you probably know a lot more about the message
than simply that it's written in English. This reduces the possible
message space -- possibly by a LOT.
In particular, the attacker knows that the message (above) doesn't start
with "yes"; this means that *IF* he knows that the message is an
answer to a yes/no question, it's likely to have begun with "no"
instead.
-kitten
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Funny mail?
Date: Thu, 11 Mar 1999 11:00:46 -0600
Jonas Th�rnvall wrote:
>
> I've got one of those funny mail again can someone helpme?
> 219,130,185,17,49,74,102,9,80,5,59,154,253,74,93,25,43,29,197,226,184,138,15
> 3,144,113,60,28,157,225,179,49,93,210,15,128,137,17,136,156,207,97,114,165,8
> 7,35,32,102,132,159,14,0,176,200,240,152,42,191,88,23,107,207,139,218,39,243
> ,150,209,138,88,91,162,25,209,69,210,201,23,9,153,190,84,133,17,0,171,153,69
> ,25,136,139,185,59,220,134,41,128,161,243,130,196,203,91,51,153,50,41,169,23
> 1,120,43,27,24,1,74,37,137,248,179,179,139,117,75,248,17,10,147,136,226,96,1
> 59,174,165,153,101,48,173,21,139,131,24,206,27,128,145,187,35,202,130,105,25
> 0,161,28,209,133,16,152,134,241,152,187,201,226,50,42,61,155,12,74,100,3,146
> ,59,217,18,121,11,80,163,151,20,194,130,67,255,
This consists of 23 blocks of 8 bytes per block. If it's little
endian, you have to switch the order of either all 8 or each block
of 4 depending on how it was written out. What was the source?
This could just be binary header info for some program, but
there are lots of duplicate bytes so it might just be a simple
xor of a byte string.
Convert to hex, put it into 4 and 8 byte blocks and look for
patterns. Have fun!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Missaka Wijekoon <[EMAIL PROTECTED]>
Subject: Documentation for PGPsdk 1.1
Date: Thu, 11 Mar 1999 17:20:33 GMT
Does anyone know where I can get some good introductory material on the use pf
PGPsdk 1.1 from NAI? I have the reference doc, but that does not tell me what
functions are needed, in what order they are required, etc.
Any help would be greatly appreciated. Thanks.
--
========================================================================
Missaka Wijekoon (a.k.a. Misk) [EMAIL PROTECTED]
SoftTek http://www.sftek.com
30555 Trabuco Canyon #100 (949) 888-1181 x17
Trabuco Canyon CA 92678
========================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: ZKS Freedom Server
Date: Thu, 11 Mar 1999 14:40:00 GMT
Has anyone used this system? They gave a presentation at last year's Defcon.
It sounded interested, but in reality it would be pretty slow.
Basically it provides a way to use the Internet anonymously by having
multiple layers of encryption that passes through many servers. Each server
strips off a layer of encryption eventually getting to the data that is being
transmitted.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Quantum Computation and Cryptography
Date: 11 Mar 1999 16:56:32 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Bill Stewart ([EMAIL PROTECTED]) wrote:
> My guess is that the precision you can get from
> quantum-magic computation things is limited by Heisenberg's Uncertainty
> Principle,
> which says you shouldn't be able to get much more accurate than Plank's
> Constant.
It also says that (in principle) you can get as accurate as you like,
provided that you don't care about the value of the conjugate observable.
> If true (and intuition about quantum is often not true, especially from
> people
> who haven't cranked a Schroedinger equation in 20 years :-),
> this means that a precision of 10**-34
10^-34 *what*? Planck's constant isn't dimensionless. It isn't
a precision or a tolerance, it's a physical quantity.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Really Nonlinear Cipher Idea
Date: Thu, 11 Mar 1999 16:54:09 GMT
[EMAIL PROTECTED] (Jayant Shukla) wrote, in part:
>Boris Kazak <[EMAIL PROTECTED]> writes:
>> Combining various ciphers, on the other hand, should be data-dependent,
>>so that each plaintext would be encrypted along its own unique path.
> and how will you know how to decrypt the cipher-text if
>the unique path depends on the plain-text? There is a reason why
>all ciphers have fixed operation sequence.
>> Thus in addition to the variability of the key you are also using the
>>variability of the plaintext, making the analyst's work accordingly
>>more difficult.
> at the cost of making your own work impossible!
Well, actually there *is* a way around that. My "Mishmash" example, which I
noted to Mr. Kazak as an anticipation of his own idea, illustrates one such
way.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Really Nonlinear Cipher Idea
Date: Thu, 11 Mar 1999 18:18:40 GMT
[EMAIL PROTECTED] (Jayant Shukla) wrote, in part:
>Boris Kazak <[EMAIL PROTECTED]> writes:
>> Combining various ciphers, on the other hand, should be data-dependent,
>>so that each plaintext would be encrypted along its own unique path.
> and how will you know how to decrypt the cipher-text if
>the unique path depends on the plain-text? There is a reason why
>all ciphers have fixed operation sequence.
>> Thus in addition to the variability of the key you are also using the
>>variability of the plaintext, making the analyst's work accordingly
>>more difficult.
> at the cost of making your own work impossible!
>~Jayant
>p.s.: don't suggest that cipher-text include the unique path to
>help during decryption. ;-)
Well, I can see that the brilliant idea would lose some of its security if
that were done, but one CAN come close.
I'll outline my idea as used in Mishmash right here and now. Actually, it
isn't a new idea: I got it from Horst Feistel, you could say.
You remember Feistel rounds?
Left half Right Half
| |
XOR <---- f-function -------|
| |
Well, then, as you can see the f-function output is plaintext-dependent.
So, if we can XOR it with the left half - and have no problem decrypting -
then why can't we use our f-function output to govern a "unique path" of
operations that will be applied to the left half?
The ciphertext *does* include everything needed to reconstruct the "unique
path", but protected by the key to the f-function.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: 11 Mar 1999 18:30:57 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>Mark Currie wrote:
>> I am sure that there are many examples where a specific type of filter could
b
>e
>> useful to an attacker. However, if you are operating in a high performance
>> environment where you are dishing out numbers continuously, and you do not
>> continuously check for sudden heavy biasing of the RNG source, then you may
>> only discover the problem after many many potentially bad values may have
been
>> dished out.
>
>Hard disk space is cheap, isn't it? Why not buffer a meg of random bits,
>check it, then use them while you're generating the next meg worth? Why
>limit yourself to sending faster than you can test?
>
Usually the random numbers that you generate are extremely sensitive and you
don't want these hanging around for long periods. Putting them on a hard disk
leads to other problems of getting rid of them permanently. Also, if you are in
an embedded environment, you do not always have a hard disk handy. However,
there may well be situations where this approach is feasable.
Mark Currie
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Thu, 11 Mar 1999 10:32:43 -0800
Reply-To: [EMAIL PROTECTED]
I started replying to Patrick Juola's message (with which I agree) to add
a couple of points, but couldn't stomach the HTML. Trevor, <do> turn it
off for Usenet!
> > > R. Knauer wrote:
> > > > If you filter the output as you suggest, then the TRNG is no longer
> > > > proveably secure in principle.
> > Trevor Jackson, III wrote:
> > > Show me the leak. Otherwise stop repeating this nonsense.
> Jim Gillogly wrote:
> > OK. Just to be definite, let's assume that [you filter the TRNG
> > stream so that] there will never be a run of 8 0-bits in a row.
> >
> > We now have a message coming in. The ciphertext starts "YNAQJ BFPGD".
> > ... I can tell with certainty that this message did not
> > start with "YES" or "INREP LYTOY".
Trevor Jackson, III wrote:
> In principle (theory) you are correct. However, in practice it is
> meaningless. Consider the 10 character message that you used as an example.
> A perfect OTP would allow any plsible decruption of those 10 characters or
> N^10 possible decryptions where N is 64 or 256 depending on your alphabet.
> Let's say N=64 to give you the maximum benefit of the doubt.
I don't care what N is. Let's call it 26 for the purpose of exposition.
The point of a OTP is that it leaks no information. As soon as you let
it leak even one bit ("this letter is not a Y"), you lose all the theorems
and you must start being careful. Let's make my example even more pointed.
You are the chairman of the Federal Reserve of the Duchy of Florin, and
each day you send a message to all 100 branches of the Federal Reserve
bank, each of which has its own OTP to talk to you. The message is
one of "UPXX", "DOWN", or "EVEN". I have tapped your outgoing line. If
I can tell which way you're moving the interest rate before it reaches
the Florinese bourse, I get rich.
If you're using a true OTP with each of the branches, I'm out of luck. I
can see that you've sent 100 4-letter messages, and that's all. If one of
the messages says "DOWN", I shrug, since I know it was by chance. If you're
filtering as hypothesized above, I win almost every day with a simple
positional frequency count, because the 100 messages will have at most 25
letters in each of the four positions. It's a near certainty that one of
the letters of the other messages will appear in one or more positions of
the ciphertext, and I'll be able to eliminate those messages.
When you muck about with your TRNG stream this way, you lose all the
theorems about infallibility, and have to start doing other things to
achieve "acceptable" levels of confidence. You're then talking about
"good enough" rather than "perfect security".
OTP is a special case. If you muck with it, you must redo the analysis.
> > Filtering the TRNG stream in the way you suggest (eliminating runs
> > of 0's or 1's) breaks this assumption.
>
> In theory yes. In practice no. Try it yourself. Set up a filter allowing
> only the best 50% of pads and show that it "breaks" the cipher.
A cipher need not be read completely in order to leak some information.
A OTP does not leak any information other than a bound on the length.
--
Jim Gillogly
19 Rethe S.R. 1999, 18:02
12.19.6.0.4, 12 Kan 17 Kayab, Fourth Lord of Night
------------------------------
** 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
******************************
