Cryptography-Digest Digest #651, Volume #9 Thu, 3 Jun 99 15:13:03 EDT
Contents:
Generating Large Primes in C++ ([EMAIL PROTECTED])
Re: Another source of random numbers ([EMAIL PROTECTED])
Re: ECM factoring question (Medical Electronics Lab)
Re: ECM factoring question (Chris Monico)
Re: random numbers in ml (Medical Electronics Lab)
Re: Challenge to SCOTT19U.ZIP_GUY (David Crick)
Re: Is SSL CPU intensive? (Paul Rubin)
Re: what cipher? (Bruce Schneier)
Re: bareface ratio ([EMAIL PROTECTED])
Re: bareface ratio ([EMAIL PROTECTED])
Re: CRC32 ("Rosco Schock")
Re: CRC32 (Bryan Olson)
Re: what cipher? (Terry Ritter)
Algorithms (Anonymous)
Re: random numbers in ml (Jerry Coffin)
Re: Generating Random Numbers (Doug Stell)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Generating Large Primes in C++
Date: Thu, 03 Jun 1999 14:24:40 GMT
Hi,
I need to generate some large primes ( 512 bit and 1024 bit ) for use
in ElGamal... I've used the search engines and found lots of classes
for large number arithmetic. I was wondering if someone could save me
some time and let me know if they have a favorite publically available
C++ class for generating large prime numbers.
Thanks,
Ron
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another source of random numbers
Date: Thu, 3 Jun 1999 14:27:29 GMT
In article <7j2eq7$ajq$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Robert Nemiroff and Jerry Bonnell have suggested using the digits
> of irrational numbers like Pi, e, and the square root of two, etc.,
> as a source of random numbers. Is this idea widely known?
yes. it's ok for non-cryptographic purposes, though it's slower
than some of the modern non-cryptographic prngs, like marsaglia's.
for cryptographic purposes, the idea is flawed. generally,
people propose using these irrational numbers in two ways:
1. given a seed, choose an irrational number and an offset into
its decimal or binary expansion. use the bits following the
offset as a pseudorandom expansion of the seed.
2. use an irrational number as a source of seeds.
the problem with #1 is that there's no mathematical reason to
suppose that an attacker can't recognize or deduce which irrational
number you started with. just because the digits or bits have a
nice uniform distribution, doesn't mean that they're unpredictable.
the problem with #2 is that it begs the question (you need a secret
seed, by which to choose the irrational number and the offset), and
anyway, #2 is still just a misapplication of #1's technique. the
most conservative use of #2 is to use a structured secret, like your
date of birth, to choose the irrational number and offset, and then
extract only a single short random number from the fractional part.
in this scenario, you're using the random number as a hashing function.
the problem, again, is that nothing has been proven about the irrever-
sibility of this hashing function. if the attacker can use your single
short random numbers to deduce the structured secrets you started with,
he may be able to predict the next structured secret you'll use.
as a rule of thumb, almost all cryptographic problems boil down to
questions about irreversibility.
note that plouffe's & borwein's formula for the hexadecimal digits
of pi is very relevant here. on the one hand, the formula allows
you to quickly calculate, say, 256 bits starting at position 10^100.
but the formula also expresses a mathematical relationship between
those bits and their offset, so that an attacker may be able to use
the formula to work backwards from the bits to deduce the offset at
which they were found.
- don davis, boston
-
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: ECM factoring question
Date: Thu, 03 Jun 1999 12:21:39 -0500
Logic wrote:
> The "exponentiation" (or multiples, depending on what you call the group
> operation) is done like this anyway, as I understand. It's a standard
> "square and multiply" or "multiply and add" type optimization.
But you only multiply once, it's addition forever after.
>
> I'm far from understanding the intricacies of ECM, which is why I asked
> these questions. I know some people who read this group (Silverman?)
> have done some analysis of ECM in the past, so I was hoping someone could
> explain why one sequence is faster than another. Nevertheless, thanks
> for the thoughts, Dr. Mike. I can always use the food for thought :)
I guess I don't understand why you don't compute the order of the point
first. It only takes a minute or so if you're in a prime field (is the
curve in GF(p) or GF(2^n)?) as shown recently in ASIACRYPT '98. If
you need a smooth curve, I'd expect finding a good curve wouldn't take
longer than an hour on a single 500MHz machine, less on an Alpha
class machine. No reason to hope for a smooth curve when it's easy
(well, not that easy!) to find one.
I don't understand the use of EC for factoring, so maybe by asking
lots of questions we'll all learn something. It sounds like you can
save a lot of time by doing some work up front, then use the known
qualities of the curve to help speed up some calculations.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Chris Monico)
Subject: Re: ECM factoring question
Date: Wed, 02 Jun 99 19:26:41 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
>Logic wrote:
>>
>> When doing elliptic curve factorization, we choose an initial point
P on the
>> curve. We then calculate the "multiples" of P recursively by
performing the
>> group operation on it with a sequence of primes under the chosen
bound B.
[snip]
>Do you know the order of P (=k say)? If so, you can compute x^m mod
k
No. The point of ECM is (more or less) to try to find the order of P
(reduced mod q, where q is a prime divisor of n) by hoping it (the
order) is B-powersmooth. This is since all calculations are done using
the standard group law in P^2(Z_n) - the projective plane over Z_n.
Then, if kP=(0:1:0) in P^2(Z_q), the lift of kP to P^2(Z_n) is a so
called special point (usually), where the 1st and 3rd coordinates are
==0 mod q. This will usually reveal a divisor of n at the last step,
since one ends up trying to invert a non-invertible element of Z_n
while doing the last group operation.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: Thu, 03 Jun 1999 12:40:44 -0500
Matthew Montchalin wrote:
> However, the Carry will be set at this point if seed[0] was odd, or clear
> if seed[0] was even. Does the double >> operator reflect this? I am
> unfamiliar with 'C' and find assembly language to be a lot more
> straightforward, and *that* much easier to read.
I am not alone!!!!!! Way cool. I didn't think there was anyone
else in the world who could think clearly :-)
No, the >> operator doesn't rotate, it only shifts. The C people
have told the compiler guys to make the form (x << y) | (x >> (n-y))
to be mean rol x,y. It seems pretty hokey, but on some compilers
you can actually generate a rotate instruction this way.
>
> | i = seed[0] + temp1
> | seed[0] = temp1 + i <<< 1
>
> Note that the Carry will now be set if 255<temp1 + i, or clear if
> 256>temp1 + i. This is important because the Carry will affect the next
> operation.
Note that the triple <<< operator is *pseudo* code, it won't work
on any compiler. You don't have access to the carry bit in C, which
is the main reason I like assembler. Time to invent a new language
maybe? :-)
> Note that the Carry is apparently random at this point. Thus, the
> variable 'i' should be 9 bits wide. Does 'C' support variables that
> are 9 bits wide? Sorry for being so naive.
No, but you can force it to by using 16 bits and masking.
> Can you or anybody suggest what the likely period is for this algorithm?
> By saying 'period,' I mean, how long it will take for the routine to
> repeat, if ever. Short of that, if the routine settles down into an
> infinite pattern, how long does it take to do that? My guess is that the
> routine does not start repeating until a very large number of iterations
> (uh, well, maybe 2^56) have passed. Again, it is only a guess, and what
> seems really random at one point can seem really predictable at another
> point. It is quite possible that I just haven't looked at the thing from
> the *right* perspective yet.
Can you convert it to a set of equations? It may have some very
short cycles as well as long ones depending on which bits are set
or clear to start with. Two or three iterations of the equations
should tell you something about the dependence of each bit on the
others.
Patience, persistence, truth,
Dr. mike
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Thu, 03 Jun 1999 18:58:37 +0100
"SCOTT19U.ZIP_GUY" wrote:
>
> >---------------------------------------------------------
> > /* encrypts a file using 19 bit words */
> > un32 iz, izz, i, j, ip, ipp, k, i19, i19s, jj;
>
> un32 is unsigned integer 32 bits in size
> > p19 *pp19;
>
> p19 is a structure of 19 bit fields alined to 32 bit boundaries
>
> > po19 *ppo19;
>
> po19 is an offset sturcture of 19 bit fileds alinen to 8 bit boundaries but
> when used with the pointer *ppo19 will be set behind the *pp19 pointer
> a few bytes so the 19 bit fileds are off set from matching field by 9 bits.
>
> as you see the magor varibles have meaing fill names though short.
>
> > void *v;
>
> v is a void pointer need it to off set ppo19 from pp19 it a weakness in
> modern C that old c's did not suffer. C does allow easy movement of
> pointers of different types you get an error
[snip]
> maybe I helped with explaning the above cut of code as you
> can see it made perfect since to me.
>
> It is readable!!
*sigh*. You really don't get it do you? The whole point is for
it to be immediately obvious to OTHER people who may wish to
verify/develop your code.
Pick up any programming/software engineering text book and it
will tell you this. It's kiddies stuff.
David.
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Keys: 2048-bit RSA: 0x22D5C7A9 4096-DH/DSS: 0x87C46DE1 |
+-------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Is SSL CPU intensive?
Date: Thu, 3 Jun 1999 17:59:18 GMT
In article <[EMAIL PROTECTED]>, Tim <[EMAIL PROTECTED]> wrote:
>How CPU intensive is SSL? I would be sending (encrypting with SSL) ~100
>bytes of data per second. I have a 68030 running at 20 MHz (embedded
>server application) and can allow 20%-30% of the CPU for this task.
>Does anybody know of, or where I can get the number of required clock
>cycles per byte for SSL?
SSL typically uses RC4 as a bulk cipher, which is very fast.
100 bytes/second should be no problem at all.
The issue is the connection setup, which usually requires a secret key
operation (normally 1024 bit RSA). You are probably looking at several
CPU seconds to start up the connection, with that hardware.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: what cipher?
Date: Thu, 03 Jun 1999 17:57:36 GMT
On Thu, 03 Jun 1999 04:36:41 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>On Wed, 2 Jun 1999 21:09:19 -0400, in
><[EMAIL PROTECTED]>, in sci.crypt "Particle"
><[EMAIL PROTECTED]> wrote:
>
>>I'm looking for a stream cipher, or a block cipher
>>that works in 8-bit intervals. (actually, I'm looking for
>>the algorithm, I'm planning on implementing it myself)
>>
>>It is very important that the ciphertext retain the length
>>of plain text.
>
>It is extremely difficult to have a secure cipher which does not
>expand the ciphertext to some extent.
Actually, I think this is straightforward to do with technology that
is in the public domain, that has been analyzed by cryptographers, and
is generally trusted.
But good luck in whatever you choose.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
Date: Wed, 02 Jun 1999 23:36:09 -0400
From: [EMAIL PROTECTED]
Crossposted-To: comp.lang.perl.misc
Subject: Re: bareface ratio
I R A Aggie wrote:
[snip]
> -----------begin repost----------somethings are timeless...
>
> Date: 09 Nov 1995 02:57:30 GMT
> From: [EMAIL PROTECTED] (Mark-Jason Dominus)
> Subject: Re: system() question
[snip]
> The worst stupid questions are the ones that come from people who
> have no business asking them. The most perfect example of this that I
> could have imagined was in comp.unix.questions a couple of years ago.
> Some guy came and asked how you could tell if a file is a hard link.
> My jaw flapped open and it's stayed open since then. I couldn't have
> been any more stumped if he'd asked why Bodhidharma came from the
> West. What do you say to this guy? Do you tell him the truth, that
> all files are hard links, that even symbolic links are hard links?
> He's not going to understand you; you might as well keep your mouth
> shut. Do you tell him the truth, that the answer won't do him any
> good because he doesn't know what a hard link is, so why did he bother
> asking in the first place? No, that'll just make him mad. I followed
> that message for the next couple weeks, and nobody said anything.
> What could you say? The guy had no business asking the question and
> no use for the answer. Maybe the right answer would have been to cut
> off his finger or something. I dunno.
>
[snip]
There actually is an answer to this kind of question. It's a bit tricky
because you have to rely on side effects, but it is reported to work.
The standard answer to a question that should not have been comes from
Zen. It is "MU". Hofstadter mentions it in his book EGB/EGB. The
effect of reaponding MU is to _unask_ the question. Sometimes that is
the perfect response.
------------------------------
Date: Wed, 02 Jun 1999 23:38:57 -0400
From: [EMAIL PROTECTED]
Crossposted-To: comp.lang.perl.misc
Subject: Re: bareface ratio
Don Roby wrote:
>
> In article <[EMAIL PROTECTED]>,
> Greg Bartels <[EMAIL PROTECTED]> wrote:
> > just an interesting phenomenon I've noticed
> > on newsgroups in general.
> >
> > bareface ratio:
> >
> > the number of people who respond
> > to tell you your information is wrong
> >
> > versus
> >
> > the number of people who respond
> > to your requests for information
> > on the same topic.
> >
> > this seems to be about 3 (or more) to 1,
> > depending on the topic.
> >
>
> We're just trying to keep a positive signal-to-noise ratio.
> All those wrong answers tend to push it negative. Negative information,
> you know.
>
> ;-)
>
> > so, if you have a question, and no one
> > is responding, you can still get the
> > answer, all you have to do is make something
> > up first (bareface it), and the
> > corrections will flood in.
> >
>
> Your description:
>
> Q1: How do I do X?
> ...long wait...no response
> A1: To do X, use Y. (incorrect fake response from original querent).
> A2: Wrong. use Z.
> A3: Wrong. use Z.
> ...etc.
>
> Better approach:
>
> Q1: Can I use Y to do X?
> A1: No. Use Z instead.
>
> I think people are more likely to answer a question with an incorrect
> proposed solution. I think this holds whether or not the incorrect
> proposed solution was part of the original post or not. I have no
> statistical evidence for my claim, but there you go...
>
> I'd rather see the fake answer as part of the original post, so it at
> least LOOKS like you've thought a bit yourself before posting. ;-)
The fake proposal also provides a lot of context that the question may
fail to provide. That context enables a respondent to answer with a
statement rather than a series of context questions.
------------------------------
From: "Rosco Schock" <[EMAIL PROTECTED]>
Subject: Re: CRC32
Date: Thu, 03 Jun 1999 14:46:54 GMT
Hello,
Try this url. The paper it links to is very readable.
It gives a good basic understanding of CRCs.
http://www.ross.net/crc/crcpaper.html
As far as odds go
For example, CRC-32 gives a 1 / 2^32 chance of failure.
That equates to odds of 1 / 4,294,967,295 of getting the same checksum.
However, if you change to a filesize / CRC pair of numbers then
the only way you will get the same checksum is if the files are the same.
HTH,
Rosco
iLLusIOn wrote in message <[EMAIL PROTECTED]>...
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Hello,
>
> I'm looking for any texts/urls with algorithms and descriptions
> of CRC-32 (like used in zip files for example), I have found a few
> sites providing source code but none which provide really useful
> descriptions of how/why it works. anything appreciated :)
>
> are there any ways to speed crc32 up a bit? or are there any
> faster (yet as "secure") algorithms as crc32? how high is the
> possibility that i'd get the same checksum twice? my
> implementation would be used to generate checksums of many
> files, getting the same checksum on two different files would be
> bad.
>
> tia
>
>~~~
>This PGP signature only certifies the sender and date of the message.
>It implies no approval from the administrators of nym.alias.net.
>Date: Thu Jun 3 07:54:19 1999 GMT
>From: [EMAIL PROTECTED]
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQEVAwUBN1Y0rU5NDhYLYPHNAQEEAQf+IWtNZS0IjjVX9bfWh7jYp4cBJrWyqw96
>0x8cbIYRMcWmOsr3Xsf0RQ6HkrRPGLm+Kkqjca11E0xwqNmUfWZorvprqGwvDATA
>JU5Gbv0s5Hw8TXKSGShnqnnfk6tZnMyYw4IjWCbcyPETYSdInOruqbl2XzqI9OQX
>Zj8K/CK0wN+O6mVAV9O/SmWSufwklMTv5lPTkUYMHqIEJjHmuMs7OgWTS0R4cn3t
>oJ+tBda/DFwAhhPQNaVHOnlIDdfoj/F9AVoNKQq0q3NmeGbk4W71LUP9TAHGdCcl
>jaHQ55hyvt4SYR67w40OgBhoEo0N+0JqUtQ1QswP24PRJcr+2Tgdfw==
>=T0LD
>-----END PGP SIGNATURE-----
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC32
Date: Thu, 03 Jun 1999 10:34:51 -0700
Anwer Bashi wrote:
> You can still get the same CRC with two different files of the
> same size. Any change in the file will (very very likely) cause a
> corresponding change in the CRC. All you have to do is copy the original
> file and keep changing the copy by flipping bits here and there at random
> until the CRC happens to come out to be the same again.
[...]
> There are obviously better ways of doing this by working backwards from the
> current CRC and figuring out the appropriate bits to flip to get the desired
> result, however I am not sure how to do this. I would be interested in
> hearing about this (anyone?)
Just XOR in the CRC polynomial. You can generate a million
collisions a second on a computer from a toy store.
--Bryan
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: what cipher?
Date: Thu, 03 Jun 1999 18:37:45 GMT
On Thu, 03 Jun 1999 17:57:36 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Bruce Schneier) wrote:
>On Thu, 03 Jun 1999 04:36:41 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>>[...]
>>It is extremely difficult to have a secure cipher which does not
>>expand the ciphertext to some extent.
>
>Actually, I think this is straightforward to do with technology that
>is in the public domain, that has been analyzed by cryptographers, and
>is generally trusted.
So instead of getting information, we get your typical "smarter than
thou" response: Teacher says, "Johnny, do you know the answer to the
question?" "Yes," says Johnny.
OK, I'll bite: What do *you* think would work? That would be: in
general, for messages of arbitrary size, with accepted security in all
cases.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Algorithms
Date: Thu, 3 Jun 1999 20:38:47 +0200 (CEST)
This is a pseudo-code example showing the LeapFrog
block-cipher. It uses a 64-bit block, and 192-bit key.
Programs using this cipher have been registered with
the U.S. Copyright Office in 1996, and details were
subsequently made public. There is also a BullFrog algorithm
using a 128-bit block but it is not shown here.
This cipher implements substitution-substitution operations
rather than substitution-permutation operations to diffuse
the data; the substitution tables are derived by a non-linear
method from the user's key.
It has good data-diffusion independent of the key, and fairly
simple key-expansion and encryption algorithms, meant to
minimize the possibility of unknown attacks.
The cipher uses a Feistel network, except that one side
operates directly on the other instead of encrypting
on one side then Xoring the other like DES.
A combination of Xor, Table Look-ups, and ADD(NC) is
employed in a non-commutative way. There are no fixed
tables, all are KEY dependant.
* This is NOT actual computer code and *
* NO computer language exists such as this *
Subroutine LeapFrog_ENCRYPT
* T1, T2, T3, T4 are Signed INTEGERS
* p1 through p8 are Signed INTEGERS
For BlockNumber = 1 To Blocks
GetTheNextBlock
p1 = Byte1_From_Block
p2 = Byte2_From_Block
p3 = Byte3_From_Block
p4 = Byte4_From_Block
p5 = Byte5_From_Block
p6 = Byte6_From_Block
p7 = Byte7_From_Block
p8 = Byte8_From_Block
* mask the input data
p1 = p1 Xor A5(A1(keySUM))
p2 = p2 Xor A6(A2(keySUM))
p3 = p3 Xor A7(A3(keySUM))
p4 = p4 Xor A8(A4(keySUM))
p5 = p5 Xor A1(A5(keySUM))
p6 = p6 Xor A2(A6(keySUM))
p7 = p7 Xor A3(A7(keySUM))
p8 = p8 Xor A4(A8(keySUM))
* rounds are 8
For x = 1 To rounds
* get the T variables
T1 = A1(p1), T2 = A2(p2), T3 = A3(p3), T4 = A4(p4)
* note the T variable order
p5 = p5 Xor A1(A1(T2 Xor T3) Xor T4)
p6 = p6 Xor A2(A2(T1 Xor T4) Xor T3)
p7 = p7 Xor A3(A3(T4 Xor T2) Xor T1)
p8 = p8 Xor A4(A4(T3 Xor T1) Xor T2)
p5 = (p5 + T1) And FF
p6 = (p6 + T2) And FF
p7 = (p7 + T3) And FF
p8 = (p8 + T4) And FF
* do other half without swapping
T1 = A5(p5), T2 = A6(p6), T3 = A7(p7), T4 = A8(p8)
p1 = p1 Xor A5(A5(T2 Xor T3) Xor T4)
p2 = p2 Xor A6(A6(T1 Xor T4) Xor T3)
p3 = p3 Xor A7(A7(T4 Xor T2) Xor T1)
p4 = p4 Xor A8(A8(T3 Xor T1) Xor T2)
p1 = (p1 + T1) And FF
p2 = (p2 + T2) And FF
p3 = (p3 + T3) And FF
p4 = (p4 + T4) And FF
Next
* mask the output data
p1 = p1 Xor A5(A1((Not keySUM) And FF))
p2 = p2 Xor A6(A2((Not keySUM) And FF))
p3 = p3 Xor A7(A3((Not keySUM) And FF))
p4 = p4 Xor A8(A4((Not keySUM) And FF))
p5 = p5 Xor A1(A5((Not keySUM) And FF))
p6 = p6 Xor A2(A6((Not keySUM) And FF))
p7 = p7 Xor A3(A7((Not keySUM) And FF))
p8 = p8 Xor A4(A8((Not keySUM) And FF))
* write cipher text
Byte1_In_Block = p1
Byte2_In_Block = p2
Byte3_In_Block = p3
Byte4_In_Block = p4
Byte5_In_Block = p5
Byte6_In_Block = p6
Byte7_In_Block = p7
Byte8_In_Block = p8
WriteThisBlock
Next
End Subroutine
Subroutine LeapFrog_DECRYPT
* T1, T2, T3, T4 are Signed INTEGERS
* p1 through p8 are Signed INTEGERS
For BlockNumber = 1 To Blocks
GetTheNextBlock
p1 = Byte1_From_Block
p2 = Byte2_From_Block
p3 = Byte3_From_Block
p4 = Byte4_From_Block
p5 = Byte5_From_Block
p6 = Byte6_From_Block
p7 = Byte7_From_Block
p8 = Byte8_From_Block
* unmask the input data
p1 = p1 Xor A5(A1((Not keySUM) And FF))
p2 = p2 Xor A6(A2((Not keySUM) And FF))
p3 = p3 Xor A7(A3((Not keySUM) And FF))
p4 = p4 Xor A8(A4((Not keySUM) And FF))
p5 = p5 Xor A1(A5((Not keySUM) And FF))
p6 = p6 Xor A2(A6((Not keySUM) And FF))
p7 = p7 Xor A3(A7((Not keySUM) And FF))
p8 = p8 Xor A4(A8((Not keySUM) And FF))
* rounds are 8
For x = 1 To rounds
* get the T variables
T1 = A5(p5), T2 = A6(p6), T3 = A7(p7), T4 = A8(p8)
p1 = (p1 - T1) And FF
p2 = (p2 - T2) And FF
p3 = (p3 - T3) And FF
p4 = (p4 - T4) And FF
p1 = p1 Xor A5(A5(T2 Xor T3) Xor T4)
p2 = p2 Xor A6(A6(T1 Xor T4) Xor T3)
p3 = p3 Xor A7(A7(T4 Xor T2) Xor T1)
p4 = p4 Xor A8(A8(T3 Xor T1) Xor T2)
* do other half without Exchangeping
T1 = A1(p1), T2 = A2(p2), T3 = A3(p3), T4 = A4(p4)
p5 = (p5 - T1) And FF
p6 = (p6 - T2) And FF
p7 = (p7 - T3) And FF
p8 = (p8 - T4) And FF
p5 = p5 Xor A1(A1(T2 Xor T3) Xor T4)
p6 = p6 Xor A2(A2(T1 Xor T4) Xor T3)
p7 = p7 Xor A3(A3(T4 Xor T2) Xor T1)
p8 = p8 Xor A4(A4(T3 Xor T1) Xor T2)
Next
* unmask the output data
p1 = p1 Xor A5(A1(keySUM))
p2 = p2 Xor A6(A2(keySUM))
p3 = p3 Xor A7(A3(keySUM))
p4 = p4 Xor A8(A4(keySUM))
p5 = p5 Xor A1(A5(keySUM))
p6 = p6 Xor A2(A6(keySUM))
p7 = p7 Xor A3(A7(keySUM))
p8 = p8 Xor A4(A8(keySUM))
* write plain text
Byte1_In_Block = p1
Byte2_In_Block = p2
Byte3_In_Block = p3
Byte4_In_Block = p4
Byte5_In_Block = p5
Byte6_In_Block = p6
Byte7_In_Block = p7
Byte8_In_Block = p8
WriteThisBlock
Next
End Subroutine
Subroutine LeapFrog_EXPAND_KEY
* k() would be the entered/hashed key
* LongKey() would be an array of bytes
* replicate key into array
y = 0
For x = 0 To 255
LongKey(x) = k(y)
y = (y + 1) Mod RealKeyLen
Next
keySUM = 0
* get checksum of real key
For i = 0 To 23
keySUM = (keySUM + k(i)) And FF
Next
* initialize expanded key arrays
For i = 0 To 255
A1(i) = i, A5(i) = i
A2(i) = i, A6(i) = i
A3(i) = i, A7(i) = i
A4(i) = i, A8(i) = i
Next
j = 0
* randomize array
For i = 0 To 255
j = (j + A1(i) + LongKey(i)) And FF
Exchange A1(i), A1(j)
Next
For i = 0 To 255
j = (j + A1(i)) And FF
Exchange A1(i), A1(j)
Next
* randomize the other arrays
For i = 0 To 255
j = (j + A1(A2(i)) + A1(LongKey(i))) And FF
Exchange A2(i), A2(j)
Next
For i = 0 To 255
j = (j + A2(A3(i)) + A2(LongKey(i))) And FF
Exchange A3(i), A3(j)
Next
For i = 0 To 255
j = (j + A3(A4(i)) + A3(LongKey(i))) And FF
Exchange A4(i), A4(j)
Next
For i = 0 To 255
j = (j + A4(A5(i)) + A4(LongKey(i))) And FF
Exchange A5(i), A5(j)
Next
For i = 0 To 255
j = (j + A5(A6(i)) + A5(LongKey(i))) And FF
Exchange A6(i), A6(j)
Next
For i = 0 To 255
j = (j + A6(A7(i)) + A6(LongKey(i))) And FF
Exchange A7(i), A7(j)
Next
For i = 0 To 255
j = (j + A7(A8(i)) + A7(LongKey(i))) And FF
Exchange A8(i), A8(j)
Next
End Subroutine
LeapFrog VALIDATION DATA
key : All Zeros
plaintext : 00 00 00 00 00 00 00 00
ciphertext : 7A DB 60 98 4F 6E 4E F1
key : All Zeros
plaintext : 00 00 00 00 00 00 00 01
ciphertext : 5E 1B 53 74 6D 3F 5A 23
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: Thu, 3 Jun 1999 12:43:42 -0600
In article <7j4pof$7fn$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> I think 'C' tries too much to insulate the programmer from the cold
> reality of 6502 assembly language,
For most people, 6502 assembly language is NOT "cold reality" -- it's
a distant memory, or else something altogether foreign to their
experience.
When you're trying to express an algorithm, C has the distinct
advantage of being understandable to a wide variety of programmers.
For writing the fastest possible programs, assembly language is a fine
choice. For conveying algorithms, it's not nearly as universal.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Generating Random Numbers
Date: Thu, 03 Jun 1999 15:39:35 GMT
On Mon, 31 May 1999 09:07:19 -0400, "Brian Ross" <[EMAIL PROTECTED]> wrote:
>Brian,
>
>I was wondering how to generate random numbers which will be used for
>encryption keys. My main concern is how to generate a random seed which is
>random enough to ensure that the generated bits are indeed random.
Look for anything and everything in your environment that is unique
and has entropy. This is usually OS dependent, as the OS may only
provide an application with some information. Possibilities are:
1. human-entered data (mentioned by another response)
2. human-entry timing characteristics
3. file system characteristics of many kinds
4. disk drive timing characteristics
Remember that you can also "stir in" (RSADSI's term from the BSAFE
library) additional entropy that you obtain over time. This makes the
seed better as time goes by. Just keep hashing stuff in with the
initial seed. Possibilities are:
1. hashes of plaintext that is transmitted in ciphertext form
2. timing of events
3. user actions
doug
------------------------------
** 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
******************************
