Cryptography-Digest Digest #253, Volume #14 Fri, 27 Apr 01 12:13:01 EDT
Contents:
Re: RC4 Source Code ("r.e.s.")
Re: Decrypting msg from a Rotor machine ("Edward A. Feustel")
Re: Can this be done? ([EMAIL PROTECTED])
Re: RC4 Source Code (Mark Wooding)
Re: RC4 Source Code (Mark Wooding)
Re: number theoretic SKEY scheme (Mark Wooding)
request for encryption software suggestions ("Eric Kleinberg")
Re: OTP WAS BROKEN!!! ("Douglas A. Gwyn")
Re: Censorship Threat at Information Hiding Workshop ("Douglas A. Gwyn")
Re: PRNG quality ("Trevor L. Jackson, III")
Re: Reusing A One Time Pad ("Dirk Mahoney")
Re: OTP WAS BROKEN!!! ("Tom St Denis")
Re: number theoretic SKEY scheme ("Tom St Denis")
Re: request for encryption software suggestions ("Tom St Denis")
Re: RC4 Source Code (Bill Unruh)
Re: RC4 Source Code ("Roger Schlafly")
Re: Censorship Threat at Information Hiding Workshop ("Trevor L. Jackson, III")
Re: RC4 Source Code ("Tom St Denis")
Re: Running Time of Factoring Algorithms (Bill Unruh)
----------------------------------------------------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: RC4 Source Code
Date: Fri, 27 Apr 2001 06:38:10 -0700
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote ...
| r.e.s. <[EMAIL PROTECTED]> wrote ...
| > "Bill Unruh" <[EMAIL PROTECTED]> wrote ...
| > [...]
| > | One can point to the ARC4 source code and state that tests have shown
| > | that on a selected set of inputs, the output of ARC4 is identical to
| > | RC4. One cannot say that it is identical since noone knows.
| >
| > Whoever reverse engineered RC4 to obtain ARC4
| > probably does know that they are identical, imo.
|
| I also suspect that the people at RSA Data Security have, at some time in
| the past, have actually compared the published ARC4 source code with their
| internal source code, and so they also know whether they are identical.
I was suggesting that the identity is supported by more than just the
happy comparison of outputs. Presumably someone reverse engineered a
compiled version of RC4 (say by disassembling it to assembly language)
so there need not have been a great deal of guesswork involved. Still,
we can't be absolutely certain of absolute fidelity.
--r.e.s.
------------------------------
From: "Edward A. Feustel" <[EMAIL PROTECTED]>
Subject: Re: Decrypting msg from a Rotor machine
Date: Fri, 27 Apr 2001 09:23:15 -0400
Take a look at:
CRYPTANALYSIS OF THE HAGELIN CRYPTOGRAPH, Wayne G. Barker =
This book progressively takes the student through the entire
subject of the cryptanalysis of the Hagelin Cryptograph, also known as
M-209
in the U.S. Army during World War II. The text begins with the
analysis of a one-wheel machine, then a two-wheel machine, until finally
the
analysis of the actual six-wheel machine is reached. Problems to be
solved are included.
C-17 =B7 8-1/2" x 11", 223pp, Paperback, ISBN: 0-89412-022-0 =B7
$32.80
as seen on
http://www.aegeanparkpress.com/browse.html
Ed F.
Daniel wrote:
> =
> Hi.
> =
> I would like to find information on attacks on rotor machines like
> Manex, Printex ,Suprex (Embase) (all Hagelin-like used around 1960).
> =
> How does one go about attacking messages encrypted with these rotor
> machines? Is there any literature on this? All I could find was a
> very brief description on how to operate such a machine, but I would
> like to learn more about it.
> =
> Thanks for your time. Best regards, Daniel.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can this be done?
Date: Fri, 27 Apr 2001 13:59:50 GMT
As most other have stated, this is basically the scenario for a digital
signature, but just to be clear about something - if all Bob has to go on
are the messages from Alice, with absolutely no additional information,
someone could simply intercept the first message, substitute a phony public
key and then intermittently pass through messages from Alice, re-signed with the
phony private key or occasionally send new forged messages and Bob won't be
able to tell the difference.
The end result is, yes, the messages all come from the same source, but it
may not be the source that Bob expects.
Basically, any time Bob must rely solely on information from one source, he
is susceptible to man-in-the-middle attacks. Normally when you use digital
signatures, you have a piece of information ahead of time - the public key
of a trusted certificate authority, which you can use to verify a public key.
Mark
Julian Morrison <[EMAIL PROTECTED]> wrote:
: Here's a scenario:
: Alice sends messages to Bob. The messages are sent in clear, but Alice
: includes a "check hash" with each message that allows Bob to ascertain
: that (1) the message matches its hash, and (2) all the messages were
: generated by someone who knew some unspecified secret, said secret being
: provably the same for all the mesages.
: HOWEVER, Bob does not know this secret, he and Alice do not exchange any
: information (the flow of data is solely from Alice to Bob), nor can he nor
: anyone else listening in determine this secret. And, no-one without the
: secret can forge new hashes that falsely seem to have been created by
: Alice.
: The result being: all the messages are proven to come from the same place,
: despite that place remaining anonymous.
: Can this be done? If so, how?
--
Mark Wutka
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: RC4 Source Code
Date: 27 Apr 2001 14:18:05 GMT
Dirk Mahoney <[EMAIL PROTECTED]> wrote:
> Sorry for wasting your time. After doing some searches and failing, I
> thought the next best plan was to ask in the newsgroup to which the
> original code was leaked.
Searches like `rc4 description', `rc4 cipher algorithm'...? Google gave
me sensible references in the top 5 for almost anything I could think
of about RC4.
> Seems logical to go straight to the source when all else fails. If
> you ask me, it seems logical to go straight to the source to begin
> with to avoid *wasting time*, but I didn't.
Search engines don't have anything else useful to do. Some sci.crypt
readers do.
> All searches I did yielded lots of nothing. RSA's site obviously had
> nothing, couldn't find anything in the sci.crypt FAQ, Counterpane's site
> wasn't helpful, neither was Rivest's (for obvious reasons),
http://theory.lcs.mit.edu/~rivest/crypto-security.html has a link to
an RC4 implementation in Perl. I think that counts as at least partly
helpful.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: RC4 Source Code
Date: 27 Apr 2001 14:21:12 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
> One can point to the ARC4 source code and state that tests have shown
> that on a selected set of inputs, the output of ARC4 is identical to
> RC4. One cannot say that it is identical since noone knows.
Ron Rivest's web pages have a pointer to `RC4 in 3 lines'. If anyone
should be able to recognize RC4, it's he.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: number theoretic SKEY scheme
Date: 27 Apr 2001 14:56:52 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I am thinking of a slightly different scheme. One where you replace
> hash with a square modulo a blum integer. By giving out the square
> root you prove you know some secret info. Use the integer as a BBS
> type thing where you give the N'th output (since you know the factors
> you can seek to there). Then as you login you just give out the N-r
> BBS output.
Interesting idea. It seems closer in spirit to Rabin's public-key
system than the BBS itself.
In your scheme, you must be quite careful not to be a square-root
oracle for anyone evil -- given such an oracle, an adversary can easily
factor your modulus.
For example, you must either construct your square roots offline, by
interacting with some some secure machine, and walk away with a list of
square roots you can use for a while, crossing them off as you use them,
or carry about your square-root device which always works backwards from
its current seed value and can't be made to compute square roots of
arbitrary challenges invented by hostile people.
Paranoid types will like the security guarantees of this system.
However, it does require rather more processing power than a simple hash
function. Finally, the responses you have to give are much longer than
if you just used a hash function: 1024 bits rather than 160.
-- [mdw]
------------------------------
From: "Eric Kleinberg" <[EMAIL PROTECTED]>
Subject: request for encryption software suggestions
Date: Fri, 27 Apr 2001 15:05:06 GMT
I am seeking freeware C source which can encrypt a buffer and whose output
is a buffer of the same size. The encryption does not have to be very
strong.
Any suggestions (URLs) would be appreciated.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Fri, 27 Apr 2001 14:52:54 GMT
Tom St Denis wrote:
> Aren't bent vectors maximally nonlinear and xor-pair minimized?
I don't know how a vector could be linear or nonlinear.
A bent function is a Boolean function whose Fourier transform
components all have the same amplitude. I.e. it is Boolean
white noise. It should be obvious why that is useful.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Fri, 27 Apr 2001 14:55:36 GMT
Darren New wrote:
> > > There is nothing natural about property per se,
> > There most certainly is. Products require producers.
> But the question becomes "who is the producer of the CD I have in my hand?"
> You may have produced the music, but I produced the CD itself.
That's disingenuous. Clearly it is the information content
that you value, not the physical medium.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: PRNG quality
Date: Fri, 27 Apr 2001 15:19:48 GMT
Rob Warnock wrote:
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> +---------------
> | Since PRNGs are deterministic their output contains no more entropy
> | than their input, the initial seed value. In a trivial sense the
> | sequence P xor Q has randomness (entropy) equal to Pseed + Qseed.
> +---------------
>
> By "Pseed + Qseed" did you mean "length(Pseed)+length(Qseed)"? I suspect
> it's probably something more like H(P XOR Q) <= H(Pseed) + H(Qseed), since
> the entropy of the seeds might be *very* small [if badly chosen], and if
> the seeds are duplicates or share content, the inequality will definitely
> apply.
I neglected to mention this consideration, but if the second key is a
duplicate or deterministically derived from the first it does not have any
entropy. So the straight equality is the general case. Otherwise we're
implying that some of the entropy in the keys is disappearing. AFAIK that is
only the case if the PRNGs have in a period shorter than the width of the
respective key (more accurately, if there are fewer PRNG output sequences than
there are initial seed values).
------------------------------
Reply-To: "Dirk Mahoney" <[EMAIL PROTECTED] (remove the _)>
From: "Dirk Mahoney" <[EMAIL PROTECTED] (remove the _)>
Subject: Re: Reusing A One Time Pad
Date: Fri, 27 Apr 2001 15:24:52 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:ePD6covxAHA.328@cpmsnbbsa07...
> The moment you reuse *any* portion of the pad, the security immediately
> falls to precisely 0. That's a simple fact of life (assuming you are using
a
> standard XOR based pad). There is no getting around that, no amount of
> postulating will get around the mathematic problems involved, your idea is
> plain and simply insecure.
> Joe
Sorry Joe, but I had to interject. Can't have everyone stealing the
spotlight! :-) I would politely like to [conditionally] disagree with your
above statement. In theory, you are correct. In practice, you are not, I
think! :-)
If my OTP is...
01000010111010101110100101110100010101101101010101000101001011
and my message is...
10010101101010010010001001110101110101011100010101101011010100
... then I end up with some ciphertext that I couldn't be bothered working
out.
However, I send a new message that has an OTP of...
01001001001101010100010111010
... and the message is...
10100100101111010110100001011
... then I get another ciphertext that I'm too lazy to figure out. Assuming
I only transmit the ciphertexts to someone who already has the OTPs, then my
plaintexts are safe from prying eyes. Easy stuff right?
I think this is what Mark G Wolf is getting at. The point is, I reused some
of my first OTP (lots in fact, quite accidently). The part I reused
deliberately was the first bit (0) of the first OTP. I used it as the last
bit (0) of my second OTP. If you know that I re-used *that* particular bit,
then yes, granted, I have compromised (to some degree) one bit. Is it
useful to you in deciphering my ciphertexts? No, not really. Are my
ciphertexts any less secure? In practical terms, no. This one bit of
re-use does not give you anything substantial to launch an attack on the
remaining bits of the ciphertext.
However, when I re-use two bits, am I getting into trouble? Maybe, but
probably not, assuming that my message is of a significant length. What I
*think* Mark is trying to determine is when this 'overlap' makes things
insecure, from a practical standpoint. We all acknowledge that in
theoretical, absolute terms, I have violated the sacred law of OTPs and I
can no longer claim perfect secrecy.
I agree with you and everyone else when we say that an OTP is to be used
once. No arguments. Understand it completely. But, as everyone agrees,
OTPs are impractical. There is only one reason that we use stream and block
ciphers: key management. An OTP is too big for key exchange protocols and
all the other stuff that we need to do. We like smaller keys, easier to
manage. We make a trade off: I'm prepared to trade some of my *provably
secure-ness* for some *key managability*.
Mark wants to see how practical it would be to make a similar trade-off,
based on the *ideas* behind the OTP, but not using an OTP. He wants to use
a large repository of purely random values (not PRNG stuff and not an OTP)
and see how quickly, in practical terms, the security degrades when re-using
portions of this pool of bits. I can't work out the maths he needs to
figure this out. Intuitively, it seems like it would degrade very quickly
(as someone else suggested earlier in the thread) and he'd be better off
with a stream or block cipher. I wouldn't want to use his scheme.
The breaking of re-used OTPs (which therefore aren't really OTPs anymore) is
based on analysing the index of coincidence. Is one bit of re-use enough to
break the rest of the ciphertexts? Sure security has been comprised a
little, but for all intents and purposes, no. But is two bits? What about
three? Mark wants to establish the point where the re-use of the random
pool drops the security of his scheme below his *acceptable level*. I don't
like his idea simply because, as someone else points out, the key quickly
becomes the instructions for re-use, at which point, it is no longer even
remotely close to the security of a real OTP. But I think I understand his
question.
Mark, am I understanding you correctly?
- Dirk
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Fri, 27 Apr 2001 15:36:15 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > Aren't bent vectors maximally nonlinear and xor-pair minimized?
>
> I don't know how a vector could be linear or nonlinear.
>
> A bent function is a Boolean function whose Fourier transform
> components all have the same amplitude. I.e. it is Boolean
> white noise. It should be obvious why that is useful.
Vectors as in a series of bits. i.e an 8x8 is a 8-component vector
(possibly).
I dunno, I would have to read up my Eurocrypt collection..
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
Comment: Key at: http://tomstdenis.home.dhs.org/key.asc
iQA/AwUBOumRbAULrT+pXe8cEQK7EgCfQhLtUCbQUn1TjYhRW1LLErGRiuwAnREM
i/Gv2dVo0fU+wSUQhSYJ5AUq
=3COm
=====END PGP SIGNATURE=====
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: number theoretic SKEY scheme
Date: Fri, 27 Apr 2001 15:36:22 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > I am thinking of a slightly different scheme. One where you
> > replace hash with a square modulo a blum integer. By giving out
> > the square root you prove you know some secret info. Use the
> > integer as a BBS type thing where you give the N'th output (since
> > you know the factors you can seek to there). Then as you login
> > you just give out the N-r BBS output.
>
> Interesting idea. It seems closer in spirit to Rabin's public-key
> system than the BBS itself.
>
> In your scheme, you must be quite careful not to be a square-root
> oracle for anyone evil -- given such an oracle, an adversary can
> easily factor your modulus.
>
> For example, you must either construct your square roots offline,
> by interacting with some some secure machine, and walk away with a
> list of square roots you can use for a while, crossing them off as
> you use them, or carry about your square-root device which always
> works backwards from its current seed value and can't be made to
> compute square roots of arbitrary challenges invented by hostile
> people.
Yeah that's the point. Basically you scratch X off your list and
replace it with X^1/2. Then the remote host scratches X^2 and keeps
X. Next time you login you give X^1/2 and they see if X^1/2^2 = X.
Etc. Obviously the remote host does not choose X, you would.
> Paranoid types will like the security guarantees of this system.
> However, it does require rather more processing power than a simple
> hash function. Finally, the responses you have to give are much
> longer than if you just used a hash function: 1024 bits rather than
> 160.
I agree it's slower and requires more bandwidth, but it does have a
nicer sense of proof to it.
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
Comment: Key at: http://tomstdenis.home.dhs.org/key.asc
iQA/AwUBOumR9AULrT+pXe8cEQJlLgCfbalyjX56A6UtReXVoE9o1z5efc0AoI5Y
jvkGsA0L9O84OOJ8IzXFmP5W
=nL/K
=====END PGP SIGNATURE=====
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: request for encryption software suggestions
Date: Fri, 27 Apr 2001 15:39:27 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Eric Kleinberg" <[EMAIL PROTECTED]> wrote in message
news:CUfG6.496$[EMAIL PROTECTED]...
> I am seeking freeware C source which can encrypt a buffer and whose
> output is a buffer of the same size. The encryption does not have
> to be very strong.
>
> Any suggestions (URLs) would be appreciated.
void enc(unsigned char *x, unsigned len)
{
while (len--)
*x++ ^= 0xAA;
}
The nice thing is that enc is it's own inverse :-)
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
Comment: Key at: http://tomstdenis.home.dhs.org/key.asc
iQA/AwUBOumSJwULrT+pXe8cEQJJUgCg2+WITdbWEz9sg1t+FK3t+0gsUVEAoKva
/Wq1BMi9HeH23CqcHK51GHrq
=LGv/
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4 Source Code
Date: 27 Apr 2001 15:49:37 GMT
In <6i7G6.18853$[EMAIL PROTECTED]> "Dirk Mahoney"
<[EMAIL PROTECTED] (remove the _)> writes:
>All searches I did yielded lots of nothing. RSA's site obviously had
>nothing, couldn't find anything in the sci.crypt FAQ, Counterpane's site
>wasn't helpful, neither was Rivest's (for obvious reasons), Terry Ritter's
Actually for a long time Rivest's site DID have a pointer to the ARC4
code. Do not know when it was removed.
My (somewhat old) crypto page does contain a pointer to RC4
www.theory.physics.ubc.ca/pgp.html
ftp://sable.ox.ac.uk/pub/crypto/misc/rc4.tar.gz
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: RC4 Source Code
Date: Fri, 27 Apr 2001 14:39:29 GMT
"r.e.s." <[EMAIL PROTECTED]> wrote in message
news:9cbsn9$dn3$[EMAIL PROTECTED]...
> | I also suspect that the people at RSA Data Security have, at some time
in
> | the past, have actually compared the published ARC4 source code with
their
> | internal source code, and so they also know whether they are identical.
> I was suggesting that the identity is supported by more than just the
> happy comparison of outputs. Presumably someone reverse engineered a
> compiled version of RC4 (say by disassembling it to assembly language)
> so there need not have been a great deal of guesswork involved. Still,
> we can't be absolutely certain of absolute fidelity.
At this point, there are enough independent implementations of RC4 (or
ARC4 if you prefer) that I'd say the public description of RC4 is the one
that defines RC4. If RSADS's version of RC4 is any different (which I
think is very unlikely), then RSADS might have to change its code to
conform to what everyone else accepts as the standard.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Fri, 27 Apr 2001 15:52:06 GMT
David Wagner wrote:
> Trevor L. Jackson, III wrote:
> >By this line of reasoning it is impossible to steal an idea.
>
> Well, I'd say that "theft" is a poor word to use when referring to
> duplicating intellectual property. Taking language that refers to
> physical property and using it to refer to intellectual property just
> leads to confusion and poorly-reasoned arguments.
Hardly. Are you aware of the legal and economic history and justification
for the generalization? Quiz: why are all forms of income "rents", and
what is the original and still fundamental thing rented? Answer: real
estate. It is the refusal to recognize the application of the proper
concepts that leads to confusion and poorly reasons arguments.
One of the fundamental issues regarding property of all forms is how it
changes from the natural state of not being owned to the state of being
owned by a particular person. Mills, one of the luminaries in this area,
concluded that property becomes owned then a person "mixes their effort
with it" -- by plowing a field, digging up a rock, cutting down a tree, or
shaping wood, stone, etc. The same process is involved when a writer mixes
his effort with paper and ink (or floppies and bits), shaping them, to
produce something the we recognize as copywritable.
Note here that the distortion lies not in ignoring the fact that copying a
paper or floppy is easier than copying a plowed field or a cord of wood.
The distortion lies in ignoring the fact that property is the result of
effort. The more effort and less material involved, the purer the property
is. Intellectual property is the purest form and thus deserves the
strongest protection. Your position appears to invert this relationship --
an egregious error.
As a professional whose work product is principally intellectual you should
be aware of these issues.
>
>
> If you have an observation about intellectual property that you think
> is compelling and that is stated in terms of "theft", I suggest trying
> the following: replace the word "theft" with "uncompensated copying"
> (or whatever you like) and see if it affects how persuasive you find
> the argument. If you find the result less compelling after the change,
> that might be because the word "theft" carried some emotional weight
> that misled you into making a fallacious argument.
I do not find it less compelling. But MHO is irrelevant. The reader's
evaluation of the various arguments is the controlling factor.
Since there is a liguistic/semantic issue developing, we should then
consider one of the the fundamental terms of intellectual property, which
is copyright -- the right to copy. This is strictly the right of the
author. Under special circumstances, like a "work for hire", the
hirer/employer owns the resulting work and the associated copy right.
Now there are two things here. The written work of, say, paper and ink, or
floppy and bits, and the right to copy them. These things the object and
the right to produce more of them, can be independently owned and sold.
Thus they can be subject to theft. In this context theft is a property
right. According to the Oxford English Dictionary of 1991 theft is defined
as "the actions of a thief; the felonious taking away of the goods of
another; larceny".
Now the violator of a copyright produces a copy of the original work. That
copy is owned, even if a "derived work" (which see), by the copyright
owner. When the violator uses or trades that copy the action is theft
because the copy is a good owned by another.
Now, where is the "emotional weight" and associated "fallacious argument"
that you claimed existed?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RC4 Source Code
Date: Fri, 27 Apr 2001 15:54:00 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Bill Unruh" <[EMAIL PROTECTED]> wrote in message
news:9cc4eh$6j3$[EMAIL PROTECTED]...
> In <6i7G6.18853$[EMAIL PROTECTED]> "Dirk
> Mahoney" <[EMAIL PROTECTED] (remove the _)> writes:
> >All searches I did yielded lots of nothing. RSA's site obviously
> >had nothing, couldn't find anything in the sci.crypt FAQ,
> >Counterpane's site wasn't helpful, neither was Rivest's (for
> >obvious reasons), Terry Ritter's
>
> Actually for a long time Rivest's site DID have a pointer to the
> ARC4 code. Do not know when it was removed.
>
> My (somewhat old) crypto page does contain a pointer to RC4
> www.theory.physics.ubc.ca/pgp.html
> ftp://sable.ox.ac.uk/pub/crypto/misc/rc4.tar.gz
At anyrate we are escaping the reality that RC4 does have some nasty
properties. It has weak keys, it leaks digraph info. No big attacks
yet but it is crumbling. Not only that you don't know the period of
the generator which is a good thing to know for stream ciphers.
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
Comment: Key at: http://tomstdenis.home.dhs.org/key.asc
iQA/AwUBOumVeQULrT+pXe8cEQIZVACgk0X5FEhSJ654sAwkdCMxXysKcYYAni/P
hpxfPIWHEebOXVP1c0bdy9Db
=HRpw
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Running Time of Factoring Algorithms
Date: 27 Apr 2001 15:55:00 GMT
In <mF4G6.70450$[EMAIL PROTECTED]> "Tom St Denis"
<[EMAIL PROTECTED]> writes:
]> If a factoring algorithm ran with the following upper bound, how would it
]> compare to the various methods that exist?
]>
]> n = p * q
]>
]> smallest of (p, q, p-q)
Terribly. Those are all exponential in the size of n. The best known is
subexponential. (of order exp(1.9 ln(n)^(1/3) ln(ln(n))^(2/3))-- Number Field
Sieve)(The 1.9 is approximate).
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
