Cryptography-Digest Digest #793, Volume #9 Mon, 28 Jun 99 16:13:04 EDT
Contents:
Re: one time pad (William Tanksley)
Re: one time pad (William Tanksley)
Re: one time pad (William Tanksley)
Re: The One-Time Pad Paradox ([EMAIL PROTECTED])
Re: one time pad (Mickey McInnis)
Hardware RNG description (Medical Electronics Lab)
Re: one time pad (Greg Ofiesh)
Re: Interesting RSA question (Doug Stell)
Re: one time pad (William Tanksley)
Re: crypt basics (Keith A Monahan)
Re: one time pad (Patrick Juola)
Re: one time pad ([EMAIL PROTECTED])
Re: one time pad (Patrick Juola)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: one time pad
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Jun 1999 18:18:20 GMT
On Sat, 26 Jun 1999 19:08:28 GMT, Greg Ofiesh wrote:
>> One example of a good way is to take a
>> 3-gate NOT cycle (that is, hook a NOT up to a NOT up
>> to a NOT, then attach the output of the last one to the
>> input of the first). Put that on a chip, and
>> put a few others like it at other places on the chip...
>This is interesting. Have there been any published studies on this
>approach?
I know of at least one product which uses this, and is backed by some good
crypto people. I don't know whether they've published the details yet.
There are other details involved; it's obvious that although the resultant
stream is "random" in some senses, it also can easily develop imbalances
toward zeroes and ones, so some other steps are used (such as interposing
the ANSI/FIPS RNG between it and the RNG output).
>Sent via Deja.com http://www.deja.com/
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: one time pad
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Jun 1999 18:31:38 GMT
On Sun, 27 Jun 1999 01:27:51 -0400, [EMAIL PROTECTED] wrote:
>AllanW wrote:
>> Doesn't the existance of a secure channel imply that no
>> encryption is needed?
>No. This issue may belong in the FAQ. The secure channel may have
>timing characteristics that make it unacceptable for real-time
>communication, but acceptable for keypad communication. Condsider a
>ship. At dock you can very easily transfer arbitrary amounts of pad
>quite cheaply, and with almost total security. At sea, however, you
>have no secure channel. I.e., it is intermittent, but the channel
>capacity is unreasonably high.
Also, the OTP key does not itself carry any sensitive information, so if
it gets compromised it's possible to recover (by making and delivering a
new key).
A secret agent carrying a message is in danger of death -- his info is
still useful when he's dead. An agent carrying a OTP is in much less
danger; if there's any chance of intercepting the key it has to be done
without making it obvious, and certainly without preventing the other side
from getting the key in the first place.
And killing the agent just to prevent the key from being delivered is only
done in wartime or with appropriate blackmail leverage (they will just
send another agent over).
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: one time pad
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Jun 1999 18:32:18 GMT
On 27 Jun 1999 20:10:36 GMT, David A Molnar wrote:
>[EMAIL PROTECTED] wrote:
>> No. This issue may belong in the FAQ. The secure channel may have
>By the way, is there a project underway to update the crypt
>cabal FAQ ? I remember seeing some discussion of this, but
>wasn't following it closely enough.
There is no cabal. It would be nice to have a FAQ update, though.
>-David Molnar
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
Date: Mon, 28 Jun 1999 01:33:20 -0400
From: [EMAIL PROTECTED]
Subject: Re: The One-Time Pad Paradox
S.T.L. wrote:
>
> I don't consider this a paradox.
>
> <<The One-Time Pad is the one theoretically perfect cipher. Provided it is
> applied in strict accordance with the theoretical conditions.>>
>
> Right on.
>
> <<One must use a key that is truly and genuinely random.>>
>
> Absolutely.
>
> <<Now, there is a small, but finite, probability that the random key will
> happen to be 000000...>>
>
> Right you are.
>
> <<If one uses such a key, one is sending one's message in plaintext.>>
>
> Yep. The Adversary doesn't know that it is the correct plaintext, however, and
> because he knows neither the key nor the correct plaintext he cannot decide
> whether the encrypted message he sees is identical to the correct plaintext or
> says something completely different.
>
> <<If one refuses to use such a key, one is causing one's key to be
> nonrandom, hence one is spoiling the perfection of the one-time-pad.>>
>
> Absolutely!
>
> <<This qualifies as a genuine paradox, and as such may well be fruitful,
> just as paradoxes in mathematics and physics have occasionally led to new
> paradigms.>>
>
> I don't consider it a paradox. Interesting, but not really.
>
> <<One way to resolve the "next step" after this paradox: let us suppose
> one's key *does* look random, but applying the key to the message creates
> what _appears_ to be the plaintext of a message saying (in different
> words) essentially the same thing as the message you want to keep
> secret...>>
>
> Could be. The rest of your message I'm not quoting because A) I don't
> understand it, and B) It can't help.
>
> You seem to be forgetting (so it seems to be) another possibility: One's key
> could look random, but applying the key to the message creates what _appears_
> to be the plaintext of a message saying a completely different thing as the
> message you want to keep secret. The probability of getting any one specific
> message of this type is, of course, exactly the same as the "null key case".
> When the adversary sees your ciphertext, he CANNOT decide whether this last
> possibility, your "similar message possibility", or the "null key" possibility
> has occurred.
I disagree. While your statement is correct in a wold of perfect
implementations _and_ perfect operators, it is false in a very practical
sense. Given that I know something about the context of the message, I
can estimate its plausibility. I can compare that plausibility against
the possibility that an operator error transmitted the plaintext en
clair by accident. Since this is almost always going to come out in
favor of an operator error (for non-trival message length) over the
probability of accidentally creating a cipher text that is intelligible
at all, I'll make the right decision.
(The number of "completely different plaintexts" is much greater
> than the single "null key" and probably larger than the number of "similar
> plaintexts"). If the Adversary tries to guess that you are sending plaintext in
> the clear, it still doesn't help him because for all he knows, he is being
> fooled by a similar plaintext.
>
> Moral of this story: You were absolutely correct that munging a one-time-pad
> spoils its perfection. "Null keys" or "similar plaintext producing keys" don't
> change that, and in my eyes aren't a paradox because of the existence of
> "completely different plaintexts".
>
> -*---*-------
> S.T.L. ===> [EMAIL PROTECTED] <=== BLOCK RELEASED! 2^3021377 - 1 is PRIME!
> Quotations: http://quote.cjb.net Main website: http://137.tsx.org MOO!
> "Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!" e^(i*Pi)+1=0 F00FC7C8
> E-mail block is gone. It will return if I'm bombed again. I don't care, it's
> an easy fix. Address is correct as is. The courtesy of giving correct E-mail
> addresses makes up for having to delete junk which gets through anyway. Join
> the Great Internet Mersenne Prime Search at http://entropia.com/ips/ Now my
> .sig is shorter and contains 3379 bits of entropy up to the next line's end:
> -*---*-------
>
> Card-holding member of the Dark Legion of Cantorians, the Great SRian
> Conspiracy, the Triple-Sigma Club, and the Union of Quantum Mechanics
> Avid watcher of "World's Most Terrifying Causality Violations", "World's
> Scariest Warp Accidents", and "When Tidal Forces Attack: Caught on Tape"
> Patiently awaiting the launch of Gravity Probe B and the discovery of M39
> Physics Commandment #3: Thou Shalt Conserve Baryon Number.
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: one time pad
Date: 28 Jun 1999 17:24:05 GMT
Reply-To: [EMAIL PROTECTED]
urfr.com>
Organization:
Keywords:
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) writes:
|> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
|> >John Savard wrote:
|>
|> >> But in real life, our RBG might generate all zeroes because of a
|> >> short circuit, ...
|>
|> >Yes, that was the idea of the FIPS-140 tests, which weren't allowed to
|> >monitor the "internals" of the key generator but only the key stream.
|>
|> >However, you're switching context. The fellow was claiming that
|> >patterns should be eliminated from the output of a *correctly
|> >functioning* random bit generator to improve security, and *that*
|> >idea is completely wrong.
|>
|> I'll agree it's:
|>
|> - theoretically unsound, and
|>
|> - completely wrong to remove _short_ patterns
|>
|> but while I am not ready to advocate the practice, I think an issue is
|> being raised that can't be completely dismissed.
|>
|> John Savard ( teneerf<- )
|> http://members.xoom.com/quadibloc/crypto.htm
I think it's fairly simple.
1) If your random number generator produces a sequence that makes you think
it's broken, you must stop and analyze it to see if it's broken. You must
not use its output until you convince yourself it's not broken. (including
any previously generated, but not used output.)
2) You can't just throw away "obviously bad" sequences. Even the
"not obviously bad" sequences are suspect, too, if your RNG is broken.
3) If you do throw away the "obviously bad" sequences, you have to some
degree, reduced the randomness of the remaining sequences.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Hardware RNG description
Date: Mon, 28 Jun 1999 12:22:54 -0500
If anyone wants to play in their basement,
here is a description of a hardware RNG which
can be built with a smoke alarm and some op amps.
A lot of testing went into this to make sure it
was "random". The paper was submitted and
accepted, but the workshop didn't have room
so it got bumped. You can find the paper here:
http://www.terracom.net/~eresrch/detecting_random.
ps
It's in postscript format with no fonts attached
to make download shorter.
What I think makes this unique is that there is
no dead time to deal with. All other radioactive
RNG's have to deal with this and other problems.
This was a fun project, and now that I've got my
Linux box running I can add the RNG to create
a /dev/random. I hope others out there have
fun with it too.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Mon, 28 Jun 1999 19:13:02 GMT
>...Personally, I doubt it, but you never know...
I agree so much with your statement on predicting radio active decay
that I would even bet my life on the proposition that we will never be
able to predict decay. And that is the first and (at this time) the
only thing I would be willing to bet my life on.
> Even if we start with the assumption that we can implement
> an OTP in a way that really matches the spec, so it's truly
> unbreakable, we're left with the more fundamental problem
> that it's not useful in most common situations anyway -- it
> still has a key that's just as large as the text being encrypted,
> rendering it worthless in the average situation.
I must tell you, I keep hearing people say several things over and over
again and yet I have NO IDEA what they are talking about (not that I
think they are wrong, but I wonder if some of them know themselves).
For example, what is the definition of "most common situation" that
would make OTPs useless?
What is the definition of the "average" situation that makes OTP
worthless?
And why has anyone even come to believe that my (unstated) plans for
OTP use are common or average?
Don't get me wrong, I am not upset. I am just curious what people mean
by these over generalized statements and what they think my intentions
are based on what little I have stated.
The US Military, I was told, uses OTPs for their most sensitive
communications (what ever those are).
> We have quite a few symmetric ciphers that as far as we
> know at the present time aren't breakable. Even if we
> assume that they're entirely secure, they're still not
> useful if what you really need is a public-key style cryptography.
I never mentioned public key and I don't believe it is nearly as useful
as it is being touted. Look at the whole concept of Certifying
Authorities. The question that comes into my mind is, "Who are they?
Can they become corrupt? Would I trust them with my data?" So you can
see that in my mind, PKey is almost useless just on that grounds alone.
> In the end, trying to talk about whether it's better to use public-
> key, symmetric or OTP cryptography is mostly a pointless gesture.
> Each does different sorts of things. Believing that an algorithm
> provides a high level of security is pointless if it simply won't do
> the sorts of things you want or need to get done.
The discussion, as I see it, has to do with provable security. In the
end, I would use encryption ABC if that was absolutely the only one
that could be proved uncrackable. My application is specialized and I
can for the most part work with the requirements and restrictions of
almost any cipher. Remember, I am the one seeking information to
validate my decision to deploy OTPs, and I have already considered the
extreme logistics of its deployment.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Interesting RSA question
Date: Mon, 28 Jun 1999 19:00:40 GMT
On Mon, 28 Jun 1999 16:56:47 GMT, [EMAIL PROTECTED] (Gilad
Maayan) wrote:
>Thanks for your reply.
>
>About that padding - if it's completely random, you wouldn't be able
>to read the decrypted message, would you? I assume you'd have to have
>some sort of padding technique that would allow you to descramble the
>original message from the padding and read it, once decryption has
>taken place. Correct me if I'm wrong.
You need some way of knowing how much padding was added and then
discard that padding and the length indicator after decryption.
Remember that the padding and length indicator are appended to the
plaintext, not scrambled in with it. You must also watch the most
significant bit.
Think of basic RSA as a block cipher, where the "useful' plaintext
block is 1 bit shorter than the modulus size. This is because the
message must be numerically less than the modulus. It is easier to
make the most significant bit or byte of the "actual" plaintext block
alway a zero than to deal with constraining the value of the other
bits to insure that they are less than the modulus.
As with any other block cipher, you must pad out a short plaintext to
the block size. The ciphertext block size is the same as the modulus
and will also be numerically less than the modulus. As with any other
block cipher, you can not truncate the ciphertext without destroying
the decryption.
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: one time pad
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Jun 1999 19:27:48 GMT
On Mon, 28 Jun 1999 00:57:57 -0400, [EMAIL PROTECTED] wrote:
>> We have no proof because there really *is* no proof. These are not
>> just word games. Our supposedly invulnerable OTP might fail and we
>> probably would never know, and would go on using that same failing
>> cipher, all while claiming it to be invulnerable. *That* is the
>> consequence of having no proof.
>Show me. Construct a plausible kaypad flaw and illustrate how an
>attacker might utilize it. I'll stipulate that the adversary can
>detect the flaw with certainty.
Okay, suppose we use a random bit source which turns out to be RC4, keyed
from a 40-bit key. (But the salesman said...! :-)
An implausibly bad weakness from a system which claimed to be OTP, but
then we all recall one such which came out quite recently. Lesser
weaknesses can be plausibly invented, but would require me to invent an
algorithm to predict their bits.
>N.B., toy messages are not illustrative. Let's use a floor of, say, 256
>bits on the message.
Toy or not, that so-called OTP can be easily cracked by brute force.
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: crypt basics
Date: 28 Jun 1999 19:52:49 GMT
Bernd,
Well, Applied Cryptography by Bruce Schneier would be a good choice. I think
most people consider the book to be the definitive reference for the field.
I think the 2nd edition is the most current.
I also bought a book awhile back called Cryptography and Network Security,
by William Stallings. Good book, more recent than AC but reminds me
a little of a schoolbook text - other than that, its good.
Both of those have been invaluable to have around... And they aren't too
difficult to read, although some sections get pretty involved.
Keith
Bernd Wachmann ([EMAIL PROTECTED]) wrote:
: Dear all,
: I'm new in the field of cryptography and I would like to
: ask some of you, which books would be good to
: learn the basics and which journals and internet
: homepages could help to get information about
: state of the art cryptography.
: Thanks in advance,
: Bernd Wachmann
: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 28 Jun 1999 15:46:24 -0400
In article <7l8hfi$poi$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>> Even if we start with the assumption that we can implement
>> an OTP in a way that really matches the spec, so it's truly
>> unbreakable, we're left with the more fundamental problem
>> that it's not useful in most common situations anyway -- it
>> still has a key that's just as large as the text being encrypted,
>> rendering it worthless in the average situation.
>
>I must tell you, I keep hearing people say several things over and over
>again and yet I have NO IDEA what they are talking about (not that I
>think they are wrong, but I wonder if some of them know themselves).
>
>For example, what is the definition of "most common situation" that
>would make OTPs useless?
>
>What is the definition of the "average" situation that makes OTP
>worthless?
The major weakness of the OTP is that it requires that the key
be as long as the message and sent securely over a channel.
If you have a secure channel of sufficient capacity to take the
key, it will also (by definition) take the message -- so why
are you bothering with using an OTP?
The most common application in cryptogrphy is where a secure
channel is available, but of *MUCH* lower capacity than the
insecure channel to which cryptogrphy is applied. If no secure
channel is available, symmetric crypto is completely inappropriate;
if the secure channel is equally available and has equal or
greater capacity, cryptography in general is inappropriate.
>And why has anyone even come to believe that my (unstated) plans for
>OTP use are common or average?
Because, again by definition, most uses are common/average, and
unless you state otherwise, people will -- and should -- assume
that your uses are otherwise typical.
If you have special needs or equipment, then it's *your* responsibility
to make them clear.
>The US Military, I was told, uses OTPs for their most sensitive
>communications (what ever those are).
Hearsay evidence at best. I've heard this at least from at least five
different sources, suggesting at least five different types of
communication that ``uses OTPs''; I suspect you're being told something
from someone who doesn't really know what's going on.
>> We have quite a few symmetric ciphers that as far as we
>> know at the present time aren't breakable. Even if we
>> assume that they're entirely secure, they're still not
>> useful if what you really need is a public-key style cryptography.
>
>I never mentioned public key and I don't believe it is nearly as useful
>as it is being touted. Look at the whole concept of Certifying
>Authorities. The question that comes into my mind is, "Who are they?
>Can they become corrupt? Would I trust them with my data?" So you can
>see that in my mind, PKey is almost useless just on that grounds alone.
So don't use a certifying authority. Other models exist, including
web-of-trust or individual certifiers.
>> In the end, trying to talk about whether it's better to use public-
>> key, symmetric or OTP cryptography is mostly a pointless gesture.
>> Each does different sorts of things. Believing that an algorithm
>> provides a high level of security is pointless if it simply won't do
>> the sorts of things you want or need to get done.
>
>The discussion, as I see it, has to do with provable security. In the
>end, I would use encryption ABC if that was absolutely the only one
>that could be proved uncrackable. My application is specialized and I
>can for the most part work with the requirements and restrictions of
>almost any cipher. Remember, I am the one seeking information to
>validate my decision to deploy OTPs, and I have already considered the
>extreme logistics of its deployment.
In other words, don't confuse you with facts as your mind is already
made up. Have fun.
-kitten
------------------------------
Date: Mon, 28 Jun 1999 03:38:51 -0400
From: [EMAIL PROTECTED]
Subject: Re: one time pad
William Tanksley wrote:
>
> On Sun, 27 Jun 1999 01:54:55 -0400, [EMAIL PROTECTED] wrote:
> >William Tanksley wrote:
>
> >> There is NO single stream of data coming out of an alleged RNG which would
> >> prove to me that it wasn't an RNG.
>
> >Well I have this special RNG that meets these criteria. It's quite
> >cheap. It is also sold under the name "zero ohm resistor", but for
> >today only, I'll make a special offer of $10.00 each.
>
> Did I mention that there's no single stream which can prove (or even
> suggest) to me that an alleged RNG is in fact a true RNG?
>
> Now, give me control and let me generate what I consider to be multiple
> streams (under my control), and let me see the generator's details, and
> let people who specialize in the details see them, and after a while I'll
> consider it suggested that the thing is an RNG.
The interesting issue isn't that you would decide, but how you would
decide. Do you use Karnak's Criteria (hold envelop to forehead)? Is
there anything in your decision process that does not fit into a DTM?
If it all fits in a DTM it can be completely automated.
If it can be automated it can run in real time. If it runs on the
output of your generator, how will you react if/when it complains?
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 28 Jun 1999 15:47:43 -0400
In article <7l8hok$psb$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>
>> And saying that an OTP is provably secure can be accurately
>> interpreted to mean that no sudden collapse _of the cipher_
>> is possible in the way that PKC is theoretically vulnerable
>> to advances in applied math.
>
>This is one of the points I have been trying to articulate all this
>time. That while OTPs are provable only in theory, the others are not
>provable at all, and in fact in theory are crackable given enough and
>proper resources (which WILL come in time).
I see. And how much time do you anticipate until a brute-force
search of a 256-bit keyspace is practical.
There are several other provably secure cyphers that are no
less impractical than a true OTP. As in, they're all next
door to useless in Real Life.
-kitten
------------------------------
** 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
******************************
