Cryptography-Digest Digest #329, Volume #14 Thu, 10 May 01 16:13:00 EDT
Contents:
Secret Sharing algo ("Thomas J. Boschloo")
Re: Intacta.Code ... (WARNING: high heat ahead, possible exposure to (newbie)
Re: Cryptanalysis Question: Determing The Algorithm? (Terry Ritter)
Re: Tiny s-boxes ("Simon Johnson")
RC4 ("William")
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm ("Simon Johnson")
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: Probablistic Algorithms For Square Roots of QRs in Z/n ("Jeffrey Walton")
Re: Crypto web-page ("Tom St Denis")
Re: enumerating permutations ("Tom St Denis")
Re: Bitsliced Cipher ("Tom St Denis")
Re: Crypto web-page ("Tom St Denis")
Re: Bitsliced Cipher ("Tom St Denis")
Re: ECC question ("Tom St Denis")
Re: RC4 ("Tom St Denis")
Re: free en/decryption library ("Tor Rustad")
Re: Crypto web-page ("Sam Simpson")
----------------------------------------------------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Secret Sharing algo
Date: Thu, 10 May 2001 19:51:01 +0200
[replace nospam with boschloo to reply]
=====BEGIN PGP SIGNED MESSAGE=====
Hi everybody, sorry about the troll that keeps following me, but I have
a real question now.
I haven't done my own research properly, but I know from PGP that it is
possible to share a secret key into several parts of which a certain
number need to be reunited again in order to use the secret key. Now I
am not a crypto-genius, but at first glance this secret sharing
algorithm seemed like something complicated to me.
How about just encrypting the secret key to all key share-holders in
succession?! Without any checksums inside which would compromise the
final security. E.g. if you want to split a key into five shares of
which three need to be reunited you could just encrypt the key to every
possible combination of three keys:
/5\
\3/ == 5!/(3!.2!) == 5.4/2= 10 different encrypted blocks of keys. Not
that much data to use. If you want all shares to be united you would
just need one block of encrypted secret key data. Even (5 above 4) has
lesser data than the (5 above 3 or 2) example.
K.I.S.S. ??!
I was reminded of this because in Holland we will get surveilance
camera's which will have their output XOR-ed into several different
streams which will need to be re-united all for the police or some other
instutition being able to breach the privacy of the people recorded on
those camera's. <http://www.nrc.nl/W2/Nieuws/2001/04/28/Vp/wo.html> This
system seemed to bit clumpsy, but very effective to me at first.
Any thoughts?
Regards,
Thomas J. Boschloo (and not his little 'Talking Pet')
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: My homepage <http://home.soneraplaza.nl/mw/prive/boschloo>
iQB5AwUBOvrG8wEP2l8iXKAJAQGPVAMbBQJoxwSdQO6upxDPI555j2b49qAsF09d
7quKJQdk4i91M52xoUR9vuI7kgieqsqOnH7QUCF3JyB3zY9NYkQUNlU/kCc8h73B
oBSjYxc7eb3GdrjKDp5J1naKlD5hua+IFVkyew==
=/0RQ
=====END PGP SIGNATURE=====
--
"Software patents harm the flow of free information"
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Intacta.Code ... (WARNING: high heat ahead, possible exposure to
Date: Thu, 10 May 2001 14:14:12 -0300
You are a pig? I'm happy to know that.
big pig or little pig?
Paul Pires wrote:
>
> Never wrestle with a pig......
> You both get coverd in mud, discarded food and feces
> but da pig likes it.
>
> Paul
>
> Joseph Ashwood <[EMAIL PROTECTED]> wrote in message news:#rCMUBM2AHA.196@cpmsnbbsa07...
> > Noone attacked you, in fact you were corrected relatively minorly (see the
> > rather severe conversations I've had with Szopa to see how mild). It was not
> > to be a personal attack. Tom was correcting a mistake you made, albeit he
> > didn't do it in the kindest way, but his attitude problem is fairly typical
> > for this group. From there you continued to take the attack personally and
> > began personal attacks on him.
> >
> > John's so-called attack on you was a comment that I guess hit your
> > masculinity a bit too closely to what you fear, for the rest of us it was a
> > funny remark. Don't worry it's fairly normal to be homophobic. Just please
> > understand around here no one will stab you in the back, it's the front or
> > nothing.
> >
> > Now my response, yeah I'd say that was rather close to a personal attack. I
> > figured if you wanted to keep the insults up, I'd give you a target that
> > bites back very well. I don't consider it too much of a waste of time (a
> > waste of bandwidth certainly, but not a waste of time) we all need an outlet
> > for our stress. I figured my response would have one of two responses, you'd
> > either go away, or realize that there are much worse people to have insult
> > you.
> > Joe
> >
> > "newbie" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > ????
> > > What are you talking about???
> > > Once you read what it was said before, then you have the right to
> > > talk!!!!!!!
> > > Tom attacked me
> > > John Lebbs attacked me
> > > And now you!!!!
> > > You are wasting your time!!!!
> > > Are you crazy???
> >
> >
> >
> >
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Thu, 10 May 2001 18:35:19 GMT
On Thu, 10 May 2001 17:10:33 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"Bo Dömstedt" wrote:
>> You still assume that the set of cipher algorithms is equivalent to
>> the set of published cipher algorithms (everyone else reading
>> has already figured this out, right ??)
>
>You cite Kerckhoff's principle, but then ignore it.
>The only way it would be safe to assume that the enemy
>cannot figure out likely candidates for the algorithm
>would be to have too many of them (known to the enemy,
>a la Kerckhoff). But the selection would have to be
>part of the key (or else the intended recipient also
>cannot figure out which algorithm). So this just turns
>into a standard situation of a known (meta-)system
>with an unknown (meta-)key.
That might be true if for some reason we *assume* that the set of
ciphers to be used is fixed.
But the situation would *not* be "standard" if the set of possible
ciphers was continually expanding:
When new ciphers are frequently entering the mix, there may not *be* a
time when "all possible" ciphers have been examined (and, thus, can be
differentiated), simply because it is faster to use a cipher than to
examine it.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Tiny s-boxes
Date: Thu, 10 May 2001 19:54:35 +0100
David Wagner <[EMAIL PROTECTED]> wrote in message
news:9d9q4p$i0d$[EMAIL PROTECTED]...
> Simon Johnson wrote:
> >A friend told me that (a/x) where x is in GF(2^w) and a and is a fixed
> >polynomials gives optimal performance against differential and linear
> >cryptanalysis.
>
> Sure, this is the idea behind the Rijndael S-box and many others.
> On its own, this is pretty awful against rational interpolation attacks,
> though...!
Up to this very second I'd never heard of that particular attack... =)
I assume it attacks the algebraic structure of the s-box?
Another question: Does the formation of this attack require some kind of
precomputation, like in differential analysis where you generally have to
generate a difference table?
If so, then in the context of this thread, if we make 'W' large enough... we
can make it computationally infeasible to find a way to exploit the cipher
in this way. The weakness will clearly still exist... but you have to find
an inventive way of gathering information about the cipher's structure.
------------------------------
From: "William" <[EMAIL PROTECTED]>
Subject: RC4
Date: Fri, 11 May 2001 02:43:39 +0800
Hi all,
I am doing RC4 course project but have not yet found design and analysis
papers or website about RC4. Please anyone suggest some websites and papers.
Thanks a lot,
William
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 10 May 2001 18:53:18 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in <[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>> ... But if you look at the UK my understanding is
>> crime is going up. ...
>
>Of course it is, but it has nothing to do with spying.
>They stupidly disarmed the law-abiding populace, giving
>criminals less to fear. Same in Australia.
>
I'm sorry to hear about that. I have meet over the
years some wonderful people from Australia. I thought
it might be a nice place to retire. But if I can't keep
my 357 next to my pillow it would be harder to sleep at nite.
I rest better knowing I can blast to hell any bastard breaking
into my place. Looks like if I move there I would have to be
satisfied with just a pet bull terrrior to protect the
home stead.
Either that or learn what ever the hell the Swiss speak since
I have met several of them at gun shows and a couple of
solder of fortune shows they seem to still be a free people.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 10 May 2001 18:41:13 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in <[EMAIL PROTECTED]>:
>> ... Measuring the actual security has nothing to do with the speed
>> of encipherment/decipherment, at least not where slower is necessarily
>> better.
>
>Except if the best (known) attack is brute-force key search,
>in which case inherently slow algorithms are slightly more
>resistant than fast ones. However, in applications, faster
>has other advantages, and since no modern system should be
>significantly vulnerable to brute force, deliberate slowness
>offers no practical advantage.
>
Above you imply they may have secret means and propably
do have means that are not known to the "open community"
if that is true one can't prove any so called modern system
would be vulnerable to there methods. So one can't say that
blind brute force is the only way. I think its highly likely
that when the method is known only very seldom is dumb blind
brute force search the only way. If thats the case the only
real help is complexity that does not lead to something that
may have an easy inverse. If it can be encrypted very rapidly
by a given method then most likely there is an easy inverse.
This again leads one to think about compression as not only
increaseing the work factor by making the amount of calulations
to even do an inverse harder. It can increase the entropy per
bit. With something like BICOM an easy break would imply
not only clever insights into the weakness of Rijndeal but
weakness is how one should do bijective PPM compression.
They may be ahead in compression as while as encryption but
I doubt there are as many secrets about compression except
that they take advantage of the poor types of compression
people are stuck with when they use PGP. Those compressions
that are weak (non bijective) would be under intense study at
the NSA.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Thu, 10 May 2001 20:07:37 +0100
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "SCOTT19U.ZIP_GUY" wrote:
> > IN short the NSA has to much power. The more power it has the more
> > corrupt it will be come. I prefer a free people that don't need a
> > big brother watching our every step.
>
> NSA's not watching you; they're watching the people who are
> out to do you harm. Big difference!
Hear! Hear! =)
In reality... the governments really don't care who we are as long as we
behave.
Simon.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 10 May 2001 19:02:09 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in <[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>> so any block cipher using a 128 bit block and only a 256 bit key
>> can not be very complex. And for a given method with a small
>> key of 256 bits. It would not take very many pairs of cipher text
>> to plain text to mathemtically have enough information to determine
>> the key. A place like the NSA would only need a few pairs to uniquely
>> show which Rijndeal key was used. It would be foolish for them
>> not to build custom hardware to do this.
>
>This is correct in principle, but the devil is in the details.
>One cannot in practice construct in advance a mapping database,
>because it would have to be way too big to have appreciable
>coverage (so that it would find a "hit" often enough to
>justify the expense). And a dynamic approach amounts to
>cryptanalysis, so the question is, how? It's not like solving
>a set of linear equations.
>
More like a set of nonlinear equations. Or one of finding
a way to transform it to a set or space where the problem is
much easuer to slove. In short working at the NSA would be
fun assuming they really want to break code. Except I hear
they use ADA a lot and that really sucks as a language.
I agree why do you think the NSA has such a big budget besides
a tremdous data base of knowledge. They have thousands over the
years working on the details. That is also why one should not
trust any implimentation of Runjndael that can expose plaintext
cipher test pairs. Or specail relationships between consecutive
blocks. Best if one uses it in a way to totally obsure it,
Such as use BICOM with one key
reverse file
Use BICOM with second key
Then it becomes much more challengeing for them to break.
My goodness shouldn't we force the NSA to do some work.
I sure they would love working on that. But by the
time they solve it if they ever do. Matt or I or someone
else will come up with a better compression stage.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Probablistic Algorithms For Square Roots of QRs in Z/n
Date: Thu, 10 May 2001 15:18:51 -0400
Exactly.
Factoring, like ECC, is very addictive.
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
Jeffrey Walton <[EMAIL PROTECTED]> wrote:
> Anyone have a heuristic or probabilistic Algorithm?
>
> I was experimenting with Newton's method, but it acts like Pollard Rho in
> Zn.
If n is prime then you have no problem: there's a probabilistic
algorithm which gives you a square root mod a prime in expected
polynomial time.
If n is composite, you should factor n first. Extracting square roots
mod a composite n is as hard as factoring n. (Proof. Let n be
composite. Choose any x. Use your square-root algorithm to find y such
that y^2 = x^2 mod n. Then gcd(x - y, n) is a nontrivial factor of n
with probability at least 1/2.)
-- [mdw]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Crypto web-page
Date: Thu, 10 May 2001 19:26:48 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > "Widespread use of the RSA public-key algorithm, when there are superior
> > alternatives. "
> >
> > Which is stupid since RSA has yet to be broken and RSA is far simpler
then
> > "surperior" algorithms
>
> The underlying theory is, admittedly, simple.[1] But there's lots of
> weird special cases and strange things you have to do with RSA --
> padding systems like PKCS#1 or OAEP or PSS, knowing what sizes of
> exponent to use, etc. So I dispute that RSA is actually `far' simpler
> than other algorithms.
>
> Even elliptic curve crypto can be considered to be on the same level of
> complexity. You have to implement the maths, and it's a bit weird in
> places, but you have to implement the maths for RSA too (including
> strange things like sliding-window exponentiation and Montgomery
> reduction). Yes, there are bad types of curves, but you can avoid them
> by just using off-the-shelf curves from OAKLEY or FIPS 186-2.
>
> [1] I think that Diffie-Hellman (and hence ElGamal) is actually
> conceptually simpler, and that Diffie-Hellman is actually better in
> many protocols because it can provide perfect forward secrecy much
> more cheaply.
On second thought I agree that DH is far simpler :-)
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: enumerating permutations
Date: Thu, 10 May 2001 19:27:59 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>
> >Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> >: I got bored in my College "Technical Math" class so I think I came up
> >: with a way to enumerate permutations [...]
> >
> >The conventional way to number permutations is to put them into
> >lexicographic order. There's and existing algorithm to iteratively
> >generate permutations in this order.
> >
> >The algorithm is described in: E. W. Dijkstra, A Discipline of
> >Programming, Prentice-Hall, 1976, p.71.
> >
> >There's an implementation with source code in an applet on one of my
> >pages:
> >
> > http://mandala.co.uk/permutations/
>
> Actaully if Tom looks at the code for scott16u I have to deal with
> permutations. You cam look at the table as a shuffling of a deck
> of cards wiht 2**16 cards. the key is sort of the index to the
> permustion used. If you look at the code it not that hard to generate
> a unqiue number that stands for each permutaion.
I don't care to look at your "code". I think my (I refer to the method I
talked about, I know it's not my invention) method is about as simple as you
can get without collisions.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Bitsliced Cipher
Date: Thu, 10 May 2001 19:31:12 GMT
"jlcooke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> May I ask what your design reasons were for the use of {29,26,25,21} in:
> a = a ^ c ^ ROL(d,29); // ROL(x,29) == ROR(x,3)
> b = b ^ d ^ ROR(c,26); // ROR(x,26) == ROL(x,6)
> c = c ^ b ^ ROR(a,25); // ROR(x,25) == ROL(x,7)
> d = d ^ a ^ ROL(b,21); // ROL(x,21) == ROR(x,11)
> which can be re-reitten with only ROR:
> a = a ^ c ^ ROR(d,3);
> b = b ^ d ^ ROR(c,26);
> c = c ^ b ^ ROR(a,25);
> d = d ^ a ^ ROR(b,11);
>
> Bajalcaliev, can you do another avalanche test (or email me the source
> for your avalance code)? What are the avalanche results with
> {ROL,ROR,ROR,ROL} := {29,23,19,17}?
To be honest so far it's only been trial and error. I would pick a quad of
values and see the avalanch effect (by outputting the the intermediate state
at each round). I removed the bitslice sbox and check.
I found some quads to be horrible (alot of collisions so you get 32-bit
words like AAAA55BB 00AA5500, etc...).
I know I have some "serious" work ahead of me. For now I will stick with
the values I chosen in my source code for the analysis.
I did my own SAC test and with a million inputs the bias goes towards 0.4 %
(100% being always the same, 0% being randomly the same). As the number of
trials increases the bias goes => zero which is IMHO a good thing.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Crypto web-page
Date: Thu, 10 May 2001 19:31:51 GMT
"jlcooke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > I.e "Failure to implement protection against "known plain-text"
attacks."
> > which is impossible except for physical protection.
> > and
> > "In the context of a public-key cryptography system: Thinking it's safe
to
> > send a public-key across an insecure network or communications medium,
such
> > as the internet. Since we all know that sending a public-key across an
> > insecure network means someone can intercept it "en route" and replace
it
> > with his/her own."
> >
> > Which is only half true. Using a web of trust it's possible todo this
> > correctly.
>
> I think you'd be hard pressed to find a successful example of this at a
> global scale Tom. I'm getting flash-backs of a news headline: "VeriSign
> falsely issues two Microsoft certificates". And how do you test the
> authenticity of the amazon.com cert? With the CA cert you downloaded in
> Netscape? Chicken and Egg.
I agree. But if I was at a company and we physically handed each other the
master CA key, I think I could trust PK a bit more.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Bitsliced Cipher
Date: Thu, 10 May 2001 19:36:41 GMT
"Kostadin Bajalcaliev" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have an impression that the avalanche effect results of TC15 have not
been
> understood. Here is the test:
>
> for each of 128 possible differences (practically two numbers x and y have
> n-bit difference if x xor y have n ones) 10000 random pairs are generated
by
> an external source. This will be 1000 pair having differ in only 1 bit,
> 10000 pairs differ in 2 bits and so on to 128 bit difference. If the
cipher
> is a good one the output difference for each possible input difference
> should have approximately combinatorial distribution. Combinatorial
> distribution is defined as d(k) = n!/[(n-k)!*i!], this is practically the
> how many 128-bit number have one 1-bit, how many have 2 1-bits and so on.
> percentile distribution is defined as pd(k) = d(k)/Sum(d(k),k=1 to 128).
> This means for each input difference 7% of the output differences should
be
> 64 -bits. Here is the expected distribution (in percents).
> TC15 give the expected distribution of the output differences. TC15 using
> only 8 rounds pass the test also. Usign the rotations you have proposed
does
> not change anything.
Ok now I get your test. In the file you sent some values were like
700/10000 and I thought it was a bias in a SAC sense.
Um I can trivially make a LT that will fail your test though (hint change
all the rotations so the bits line up and cancel out). My LT was designed
to avoid that over many rounds (e.g. increase the number of active sboxes).
afaik All I need are 32 active sboxes and I win against diff and linear
attacks. in TC15 that ammount to at least 2 boxes per round which is most
likely a virtually certainty.
Of course truncated attacks may still be possible (boomerang and slide are
not).
I would like to thank you guys for showing interest in this design. It
shows some promise since it's fast, simple, compact and easy to implement.
Tom
> 1 - 39 0.000
>
> 40 0.001
> 41 0.002
> 42 0.003
> 43 0.007
> 44 0.013
> 45 0.024
> 46 0.043
> 47 0.076
> 48 0.128
> 49 0.208
> 50 0.329
> 51 0.503
> 52 0.745
> 53 1.069
> 54 1.484
> 55 1.997
> 56 2.603
> 57 3.288
> 58 4.025
> 59 4.775
> 60 5.491
> 61 6.122
> 62 6.615
> 63 6.930
> 64 7.039
> 65 6.930
> 66 6.615
> 67 6.122
> 68 5.491
> 69 4.775
> 70 4.025
> 71 3.288
> 72 2.603
> 73 1.997
> 74 1.484
> 75 1.069
> 76 0.745
> 77 0.503
> 78 0.329
> 79 0.208
> 80 0.128
> 81 0.076
> 82 0.043
> 83 0.024
> 84 0.013
> 85 0.007
> 86 0.003
> 87 0.002
> 88 0.001
> 89 - 128 0.000
>
>
>
>
>
>
> jlcooke wrote in message <[EMAIL PROTECTED]>...
> >May I ask what your design reasons were for the use of {29,26,25,21} in:
> > a = a ^ c ^ ROL(d,29); // ROL(x,29) == ROR(x,3)
> > b = b ^ d ^ ROR(c,26); // ROR(x,26) == ROL(x,6)
> > c = c ^ b ^ ROR(a,25); // ROR(x,25) == ROL(x,7)
> > d = d ^ a ^ ROL(b,21); // ROL(x,21) == ROR(x,11)
> Tom
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ECC question
Date: Thu, 10 May 2001 19:37:33 GMT
"Mike Rosing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > Probably the dudes name was "Jakob" or something...
>
> Jacobians are something totally different....
>
> Keep reading :-)
Bah I am learning about "systems of linear equations" and "cramers rule" in
college now... (we do those in high school)...
Thanks for all your help Mike, you're a cool dude.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RC4
Date: Thu, 10 May 2001 19:38:05 GMT
"William" <[EMAIL PROTECTED]> wrote in message
news:9dendq$7fs$[EMAIL PROTECTED]...
> Hi all,
>
> I am doing RC4 course project but have not yet found design and analysis
> papers or website about RC4. Please anyone suggest some websites and
papers.
> Thanks a lot,
Look up a dude named "Scott Fluhrer".
Tom
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Thu, 10 May 2001 21:50:21 +0200
"Bill Unruh" <[EMAIL PROTECTED]> wrote in message
> In <[EMAIL PROTECTED]> Frank Uepping <[EMAIL PROTECTED]>
writes:
>
> >Hi,
> >I am new with en/decryption and I am looking for a free and open
> >en/decryption C/C++ library that compiles with gcc and C++ Builder.
>
>
> Try cryptlib
>
> http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
Very good library indeed and the documentation is excellent aswell, but
there are some licence issues.
I have only tried it on Win32 myself, but it has been ported to/from UNIX,
MVS and even NSK.
--
Tor <torust AT online DOT no>
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Crypto web-page
Date: Thu, 10 May 2001 20:50:51 +0100
Hi Mark,
I think the argument has been made before that (for example...) both RSA and
Elgamal signatures have many gotchas that one needs to be aware of when
coding the algorithm. The difference appears to be that RSA has standard
definitions for signatures (ANSI, the various PKCS etc) that avoid all known
problems, whereas traditional Elgamal signatures have no such standard and
instead rely upon each implementor reading huge swathes of literature to get
the implementation correct and avoiding the many pitfalls.
Of course, we now have opportunity to use DSS and as per [1] "Our results
have also explained the design of the US digital signature standard. It is
really just Elgamal with most of the bugs fixed."
I strongly respect you opinion so I'd be interested in your comments on this
point of view?
(PS: We're still using Catacomb in the development of Scramdisk for Linux -
cheers again!)
--
Regards,
Sam
http://www.scramdisk.clara.net/
[1] W.Aiello, R.Venkatesan, "Foiling Birthday Attacks in Length-Doubling
Transformations", Eurocrypt 96, 1996.
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > "Widespread use of the RSA public-key algorithm, when there are superior
> > alternatives. "
> >
> > Which is stupid since RSA has yet to be broken and RSA is far simpler
then
> > "surperior" algorithms
>
> The underlying theory is, admittedly, simple.[1] But there's lots of
> weird special cases and strange things you have to do with RSA --
> padding systems like PKCS#1 or OAEP or PSS, knowing what sizes of
> exponent to use, etc. So I dispute that RSA is actually `far' simpler
> than other algorithms.
>
> Even elliptic curve crypto can be considered to be on the same level of
> complexity. You have to implement the maths, and it's a bit weird in
> places, but you have to implement the maths for RSA too (including
> strange things like sliding-window exponentiation and Montgomery
> reduction). Yes, there are bad types of curves, but you can avoid them
> by just using off-the-shelf curves from OAKLEY or FIPS 186-2.
>
> [1] I think that Diffie-Hellman (and hence ElGamal) is actually
> conceptually simpler, and that Diffie-Hellman is actually better in
> many protocols because it can provide perfect forward secrecy much
> more cheaply.
>
> -- [mdw]
------------------------------
** 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
******************************
