Cryptography-Digest Digest #774, Volume #9 Fri, 25 Jun 99 14:13:03 EDT
Contents:
Re: Online material? (JPeschel)
Re: Bytes of "truly random" data for PRNG seed. (fungus)
HELP: FIPS 140-1 for Browser Engine ([EMAIL PROTECTED])
DES-NULL attack ([EMAIL PROTECTED])
Re: CBC mode (?) ([EMAIL PROTECTED])
Re: "Breaking" a cipher ([EMAIL PROTECTED])
Re: Bytes of "truly random" data for PRNG seed. ([EMAIL PROTECTED])
Re: DES-NULL attack ([EMAIL PROTECTED])
Categorize a RNG ([EMAIL PROTECTED])
Re: Bytes of "truly random" data for PRNG seed. ("Douglas A. Gwyn")
Re: one time pad (Patrick Juola)
Re: "Breaking" a cipher (JPeschel)
Re: one time pad (John Savard)
Re: Dundee Society (John Savard)
Re: VIC cipher now described on web site (John Savard)
Re: one time pad (John Savard)
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day (John Savard)
Re: one time pad (Jim Felling)
Re: CBC mode (?) (Eric Young)
Re: one time pad (John Briggs)
Re: one time pad ("Douglas A. Gwyn")
Tough crypt question: how to break AT&T's monopoly??? (Jayjames99)
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Medical
Electronics Lab)
Re: one time pad (Greg Ofiesh)
Re: Kryptos article (Jim Gillogly)
Re: one time pad (Terry Ritter)
Re: RC4 Susectability ([EMAIL PROTECTED])
Re: one time pad (Mickey McInnis)
LOKI 89,91; Safer K-64, K-128 (JPeschel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Online material?
Date: 25 Jun 1999 12:03:22 GMT
>[EMAIL PROTECTED] writes:
>Does anyone know of any online materials available for a newbie
>interested in cryptanalysis? I'm talking about real basic stuff that'd
>cover the math/number theory involved...
Menezes' chapter 2 from his book is on his web site. Might
be helpful.
http://www.cacr.math.uwaterloo.ca/hac/
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Bytes of "truly random" data for PRNG seed.
Date: Fri, 25 Jun 1999 15:17:55 +0200
Benjamin Goldberg wrote:
>
> The seed generator used in java.security.SecureRandom says that it
> "has not been thoroughly studied or widely deployed." Does anyone know
> how I could go about verifying that the bytes provided by that method are
> "truly random," in the sense that they are usable for cryptographic
> purposes?
>
That's the fun part - you can *never* prove a number is random
just by looking at it. "When is a number not random" has been
a thread in this newsgroup since it was started.
The Blum Blum Shub I mentioned earlier is supposed to be "provably
good" but I have to confess I don't know much about the algorithm
or how the proof works.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: HELP: FIPS 140-1 for Browser Engine
Date: Fri, 25 Jun 1999 13:48:50 GMT
Can anyone give me the FIPS 140-1 compliance status for the encryption
engines of Microsoft IE and Netscape Navigator.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: DES-NULL attack
Date: Fri, 25 Jun 1999 14:04:43 GMT
Suppose we use DES encryption algorithm.
Let a plain text block contains only bits with NULL value.
Then correspondent cipher block is well-defined function
of the encryption key, which can be recovered.
For more details please follow the link 'DES-NULL attack'
at
<www.online.de/home/aernst>
Regards
Alex
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CBC mode (?)
Date: Fri, 25 Jun 1999 13:50:08 GMT
In article <7ku1qe$1pp$[EMAIL PROTECTED]>,
"Serge" <[EMAIL PROTECTED]> wrote:
> I did find a test array for Blowfish in CBC mode. Length of array 29
bytes.
> Is there a standart method to fill last block up to 8 bytes? I did
try to
> fill last 3 bytes with zero, but it was wrong.
Normally you pad with zeroes except the last bit is a one. This is
like hash functions I believe.
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: [EMAIL PROTECTED]
Subject: Re: "Breaking" a cipher
Date: Fri, 25 Jun 1999 13:53:03 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> As it happens, I also encrypted those messages with DES. I arranged
for
> some time for Tommy to use EFF's DES cracker. He declined, knowing
that
> a brute-force break was not really a break.
Well that's a weakness not a break. A break would be getting Matsui's
program and computers and having 2^43 pairs and solving it faster then
O(2^55).
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: [EMAIL PROTECTED]
Subject: Re: Bytes of "truly random" data for PRNG seed.
Date: Fri, 25 Jun 1999 14:04:35 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> It's just iterated squaring (starting with a random seed) modulo a
> product of two large primes (each of which is congruent to 3 mod 4).
> The claim that BBS is "cryptographically strong" is based on the
> difficulty of factoring, which of course is a field that has seen
> rapid progress..
>
A quick question, the composite number 'pq' in BBS is the Blum Integer?
Does anyone have a link to the BBS paper online?
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: [EMAIL PROTECTED]
Subject: Re: DES-NULL attack
Date: Fri, 25 Jun 1999 14:23:27 GMT
In article <7l029h$4q6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Suppose we use DES encryption algorithm.
>
> Let a plain text block contains only bits with NULL value.
>
> Then correspondent cipher block is well-defined function
> of the encryption key, which can be recovered.
That is not true. It's a function of the plaintext register, key and
sboxes. You forget that the key and sboxes will not always produce
degenerative output and their is a feedback (the other unmodified half
in each round).
For NULL it's just as hard as for '12345678'. By your argument though
the all one plaintext would reveal the complement of the key.
That's not true. If it were this would apply to many other ciphers
(Blowfish, CAST, Kafre, etc...)
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: [EMAIL PROTECTED]
Subject: Categorize a RNG
Date: Fri, 25 Jun 1999 14:27:18 GMT
I was thinking of how to categorize the strength of a RNG. I think
this ratio will work for most cases
o:r:i
o = # of bits out (single output)
r = # of bits revealed (per output)
i = # of bits in (state)
Because linear complexity plugs into r, the key plugs into i, and the
output into 'o'. The only thing that is not represented is the
statistical testing (i.e frequency of the output bytes). a LFSR for
example could be qualified as
1:1:n
Where there is one output bit, which reveals one bit of the state, and
the state has n bits. Two LFSR's put together would be
1:0.5:2n
etc...
RC4 would be
8:r:1684
(I don't know r yet).
just a thought,
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: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Bytes of "truly random" data for PRNG seed.
Date: Fri, 25 Jun 1999 12:49:24 GMT
fungus wrote:
> The Blum Blum Shub I mentioned earlier is supposed to be "provably
> good" but I have to confess I don't know much about the algorithm
> or how the proof works.
It's just iterated squaring (starting with a random seed) modulo a
product of two large primes (each of which is congruent to 3 mod 4).
The claim that BBS is "cryptographically strong" is based on the
difficulty of factoring, which of course is a field that has seen
rapid progress..
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 24 Jun 1999 15:19:10 -0400
In article <7kttu6$dpu$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>
>> What does this mean? If by ``maintaining statistical randomness''
>> you mean ``drawing without replacement from a uniform pool,''
>> then I'd just like to point out that drawing without replacement
>> isn't a good model for the phenomena under discussion.
>
>Yes, this is all it can mean.
Then you're using the wrong model. Try drawing with replacement
instead.
-kiten
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: "Breaking" a cipher
Date: 25 Jun 1999 15:42:04 GMT
> [EMAIL PROTECTED], still grasping at broken straws writes:
>Well that's a weakness not a break. A break would be getting Matsui's
>program and computers and having 2^43 pairs and solving it faster then
>O(2^55).
I agree with you that Matsui's attack on DES is a break. Still I must
contend that when we know we can exhaustively search the entire keyspace
of cipher, in this instance, DES, in less than a couple days this a break.
Knudsen seems to agree when he writes: "More recently the Electronic
Frontier Foundation (EFF) built a machine to exhaustively break the DES."
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 15:38:32 GMT
"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
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dundee Society
Date: Fri, 25 Jun 1999 15:34:47 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
>Having
>pretty much finished the Zendian Problem, I figured if I were going to be
>a serious amateur cryppie, I'd need a Dundee crock... my "outfit", as it
>were. E-Bay obliged with an antique one.
Except to do some preliminary sorting out of the information that
seems to identify messages, and to find some that were similar, I
haven't started. But I did find, in a local thrift shop one day (hey,
more recently I found a pair of Maggies there) a jar of the kind that
was of opaque light brown glass or ceramic - although it does vary
from "authenticity" in one way, being bilingual.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: VIC cipher now described on web site
Date: Fri, 25 Jun 1999 15:36:34 GMT
[EMAIL PROTECTED] (UBCHI2) wrote, in part:
>That cipher must have been a Soviet red herring. There is no way to implement
>a hand cipher of that complexity.
I'll admit that carrying out chain addition for such a length of time
seems to be impossibly prone to error.
However, when you have the ability to send people to Siberia, it's
surprising what skills you can get them to learn.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 15:46:20 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>The issue here is whether even minor forms of predictability are
>mathematically prohibited, or even wildly impossible given what we
>know about the real system. I think not: these are reasonable
>concerns. There is no process in place, no tool we have, no test we
>can make which can eliminate the possibility of weakness in a pad.
>And the possibility of weakness destroys any claim to absolute
>strength.
I see that I have misunderstood your argument. I thought you were
claiming that a physical random-number generator might accidentally
produce a keystream matching one that could be generated by a
cryptanalyzable PRNG, and I pointed out that that risk doesn't
actually reduce ambiguity.
Instead, you are suggesting that a physical RNG - say, for example, a
rotating cage with numbered balls in it - might still be predictable
by means of some advanced mathematics.
Well, it is true that the OTP model makes simplifying assumptions
about the real world. The "proof" that the OTP is secure depends on
the truth of those assumptions. The specific example of a "true" RNG I
gave _might_ be subject to such an attack, but I think no one would
really be worried about that particular risk. Independent dice throws,
though, or the output of an RNG making use of a quantum-mechanical
process, can be considered quite safe.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
Date: Fri, 25 Jun 1999 15:48:27 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>I'm glad you are feeling so pleased with yourself, John, but that was
>*not* my argument.
Ah, well, I made a fruitful error. But I do owe you an apology. I'll
have to admit, though, when I saw what your argument _was_, I thought
it a rather wild one (and a nitpick too), but I suppose it *is*
important to address any illusions about "proof".
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 10:48:05 -0500
"Douglas A. Gwyn" wrote:
> Jim Felling wrote:
> > So long as you "build this pad" with random (UBP type) noise it will
> > have a lack of long term patterns.
>
> Patterns of the type he was concerned about (e.g. 100 consecutive
> 0 bytes) *will* occur in a sufficiently long run, with probability 1.
Well, yes, but.. a long run like that assuming you generate random values
at 2^22 byte/second it is expected that that will occur at a time on the
order of 2^74 seconds from now.(Not something that I'd worry about.)
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: CBC mode (?)
Date: Sat, 26 Jun 1999 02:08:43 +1000
[EMAIL PROTECTED] wrote:
> In article <7ku1qe$1pp$[EMAIL PROTECTED]>,
> "Serge" <[EMAIL PROTECTED]> wrote:
> > I did find a test array for Blowfish in CBC mode. Length of array 29
> bytes.
> > Is there a standart method to fill last block up to 8 bytes? I did
> try to
> > fill last 3 bytes with zero, but it was wrong.
The other popular system is to pad with the value of the number of
bytes to ignore. ie, for 3 bytes of padding, 0x03,0x03,0x03 would
be appended.
There are three systems that I have come across.
1) Last byte is number of padding bytes, random values for pad bytes
2) Fill all padding bytes with the number of padding bytes
3) Last byte is number of padding bytes, fill the padding bytes with
that number.
eg for 3 bytes + padding
1) MM MM MM ra nd om ra 05
2) MM MM MM 05 05 05 05 05
3) MM MM MM 04 04 04 04 04
The difference between 1 and 2 is that for 2, the encryption
will always produce the same result. The different between 2
and 3 is that there is a 'padding length' field added, so we
actually pad one byte less.
Sun's old DES command (as implemented in libdes) used system 1.
Most RFC's etc on ciphers use system 2. SSLv3/TLSv1 uses system 3.
eric
------------------------------
From: [EMAIL PROTECTED] (John Briggs)
Subject: Re: one time pad
Date: 25 Jun 99 12:00:58 -0400
In article <[EMAIL PROTECTED]>, Jim Felling
<[EMAIL PROTECTED]> writes:
>
>
> "Douglas A. Gwyn" wrote:
>
>> Jim Felling wrote:
>> > So long as you "build this pad" with random (UBP type) noise it will
>> > have a lack of long term patterns.
>>
>> Patterns of the type he was concerned about (e.g. 100 consecutive
>> 0 bytes) *will* occur in a sufficiently long run, with probability 1.
>
> Well, yes, but.. a long run like that assuming you generate random values
> at 2^22 byte/second it is expected that that will occur at a time on the
> order of 2^74 seconds from now.(Not something that I'd worry about.)
I think you dropped a factor of 8 there. Make it 2^774 seconds and you're
in the ballpark.
John Briggs [EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 05:12:07 GMT
Jim Felling wrote:
> So long as you "build this pad" with random (UBP type) noise it will
> have a lack of long term patterns.
Patterns of the type he was concerned about (e.g. 100 consecutive
0 bytes) *will* occur in a sufficiently long run, with probability 1.
------------------------------
From: [EMAIL PROTECTED] (Jayjames99)
Subject: Tough crypt question: how to break AT&T's monopoly???
Date: 25 Jun 1999 16:56:16 GMT
I think this is a tough question to answer.
I am trying to send an encypted file to somebody who is not computer savvy, in
a format so that the receiving party does not have to know how to decrypt the
file. It will simply self-extract, ask for the private key to be entered, and
voila...the file is now readalble.
I think AT&T is the only vendor of this kind of a program--but it costs $1000+
for a network license. Outrageouis. And probably patented.
Does anybody know of a cheap workaround?
Also, in the alternative, please recommend any NON-PGP program (except ROT13)
for half-way decent protection from casual intruders, so that somebody can
simply send an encryped file that can be easily decrpyted (especially a binary
file sent as an attachment)
Thank you! feel free to reply by e-mail as well: [EMAIL PROTECTED]
JJ
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: Fri, 25 Jun 1999 11:57:43 -0500
Robert Harley wrote:
> This is true for most curves, but false for many of the special cases
> that have been proposed. Special cases are dangerous. What's hard to
> understand about that?
Nothing. It's the relative level of danger. For most applications
I've seen, the crypto is about 1e6 over kill compared to the security
of the application itself due to hacking. Using a Koblitz curve
in that situation is fine, it's 1e5 overkill instead! And in
10 years it might only be 1e3 overkill.
It's the difference between "academic" and "practical", which has
been argued here many times. Koblitz curves are practical for
many applications. That's not dangerous, yet.
All elliptic curves could be dangerous. Some genius might come
along and find a polynomial solution to the ECDLP. As an engineer,
it's a chance I'll take that the genius hasn't been born yet.
For me, Koblitz curves are a long way from super-singular curves
which do have a polynomial time solution. How dangerous are
Koblitz curves? For you, too dangerous. For me, not so dangerous
I can't use them for the next 10 years.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 16:27:48 GMT
> The probability of a long stream of zero's is
> so vanishingly small, that
> worrying about it is counter productive.
If it is vanishingly small, then at some point you do not expect to see
it in nature. For example, what are the odds that all photons in the
universe come together and cancel each other out in a moment of time?
So slim that you do not expect to ever see it happen.
Therefore I ask, what do you do if your RNG produces an event that is
too unlikely to occur in nature? Assume the RNG is broken and replace
it? Why not filter the output with: "I want only those events that
meet a threshold of probability. Anything lower than this given
threshold is demonstrative of an inperfect RNG because the event shows
a bias toward a probability that is too slim to occur in nature."
What say you?
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: Fri, 25 Jun 1999 10:09:10 -0700
[EMAIL PROTECTED] wrote:
> Jim is your program available? If not will you
> make it so? Done in perl?
No, sorry. If you'd like to learn how to do this sort of
stuff, I recommend the American Cryptogram Association:
ACA Treasurer
1118 Via Palo Alto
Aptos CA 95003.
I use Perl for one-off programs and things that aren't computationally
intensive -- analyzing and diagnosing unknowns, for example. C is
better for the serious crunching, like if you want to do an N^2 search
on a word list for an autokey primer and alphabet key; or for the kind
of hill-climbing approaches to which I've become addicted for classical
ciphers.
--
Jim Gillogly
2 Afterlithe S.R. 1999, 17:00
12.19.6.5.10, 1 Oc 18 Zotz, Second Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 05:12:32 GMT
On Thu, 24 Jun 1999 23:51:15 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>
>>Alas, we also *cannot* know whether a pad is "good" or not. Any pad
>>we create may have some predictable pattern of which we are unaware.
>>No tests can assure us otherwise. We use any pad at all at risk of
>>failure when our opponents find something we missed.
>
>>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.
>
>I suppose, though, that the odds of generating a bit stream by
>flipping a coin that happens to match, say, the output of a simple
>shift-register or mixed congruential generator - hence leading to my
>message being decrypted by a cryptanalyst who didn't realize I was
>using an OTP...
>
>are much smaller than the odds of the bit stream I generate, plus my
>plaintext, producing a ciphertext that could have been produced by
>some other plaintext plus a poor stream cipher.
>
>In fact, the chance is smaller by exactly 1/N, where N is the number
>of possible plaintexts. That _is_ as perfect as security gets.
>
>*Nothing* can prevent the cryptanalyst from reading your message by
>making a lucky guess, but I can't really call that a weakness in a
>cipher method. (Of course, I could just be misunderstanding your
>point.)
I'm not talking about lucky guesses, unless you call hard work and
eventual success on something that should be impossible, "lucky." My
point is that any pad we generate, by any process, may have some
weakness, some predictability, that we do not recognize but which may
nevertheless exist. It is unnecessary for this predictability to have
the particular structure of a LFSR or LCG, which would be quite
unlikely. Indeed, I would expect real "predictability" to be
short-range and partial at best. But along with other information, it
might be all our opponents need.
The issue here is whether even minor forms of predictability are
mathematically prohibited, or even wildly impossible given what we
know about the real system. I think not: these are reasonable
concerns. There is no process in place, no tool we have, no test we
can make which can eliminate the possibility of weakness in a pad.
And the possibility of weakness destroys any claim to absolute
strength.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 Susectability
Date: Fri, 25 Jun 1999 17:33:02 GMT
[EMAIL PROTECTED] wrote:
> 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...
What a mess. RC4 uses a secret key of from 1 to 256
bytes. It uses an internal state consisting of a
permutation of the integers [0..255] and two more
integers in [0..255]. From the state, it generates a
keystream of arbitrary length.
> Sorry about that (bad water or something :) ). I will try to post
when
> I am sure about what I am saying...
Is that just for this thread, or a new policy in
general?
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: one time pad
Date: 25 Jun 1999 15:58:52 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
|> Greg Ofiesh wrote:
|> > You cannot say this with OTP. OTP, even if rough, as long as it
|> > lacks any obvious conclusions, does not let an attacker have a clue
|> > as to which candidate is correct. In this lies the guarantee (it
|> > would seem to me) that OTP cannot be broken, even in rough
|> > implementation.
|>
|> However, several one-time pad systems have in fact been broken by
|> cryptanalysis. One that has achieved some measure of fame can be
|> found under "VENONA" on the NSA Web site.
If I recall correctly, the "VENOMA" example wasn't a one-time-pad that
was broken. It was a two-time-pad (or a multiple-time-pad). Due to
errors, the same pad was reused. The sender meant to use a
one-time-pad, but they didn't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: LOKI 89,91; Safer K-64, K-128
Date: 25 Jun 1999 17:47:09 GMT
To the "Algorithms and Attacks" page of my web site I have recently
added the above ciphers and attacks.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
** 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
******************************
