Cryptography-Digest Digest #760, Volume #9 Thu, 24 Jun 99 11:13:03 EDT
Contents:
Re: 8-cycle DES ?? ("Richard Rooney")
Re: one time pad (Patrick Juola)
Re: RC4 Susectability ([EMAIL PROTECTED])
Re: one time pad (Patrick Juola)
Re: card shuffling related to rc4? ([EMAIL PROTECTED])
Re: OTP is it really ugly to use or not? ("RandAlthor")
Re: A different method of encryption ([EMAIL PROTECTED])
Re: OTP is it really ugly to use or not? ("RandAlthor")
Re: Kryptos article (Jim Gillogly)
Re: one time pad (Sundial Services)
Re: 1024-bit block cipher ([EMAIL PROTECTED])
Re: one time pad (Patrick Juola)
Re: Kryptos article (Michael)
Re: one time pad (Christopher)
Re: one time pad ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Richard Rooney" <[EMAIL PROTECTED]>
Subject: Re: 8-cycle DES ??
Date: Thu, 24 Jun 1999 14:15:46 +0100
Hi Paul,
I actually saw the term "8-cycle DES" on the Datasheet for the
VLSI Technology
VMS113 Cryptographic chip. This datasheet also contains a timing diagram
which shows that, 8 clock cycles after performing initial setup and register
loading,etc., output Ciphertext or Plaintext will be available i.e. the DES
core operates in 8 clock cycles.
I didn't understand your reply below, at first. Then I grasped the
significance of the word
"combinatorial". I always considered DES as 16 registered stages (or 1 stage
used 16 times) but it never dawned on me that it could be implemented in
combinatorial logic....which of course it can .....!!
Many thanks,
Richard Rooney.
Paul Rubin wrote in message ...
>In article <7kloc5$q0n$[EMAIL PROTECTED]>,
>Richard Rooney <[EMAIL PROTECTED]> wrote:
>>Can anyone enlighten as to how 8-cycle DES is done ?
>>FIPS 46-2 describes DES performed in 16 cycles.
>>I cannot see how this can be done in 8 cycles....
>
>I'm not sure what you mean by 8 cycles. What is the context where
>you saw the term used?
>
>With enough hardware pipelining, you can do DES in 8 clock cycles or
>even 1 cycle. Maybe that's what was meant. An 8-cycle implementation
>would have two sets of S-boxes etc. and implement two rounds as a
>single combinatorial function. Then a sequencer would operate the
>function 8 times to compute standard 16-round DES.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 24 Jun 1999 09:10:45 -0400
In article <7kskco$tou$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>
>I thought Statistical randomness ment:
>
>> >is ment that the digits are generally well distributed, and that they
>> >occur approximately as often as each other- that 1' occur as
>> >frequently, as 2's which occur as frequently as..., you get the idea.
>
>
>Are you certain that this definition is not correct? Is this not what
>you call statistical trends? i.e.- even distribution.
It's correct as far as it goes, but it's not sufficient.
For example, the sequence
0.1234567891011121314151617181920212223...
has provably uniform distribution... about as many 1's as 2's, &c,...
but is also very easily predictable, in the sense that if I am
given the previous digit (or several digits), I can easily guess
what the next one is.
Statistical randomness for the purposes of the OTP requires not only
uniform distribution, but also independence -- each digit is
independent of every other and knowing a particular number doesn't
help you guess its neighbors. Pi doesn't have this independence.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 Susectability
Date: Thu, 24 Jun 1999 13:14:23 GMT
Omigosh what am I saying? Were both wrong, technically the key is the
output of the cipher...i.e the key stream. The input is the private
key to the RNG, the state merely constitues the private sbox...
Sorry about that (bad water or something :) ). I will try to post when
I am sure about what I am saying...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 24 Jun 1999 09:07:00 -0400
In article <7ksjkc$tj5$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>Predictability-
>
>A true random bit generator (RBG) can produce 400 zeros, but this is
>undesireable.
Incorrect. In fact, *failure* to produce long sequences of zeros at
the correct (low) frequency is undesirable.
> Therefore, a true RBG is not desired.
Incorrect (conclusion from incorrect premises).
>Predictability can be hampered by limitations, but it turns out that
>predictability is not an issue.
Incorrect, again.
>The issue is minimizing patters while
>maximizing message candidates that the opponent must choose from.
No, the issue is making sure that the probability of a particular
plaintext being correct *conditioned on a particular bit of cyphertext
being received* is exactly the same as the probability of a particular
plaintext being correct. No information is gained.
There's an easy reductio-ad-absurdam. Suppose that I decide that 8-bit
patterns of all ones and all zeros are two long (you suggest 400 above,
and I'm being ``even more conservative.''). This means that all
possibilities are permitted *except* that a given byte will never encrypt
to itself, or to its exact inverse.
Now, I want you to OTP encrypt your wedding invitation -- e.g., take
the same message, and send it (using, of course, different pads) to
five hundred or so guests.
I can recover your message in seconds by intercepting these messages
and observing that the first character is one of the two characters
that did not appear as the first character in *any* received message.
Continuing this observation for the second, third, and so forth,
gives me your complete message, almost without effort.
Please note the following :
First, it isn't a violation of the OTP conditions to send identical
messages, and in fact, it's sometimes necessary in the event of
transmission errors or garbles. Any cryptosystem that will not
support sending the same message multiple times is of necessity at
least partially insecure, unlike the theoretical OTP.
Second, the only reason that this is breakable is because of our
joint insistence that 8-bit patterns be removed from the keystream.
If you hadn't prefiltered the key, I couldn't have done a thing.
Third, if 8-bit patterns are necessary for strength, why are
100-byte patterns any different. In point of fact, with your proposed
stripping of 400-bit patterns, ``all'' I would need is 2^400 copies of
the same message encrypted with different keys. Although this is
probably an implausibly large number of texts, it shows the difference
between the unbreakable OTP and the breakable filtered pad.
-kitten
And
>every message candidate must be given the illusion of having the same
>probability of being correct as the correct message has.
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: card shuffling related to rc4?
Date: Thu, 24 Jun 1999 12:31:32 GMT
> The RC4 expansion is similar to the shuffling of a deck of cards
(128).
> So if RC4 has a skew toward some shufflings more than others, then
you can
> might know in what order to perform a brute-force attack on rc4.
Which
> makes it weaker, yes?
No. The RC4 key schedule uses an 8-bit feedback with 2^8 steps so that
each card is shuffled with a random card. The code resembles
x = y = 0
for i = 0 to 255 do
y = (y + state[x] + key[x]) mod 256
x = (x + 1) mod key_length
Swap(state[i], state[y])
next i
There are 256 cards, and 256 shuffles (256 / 256 = 1) and there are 256
possible values for y (again 256/256 = 1). So the algorithm in that
respect is well balanced. The algorithm will work for other word sizes
as well as long as the counts/mods change. For example you could have
64 cards, or 4096 cards...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "RandAlthor" <[EMAIL PROTECTED]>
Subject: Re: OTP is it really ugly to use or not?
Date: Thu, 24 Jun 1999 23:07:19 -0700
It was just his last sentence that I disagree with.
The processing is very significant. You are trying to decrypt, but now have
to do a decrypt of the Non OTP and then the OTP to get any verification that
you are on the right track. Since you can't crack the OTP, it makes the OTP
ambigous enough to be virtually unusable to anyone without the authority.
What do you think?
<[EMAIL PROTECTED]> wrote in message
news:7kmor3$r4l$[EMAIL PROTECTED]...
> RandAlthor wrote:
>
> > FO wrote in message
>
> > > About right software, having all that key material laying around -
> > > perhaps it would be proper to protect the one time pad by encrypting
> > > it in some way. But then it would be no safer than the encrypting =
> > method.
> >
> > No, because the plaintext (the OTP) would be random, and so one could
> =
> > not ascertain if the correct OTP had been decrypted correctly- at
> least =
> > not until it was used to decrypt the original information (Potp). This
> =
> > means that to decrypt anything useful, the processing requirement will
> =
> > be additional to that under a standard OTP scheme, making this a good
> =
> > method.
>
> FO is right. The processing requirment is negligible.
> The provable security of the OTP is lost if the
> adversary obtains the pad encrypted with some
> non-perfectly secure cipher.
>
> --Bryan
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A different method of encryption
Date: Thu, 24 Jun 1999 12:52:41 GMT
In article <7kre6j$lur$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> except this post seems to have all the markings of a troll (with the
> exception of originating from AOL ... AOLers might actually produce
this
> sort of thing ... of course, I never put too much trust in anything
that
> ain't signed ... or anyone who doesn't sign ... no offence)
Wrong newsgroup for this type of post.
(BTW how do I trust that noahp? actually wrote the message and not
someone with access to your PGP keys? Or fake PGP keys?)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "RandAlthor" <[EMAIL PROTECTED]>
Subject: Re: OTP is it really ugly to use or not?
Date: Thu, 24 Jun 1999 23:07:19 -0700
It was just his last sentence that I disagree with.
The processing is very significant. You are trying to decrypt, but now have
to do a decrypt of the Non OTP and then the OTP to get any verification that
you are on the right track. Since you can't crack the OTP, it makes the OTP
ambigous enough to be virtually unusable to anyone without the authority.
What do you think?
<[EMAIL PROTECTED]> wrote in message
news:7kmor3$r4l$[EMAIL PROTECTED]...
> RandAlthor wrote:
>
> > FO wrote in message
>
> > > About right software, having all that key material laying around -
> > > perhaps it would be proper to protect the one time pad by encrypting
> > > it in some way. But then it would be no safer than the encrypting =
> > method.
> >
> > No, because the plaintext (the OTP) would be random, and so one could
> =
> > not ascertain if the correct OTP had been decrypted correctly- at
> least =
> > not until it was used to decrypt the original information (Potp). This
> =
> > means that to decrypt anything useful, the processing requirement will
> =
> > be additional to that under a standard OTP scheme, making this a good
> =
> > method.
>
> FO is right. The processing requirment is negligible.
> The provable security of the OTP is lost if the
> adversary obtains the pad encrypted with some
> non-perfectly secure cipher.
>
> --Bryan
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Kryptos article
Date: Thu, 24 Jun 1999 07:20:10 -0700
Michael wrote:
> Douglas A. Gwyn wrote:
> [snip]
> > Since I posted an accurate transcript of the Kryptos ciphertext
> > several years ago, there has been plenty of time to work on it.
> > (ACA's The Cryptogram published a slightly incomplete and slightly
> > inaccurate version in the MA92 issue, ...
> [snip]
>
> Which is the problem I encountered. Before starting any work on the
> "Famous 97 Characters" I tried to verify that I had the correct,
> complete, cipher text. I might ..... don't really know for sure. Of
> the 4 copies the cipher text I was able to dig up, 3 have different
> lengths. Is the accurate transcript you spoke of here currently posted
> somewhere on the Web?
It is now -- see below. This is the version I used to crack the first
N-97 letters. There are two typos in the substitution section, but they
are cut into the KRYPTOS sculpture itself, and may be meaningful: the
erroneous ciphertext letters are K and R (the first letters of KRYPTOS),
and the erroneous plaintext letters are Q and U (replacing L and O).
Whenever I see QU in the same breath I get suspicious. There's also
a misspelling in the transposition section: an A that should be an E,
and an omitted E in the same word. That could extend QU into QUA if
it's meaningful.
In addition, I've just been told that some of the letters on the sculpture
are in italics. I hope to learn soon which ones they are.
Finally, I note that the Today Show didn't run the KRYPTOS segment
today after all. I imagine David Stein and his family had to watch
the ABC Evening News for nearly a year before his interview was aired,
so I guess I'll put my VCR on automatic and wait for reports.
======================Forwarded message ========================
From: [EMAIL PROTECTED] (Doug Gwyn)
Subject: corrected Kryptos transcription
Keywords: CIA Kryptos sculpture cipher transcription update
Date: 1 Sep 92 17:28:04 GMT
Organization: U.S. Army Ballistic Research Lab (BRL), APG, MD.
EMUFPHZLRFAXYUSDJKZLDKRNSHGNFIVJ ABCDEFGHIJKLMNOPQRSTUVWXYZABCD
YQTQUXQBQVYUVLLTREVJYQTMKYRDMFD AKRYPTOSABCDEFGHIJLMNQUVWXZKRYP
VFPJUDEEHZWETZYVGWHKKQETGFQJNCE BRYPTOSABCDEFGHIJLMNQUVWXZKRYPT
GGWHKK?DQMCPFQZDQMMIAGPFXHQRLG CYPTOSABCDEFGHIJLMNQUVWXZKRYPTO
TIMVMZJANQLVKQEDAGDVFRPJUNGEUNA DPTOSABCDEFGHIJLMNQUVWXZKRYPTOS
QZGZLECGYUXUEENJTBJLBQCRTBJDFHRR ETOSABCDEFGHIJLMNQUVWXZKRYPTOSA
YIZETKZEMVDUFKSJHKFWHKUWQLSZFTI FOSABCDEFGHIJLMNQUVWXZKRYPTOSAB
HHDDDUVH?DWKBFUFPWNTDFIYCUQZERE GSABCDEFGHIJLMNQUVWXZKRYPTOSABC
EVLDKFEZMOQQJLTTUGSYQPFEUNLAVIDX HABCDEFGHIJLMNQUVWXZKRYPTOSABCD
FLGGTEZ?FKZBSFDQVGOGIPUFXHHDRKF IBCDEFGHIJLMNQUVWXZKRYPTOSABCDE
FHQNTGPUAECNUVPDJMQCLQUMUNEDFQ JCDEFGHIJLMNQUVWXZKRYPTOSABCDEF
ELZZVRRGKFFVOEEXBDMVPNFQXEZLGRE KDEFGHIJLMNQUVWXZKRYPTOSABCDEFG
DNQFMPNZGLFLPMRJQYALMGNUVPDXVKP LEFGHIJLMNQUVWXZKRYPTOSABCDEFGH
DQUMEBEDMHDAFMJGZNUPLGEWJLLAETG MFGHIJLMNQUVWXZKRYPTOSABCDEFGHI
ENDYAHROHNLSRHEOCPTEOIBIDYSHNAIA NGHIJLMNQUVWXZKRYPTOSABCDEFGHIJ
CHTNREYULDSLLSLLNOHSNOSMRWXMNE OHIJLMNQUVWXZKRYPTOSABCDEFGHIJL
TPRNGATIHNRARPESLNNELEBLPIIACAE PIJLMNQUVWXZKRYPTOSABCDEFGHIJLM
WMTWNDITEENRAHCTENEUDRETNHAEOE QJLMNQUVWXZKRYPTOSABCDEFGHIJLMN
TFOLSEDTIWENHAEIOYTEYQHEENCTAYCR RLMNQUVWXZKRYPTOSABCDEFGHIJLMNQ
EIFTBRSPAMHHEWENATAMATEGYEERLB SMNQUVWXZKRYPTOSABCDEFGHIJLMNQU
TEEFOASFIOTUETUAEOTOARMAEERTNRTI TNQUVWXZKRYPTOSABCDEFGHIJLMNQUV
BSEDDNIAAHTTMSTEWPIEROAGRIEWFEB UQUVWXZKRYPTOSABCDEFGHIJLMNQUVW
AECTDDHILCEIHSITEGOEAOSDDRYDLORIT VUVWXZKRYPTOSABCDEFGHIJLMNQUVWX
RKLMLEHAGTDHARDPNEOHMGFMFEUHE WVWXZKRYPTOSABCDEFGHIJLMNQUVWXZ
ECDMRIPFEIMEHNLSSTTRTVDOHW?OBKR XWXZKRYPTOSABCDEFGHIJLMNQUVWXZK
UOXOGHULBSOLIFBBWFLRVQQPRNGKSSO YXZKRYPTOSABCDEFGHIJLMNQUVWXZKR
TWTQSJQSSEKZZWATJKLUDIAWINFBNYP ZZKRYPTOSABCDEFGHIJLMNQUVWXZKRY
VTTMZFPKWGDKZXTJCDIGKUHUAUEKCAR ABCDEFGHIJKLMNOPQRSTUVWXYZABCD
? are actual question-mark characters
transcribed from photos by PHOENIX, published in The Cryptogram MA92
retyped into this machine-readable file by Doug Gwyn
slight edits made by Gwyn based on CNN video supplied by Harry Carter
resulting draft visually checked on site and corrected by Gwyn
Gwyn's estimate of probability of any residual transcription error: 0.6
===============End forwarded message=================================
--
Jim Gillogly
1 Afterlithe S.R. 1999, 14:13
12.19.6.5.9, 13 Muluc 17 Zotz, First Lord of Night
------------------------------
Date: Thu, 24 Jun 1999 06:47:18 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: one time pad
Terry Ritter wrote:
>
> We cannot generate randomness with rules. We cannot improve
> randomness with rules. We may be able to collect randomness, but that
> is about it.
>
[ pursuing, not countering, Terry's point ... ]
And, leave us not forget, we must now distribute the randomness equally
and simultaneously to anyone and everyone who might wish to use our
cipher. Every user of our cipher must use exactly the right portion of
the pad and, having used it, destroy it so that it can be used only
once. Every user of our cipher must use it precisely-correctly, every
time, or the messages sent and received will be as incomprehensible to
the cipher's authorized users as it would be to any opponent.
The one-time pads must be sent using a secure link... it wouldn't do to
encrypt them and send them, now would it? A chain is only as strong as
its weakest link. If sent on CD-ROM, those CD-ROMs must be and must
remain perfect; if even one is stolen, all is lost.
As appealing as one-time pads may sound to the theoretician, for the
needs of practical communication (in which millions of bytes of data
might be sent every day, and you never have a secure link to the person
you want totalk to...) they are rarely adequate.
Really... we could yammer on about OTP's for months and in fact we have.
But they are a theoretical target. Designers seek to produce ciphers
with comparable security while simultaneously acknowledging the logistic
requirements of how ciphers are actually, practically used in the field.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 1024-bit block cipher
Date: Thu, 24 Jun 1999 14:22:58 GMT
Hello Tom,
thank you for your reply.
You are correct.
It was so planed and designed.
One can take a look at the algorithm description
online at
<www.online.de/home/aernst>
The link is 'Description to view'.
Or download it from the download list: the link
is 'Description of the algorithm.Word.ZIP.115Kb'
Regards
Alex
In article <7kt8ko$4h2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> <snip>
>
> Some problems.
>
> 1. The block size cannot change. This would for example be a bad
> thing for network trafic (imagine the 2x slowdown!).
>
> 2. 1024-bit blocks are only good for static objects (or small
> objects). Consider a 'difficult' problem like RSA, ElGamma, etc...
>
> 3. You have no link in your email, but if you don't have a text
> describing the algorithm your source code better be really really
> clean !
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 24 Jun 1999 10:16:19 -0400
In article <[EMAIL PROTECTED]>,
Christopher <[EMAIL PROTECTED]> wrote:
>In article <7kt9pt$iac$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Patrick Juola) wrote:
>
>_ In article <[EMAIL PROTECTED]>,
>_ Christopher <[EMAIL PROTECTED]> wrote:
>_ >In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter)
>wrote:
>_ >
>_ >_ But if we leak *any* information, then, clearly, our
>_ >_ "guarantee" is something less than one might expect.
>_ >
>_ >Which would happen if it is known that there are definitely no sequences
>_ >of 100 bytes (or more) in the pad, as an example.
>_
>_ Let's see -- out of the 8^100 possible sequences for any 100-byte
>_ block, 8 are disallowed.
>_
>_ This in turn, disallows 8 of the possible decryptions. If one of
>_ those 8 is a particularly crucial possibility, then the cryptanalyst
>_ has gotten some significant information.
>
>Okay, maybe I'm being thick here, but where did the 8 come from, I would
>have thought it more than that.
Sorry, no -- I'm being thick. Replace 8 with 256 (2^8) throughout
in the previous paragraph.
>
>Anyway, it was just an example, and the one used earlier in the thread.
>My point was that the sequence is no longer 'random' with any restrictions
>placed on it.
Yes. And if you put restrictions on the pad, then you can make inferences
about the underlying plaintext that you couldn't with an unbiased
pad.
-kitten
------------------------------
From: Michael <[EMAIL PROTECTED]>
Subject: Re: Kryptos article
Date: Thu, 24 Jun 1999 09:41:05 -0400
Douglas A. Gwyn wrote:
[snip]
> Since I posted an accurate transcript of the Kryptos ciphertext
> several years ago, there has been plenty of time to work on it.
> (ACA's The Cryptogram published a slightly incomplete and slightly
> inaccurate version in the MA92 issue, ...
[snip]
Which is the problem I encountered. Before starting any work on the
"Famous 97 Characters" I tried to verify that I had the correct,
complete, cipher text. I might ..... don't really know for sure. Of
the 4 copies the cipher text I was able to dig up, 3 have different
lengths. Is the accurate transcript you spoke of here currently posted
somewhere on the Web?
--
Michael
---
NOTE: Reply_To has been forged to foil SPAM.
Please reply via this NewsGroup.
------------------------------
From: [EMAIL PROTECTED] (Christopher)
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 09:53:00 -0400
In article <7kt9pt$iac$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Patrick Juola) wrote:
_ In article <[EMAIL PROTECTED]>,
_ Christopher <[EMAIL PROTECTED]> wrote:
_ >In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter)
wrote:
_ >
_ >_ But if we leak *any* information, then, clearly, our
_ >_ "guarantee" is something less than one might expect.
_ >
_ >Which would happen if it is known that there are definitely no sequences
_ >of 100 bytes (or more) in the pad, as an example.
_
_ Let's see -- out of the 8^100 possible sequences for any 100-byte
_ block, 8 are disallowed.
_
_ This in turn, disallows 8 of the possible decryptions. If one of
_ those 8 is a particularly crucial possibility, then the cryptanalyst
_ has gotten some significant information.
_
_ -kitten
Okay, maybe I'm being thick here, but where did the 8 come from, I would
have thought it more than that.
Anyway, it was just an example, and the one used earlier in the thread.
My point was that the sequence is no longer 'random' with any restrictions
placed on it.
------------------------------
Date: Wed, 23 Jun 1999 23:06:05 -0400
From: [EMAIL PROTECTED]
Subject: Re: one time pad
[EMAIL PROTECTED] wrote:
>
> I would like to put forth the following claims
> and if anyone would care to comment, disprove,
> ect., I would appreciate it. I thought I new
> some things (being new to cryptography), but a
> patient individual helped me see I have more to
> learn. He suggested I come to Deja, so here I am.
>
> 1. One time pads, when implemented, deployed, and
> used correctly are the only known cipher that
> guarantees the security of the plain text over a
> non secured media. (Physical security is assumed
> for this discussion.)
>
> 2. Maintaining statistical randomness produces a
> weakness in the pad since the probability of some
> values already seen in the bit stream are less
> likely to be found again.
>
> 3. As long as a minimal amount of randomness is
> guaranteed, the pad's security is its strongest.
> To require strong randomness is to limit the
> opportunities of what can be found on the pad and
> thus limit the candidates of possible plain text
> hidden by the OTP's output.
Your claims 2 and 3 are based on a peculiar interpretation of the
concept "random". This topic appears regularly in this news group, so
join the club.
I suspect that you will find the opinions of the other contributors to
this news group strongly against your claims 2 and 3 because there is no
definition of random that leads to your claims. In fact both the
classical statistical definition, Shannon's definition of entropy, and
the cryptologic definition lead to the exact opposite of your claims.
------------------------------
** 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
******************************
