Cryptography-Digest Digest #320, Volume #12 Mon, 31 Jul 00 14:13:01 EDT
Contents:
Re: Skipjack and KEA test vectors (Brian K. Ogilvie)
Re: Pegwit - "Weak" ECC with GF(2^m), m composite? (John Myre)
DES implementation woes ([EMAIL PROTECTED])
Re: Skipjack and KEA test vectors (Mark Wooding)
Re: PGP US Versions Broken,no good?? (Florian Weimer)
Re: DES implementation woes (Mark Wooding)
Re: Reference to a public key technique in NYTimes (Gordon Walker)
Re: Software to ECDSA? (Mike Rosing)
Re: Enigma ("Douglas A. Gwyn")
Re: Small block ciphers ("Douglas A. Gwyn")
Re: Software to implement elliptic curves? (Steve Weis)
Re: purpose of final swap in Twofish? (Matthew Skala)
Re: Has RSADSI Lost their mind? (Bob Silverman)
Re: Math�matics (Bob Silverman)
Re: Combining bit sequences (Mok-Kong Shen)
Re: Elliptic Curves encryption (Steve Weis)
Re: Elliptic Curves encryption (Mike Rosing)
Re: BUGS v3.3.0 - CONTEST (Mack)
Re: How secure is Pegwit? (Mike Rosing)
Re: Small block ciphers (Mack)
Blowfish Implementation (Joseph Stein)
Re: Small block ciphers (Mack)
Re: PRNG cryptoanalysis (Corrado Galdini)
Re: Elliptic Curves encryption (Mike Rosing)
PRNG cryptoanalysis (Corrado Galdini)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Brian K. Ogilvie)
Subject: Re: Skipjack and KEA test vectors
Date: 31 Jul 2000 10:31:14 -0400
[EMAIL PROTECTED] (Mark Wooding) writes:
> In a different thread, the subject of the paucity of Skipjack test
> vectors came up. In particular, Annex III of `SKIPJACK and KEA
> Algorithm Specifications' version 2.0 (29 May 1998)[1] only provides one
> test vector for the Skipjack algorithm itself, and it doesn't cover the
> F table very thoroughly.
One could always get an independent lab to test your Skipjack
implementation. See
http://csrc.nist.gov/cryptval/
for details. This service only costs a few hundred dollars.
If the Skipjack tests are like the DES validation tests, there are a
few specific tests given, but the bulk of the testing is done by
feeding back results (i.e. output fed back to input, key set to old
key XOR output). An in/out/key triple is printed every 1000 encrypts
to check results. This is similar to Ron Rivest's old DES test using
16 vectors, but on a larger and presumably more random scale.
--
Brian K. Ogilvie
[EMAIL PROTECTED]
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Pegwit - "Weak" ECC with GF(2^m), m composite?
Date: Mon, 31 Jul 2000 09:28:06 -0600
Ed Suominen wrote:
<snip>
> OK, so if m is 15 (k=3,d=5) then
<snip>
For pegwit, m = 255. So I think k = 17, and d = 15.
So instead of O(2^127) we get O(2^34).
(I haven't read Smart's paper, so I don't know what
choice we have for k and d; it could only get worse
if, say, we can choose k=3 and d=85.)
JM
------------------------------
From: [EMAIL PROTECTED]
Subject: DES implementation woes
Date: Mon, 31 Jul 2000 15:43:16 GMT
I am implementing DES for a JavaCard platform and have stumbled across a
very nasty error.
In short, program does not work correctly with given test data. Data is
100% correct (taken from two other crypto packages). But even with the
simplest test set where plaintext block and key are 0, the result of
encryption round 1 differs from that of Eric Young's implementation
(here referred to as EY program). The difference occurs somewhere in
S-box substitution block and P-box permutation block, which are merged
in EY program and clearly separated in mine.
Most frustrating is that even when doing round 1 by hand I get same
result as in my program. On the simple test set of plaintext=0 and
key=0, the trace is: S-box input is 0, output is 0xD4C27AFE which is
then permuted into 0x4A7FF632. XORing it with L, which is 0, gives the
same, so that is also the result of this round. On the other hand, EY
program produces 0x7BB63636 in round 1.
It seems that I have missed some very basic detail of DES algorithm, but
I can not figure out what. I have been using "Applied Cryptography" and
FIPS PUB 46-2 as reference.
Any kind of help would be greatly appreciated.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Skipjack and KEA test vectors
Date: 31 Jul 2000 16:11:05 GMT
Brian K. Ogilvie <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Mark Wooding) writes:
>
> > In a different thread, the subject of the paucity of Skipjack test
> > vectors came up. In particular, Annex III of `SKIPJACK and KEA
> > Algorithm Specifications' version 2.0 (29 May 1998)[1] only provides
> > one test vector for the Skipjack algorithm itself, and it doesn't
> > cover the F table very thoroughly.
>
> One could always get an independent lab to test your Skipjack
> implementation. See
>
> http://csrc.nist.gov/cryptval/
>
> for details. This service only costs a few hundred dollars.
Ho! I'm writing free software, in my spare time. No way am I forking
over hundreds of quid for this.
And it's missing the point anyway. I've looked at a few Skipjack
implementations now, and they all agree with mine. I'm getting fairly
convinced that my implementation is doing the right thing, according to
the version 2 spec.
The important questions are:
1. Does anyone have a Skipjack implementation which does *not* pass
this test vector?
key = e7496e99e4628b7f9ffb
plaintext = 99ccfe2b90fd550b
ciphertext = 60a73d387b517fca
2. If this is the correct behaviour, then why do the KEA test vectors
suggest that the correct behaviour is actually
key = e7496e99e4628b7f9ffb
plaintext = 99ccfe2b90fd550b
ciphertext = 2f30????????????
key = e7496e99e4628b7f9ffb
plaintext = 2f30????????????
ciphertext = 740839dee833add4
where the ? are unknown hex digits? Or, alternatively, why is this
the wrong thing for me to expect?
I've now gone through my F-table again, by hand, and checked that it
matches the one in the spec, which I freshly fetched and magnified.
I've also gone through the KEA test vectors with a multiprecision
calculator to confirm that the numbers I'm stuffing into my Skipjack
implementation are the right ones.
One of these is true:
1. My implementation is wrong. So, among others, is Doug Gwyn's.
2. The KEA test vectors are wrong. Both of them.
3. My understanding of the key derivation algorithm is wrong.
4. Something spookier has happened. Insert your favourite paranoid
delusion here.
I think that 3 must be the most likely explanation. But I'm damned if I
can see where I'm going wrong.
-- [mdw]
------------------------------
From: Florian Weimer <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: 31 Jul 2000 18:22:17 +0200
[EMAIL PROTECTED] (Edward A. Falk) writes:
> >GnuPG (http://www.gnupg.org/).
>
> Thanx for the pointer. Using it would mean losing compatibility
> with PGP 2.6 though.
I don't think so. It tool some time until I figured out how to create
messages which can be processed by PGP 2.6.x, but it works.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: DES implementation woes
Date: 31 Jul 2000 16:24:40 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> S-box input is 0, output is 0xD4C27AFE
This should be 0xefa72c4d. You're applying the S-boxes in the wrong
order. DES specs have funny bit numbering: the *most* significant bit
is labelled 1. Be careful of this!
Also bear in mind that Eric Young's version keeps the block rotated by
one place, which makes doing the E expansion on the fly slightly easier,
and that he's reflected the world so that his implementation can be
little-endian. Bleugh.
-- [mdw]
------------------------------
From: Gordon Walker <[EMAIL PROTECTED]>
Subject: Re: Reference to a public key technique in NYTimes
Date: Mon, 31 Jul 2000 17:35:10 +0100
On Sun, 30 Jul 2000 06:53:12 -0400, Johnny Bravo <[EMAIL PROTECTED]>
wrote:
>>minute song could be scrambled into 180 different codes; anyone
>>taking the time to break a single code would be rewarded with only one
>>second of music.
>
> And it only took one second to think of a way to bypass six years of
>"research".
>
> Play music, record music as it gets sent to speakers. The software
>needed for this is already around, I've used it to record a broadcast
>channel playing through WinAmp.
But it's not a direct digital copy, you're adding a trip out through
the A/D converter and back in through the D/A. Granted, for a format
like MP3 this degradation probably isn't noticeable but it still isn't
the exact copy possible with unprotected digital recordings.
--
Gordon Walker
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Software to ECDSA?
Date: Mon, 31 Jul 2000 11:39:59 -0500
Sergio Arrojo wrote:
>
> Anybody knows where could I get some software to download to implement the
> digital signature algorithm ECDSA?
I've got it burried someplace in the "protocols.c" file on my web site.
See http://www.terracom.net/~eresrch
You can also get it from this site: http://www.manning.com/rosing but
you have to trick it into thinking you've got the book.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Enigma
Date: Mon, 31 Jul 2000 15:48:38 GMT
Jim Gillogly wrote:
> Some others, including strong chess players, think a 20-ply program
> won't be much better against strong humans than a 13-ply program.
I suspect their reasoning is, strong humans don't actually analyze
every variation more deeply than 13 plies anyway, so whatever
advantage a strong human player might have is due to strategic
"intuition" that no practical depth of tactical analysis can
reproduce.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Small block ciphers
Date: Mon, 31 Jul 2000 15:52:15 GMT
Mack wrote:
> Certainly using a block size of 32 or 48 is not very secure for
> modern applications.
That's not certain at all! Using a *key* size that small would
be insufficiently secure, but block size is only slightly coupled
to cryptosystem security, and in fact there are stream ciphers
(in effect, a 1-bit block size!) that are sufficiently secure.
------------------------------
From: Steve Weis <[EMAIL PROTECTED]>
Subject: Re: Software to implement elliptic curves?
Date: Mon, 31 Jul 2000 09:46:05 -0700
Sergio Arrojo wrote:
> Does anybody know where from could I download implementation of elliptic
> curves over GF (2^p) (p prime) in C++. I just want a NO-COMPLICATED software
> to be able to implement different curves without having to deal too much
> with the contents of the program (I am not that much of a genius with C++).
These may be of interest:
Wei Dai's Crypto++
http://www.eskimo.com/~weidai/
Pegwit
http://ds.dial.pipex.com/george.barwood/v8/pegwit.htm
Elliptix (Java)
http://www.cryptix.org/products/elliptix/index.html
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: purpose of final swap in Twofish?
Date: 31 Jul 2000 09:42:51 -0700
In article <[EMAIL PROTECTED]>, Runu Knips <[EMAIL PROTECTED]> wrote:
>I can't find such a thing in neither my own, nor Brian Gladman's
>nor the GnuPG sources, and also not in the paper, so what are
>you talking about ?
It's in GnuPG. Look at the use of the INPACK and OUTUNPACK macros. The
GnuPG implementation never does explicit swaps, but it uses the four words
of the block in different orders in successive rounds. When it packs or
unpacks them into bytes on the ciphertext side, around lines 776 and 794
in GnuPG 1.0.0's twofish.c, it does it in cdab order, so the effect of the
extra/omitted swap is there.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: Mon, 31 Jul 2000 16:45:58 GMT
In article <[EMAIL PROTECTED]>,
Sander Vesik <[EMAIL PROTECTED]> wrote:
<snip>
>
> But of course, there is the whole matter of what is better. If a set
of
> the finalists (any number between 2 and 5) can be shown to be equally
> strong in the face of all known attacks, then surely the one selected
> must be selected based upon other criteria than security?
It currently *appears* as if one very strong non-crypto criterion
is speed and memory requirements on very small devices. This
currently seems to be a major concern.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Math�matics
Date: Mon, 31 Jul 2000 16:48:38 GMT
In article <[EMAIL PROTECTED]>,
Ioshua <[EMAIL PROTECTED]> wrote:
> Does someone know MAPLE V.4 PRO?
Yes.
Someone does.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combining bit sequences
Date: Mon, 31 Jul 2000 19:25:03 +0200
"Douglas A. Gwyn" wrote:
> Mok-Kong Shen wrote:
> > Indeed my post was not very clear and hence misleading. Instead
> > of 'bit' I should have used 'random bit'. The purpose of obtaining
> > nonlinearity is to render the resulting sequence less susceptible to
> > prediction.
>
> If the input bits are random they're already unpredictable.
> So I guess you're asking about methods to take biased bits
> and remove the bias. There is a paper on this in a recent
> (May 2000 I think) issue of IEEE Trans. Inf. Th.
Thanks for the reference to the articles. It is noteworthy
that new research results on improving random bit sequences
continue to come out. Perhaps some large scale experiments
to compare the relative merits of the different approaches
would be very valuable for the practice.
M. K. Shen
------------------------------
From: Steve Weis <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Mon, 31 Jul 2000 10:19:29 -0700
Mike Rosing wrote:
> Steve Weis wrote:
> > In my experience with ECC over GF(p) or GF(2^n), it has slower
> > verfication performance vs. RSA by an order of magnitude. ECC has shown
> ...
> You're using sub-optimal code. While I don't have experience with GF(p),
> my comparisons with RSA are that they are close for the same level of
> security. And I didn't use any of the advanced tricks now available.
Most of the performance comparisons I have seen are a bit dated. RSA's
summer 1998 Cryptobytes contains a direct comparison of RSA-1024,
DSA-1024 and ECDSA-168 over GF(p) showing a strong advantage to RSA in
verification. Obviously, it might be in their interest to hype RSA over
alternative algorithms.
Lenstra & Verheul recently published a paper, available at
www.cryptosavvy.com, which indicates that EC keysizes of about 130-140
would be equivalent to a 1024 bit RSA key. If these smaller keys offer
the same level of security, would their use improve verification
performance to something close to RSA?
Which techniques have you had the most improvement with? It sounds like
you have mainly worked in GF(2^n). Have you seen an advantage over GF(p)
and GF(p^m)? I've focused mostly on improving scalar multiplication and
simultaneous multiplication and have had good results. Point addition
seems to be the biggest bottleneck now.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Mon, 31 Jul 2000 12:12:32 -0500
Terry Ritter wrote:
> Nope: Facts exist independent of belief. Convincing someone is not
> relevant to reality.
And belief exists independent of facts. Convincing people of things
is all there is to "reality". Advertising comes to mind...
> The Russian text is no doubt conveying a typical wry cynicism.
Yeah, pretty necessary for survival anywhere now.
>
> I will believe a mathematical proof, if I can understand it, because I
> will have no choice. There are, however, many supposed "proofs" which
> I do not accept because they are only proofs if one accepts certain
> assumptions which I do not accept.
>
> We are no doubt supposed to believe that our opponents are limited to
> making the same assumptions our side is willing to make.
Like Don said, different assumptions lead to different fields of
mathematics. If there's an assumption you don't like, that's fine.
If I want to assume that 2 parralel lines meet, I'm not doing
Euclidian math anymore, I might be doing Lobechevskian math. That you
don't accept the proofs is consistent with the translated russian words.
What makes math interesting is the ability to relate different fields
with each other. Mapping from one set of assumptions to another makes
life complicated, and keeping track of which assumption is valid where
gets confusing. To me, it makes "proof" even more confusing.
> Well, that's an interesting assertion. But where is your proof?
>
> In reality, you have no idea what math has been discovered. You just
> know that it hasn't been disclosed; that is, that *you* don't know
> about it. Thus, we see a vast chasm between what you actually do
> know, and what you claim to know. That is a serious problem for any
> discussion about cipher strength.
Agreed. There may be a race of creatures only 20 light years away who
are laughing their heads off. They know how to build quantum computers,
and have found algorithms for everything we have that are poly-time.
I also agree that discussing cipher strength is a lot of hand waving.
Even so, we can get a rough idea on what it takes to crack various
PK ciphers here on earth with present technology, and build a certain
level of security which will force our opponents to pay large sums of
money to circumvent.
Spys are always cheaper than hardware, so discussion of cipher strength
is kind of silly anyway. It is still a practical excersise to determine
how much it costs to implement a cipher and how much it *might* cost
an opponent to attack it. When the attack price is over twice the
price of a spy, it should be good enough.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 31 Jul 2000 17:28:44 GMT
Subject: Re: BUGS v3.3.0 - CONTEST
>
>> The contest as it is is basically here is my algorithm and
>> a ciphertext. This really doesn't tell if your algorithm is secure.
>> To be secure, it must be secure against chosen-adaptive
>> plaintext attack. A cipher-text only attack isn't really
>> practical for most ciphers (even bad ones).
>
>Good point.
>What about if I give more information for this contest such as:
>- 2 textfiles crypted with the same password
>- The size of the key
>- The language used in the text file
>
>I think this would be more a "real world" test.
Yes it would be more 'real world'.
The more complete test would to award your
prize to the person with the most complete attack.
Or setting the upper limit for a prize as a method
that will reduce the complexity of attack to say 64
bits with two meg of chosen plaintext.
>
>> That said BUGS appears to be more of an application than
>> just a cipher. I haven't really looked at it just the nature of
>> the contest. The cipher may be useful. The contest is not.
>
>I may change the contest then and give more clues.
>BUGS is actually more of a cryptography algorithm than an application.
>Te applications where supposed to be only there as example. But as many
>people get back to me with applications ideas I created more and more
>applications around. The time spent on the application is only a 1/10 of
>the tim spent on the algorithm, and were not really challenging anyway.
>
>Cheers,
>Sylvain.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: How secure is Pegwit?
Date: Mon, 31 Jul 2000 12:40:26 -0500
Ed Suominen wrote:
> 1. Pegwit uses GF(2^255) elliptic curve encryption. This is a strong
> type of encryption (it does not use 2^m composite curves) that is
> roughly equivalent to the 128 bit symmetric key encryption of PGP. It
> has the advantage of a short (256 bit) key that is not much longer
> than the 160 bit fingerprint of a DH/DSS PGP key.
Actually, 255 = 5*51, so it's subject to Smart's attack. From Paullo's
web page:
Briefly, if m = kd then the elliptic discrete logarithm problem can be solved
in time O(2^(k*(2 + epsilon))) instead of O(2^kd/2).
So d=5, k=51, it's more like 102 bits of security instead of 127. If
d=51 and k=5, it ain't secure :-)
Nothing to complain about in the first case, especailly for free :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 31 Jul 2000 17:45:06 GMT
Subject: Re: Small block ciphers
>
>
>Mack wrote:
>
>> But if we use a 12 bit key we now have 8 equations in
>> 12 variables. This is obviously not soluble with only one
>> ciphertext. If each nonlinear term is a 'variable' we now have
>> 4095 unknowns. This would require at least 512 pairs.
>> Since the maximum is 256 pairs it can't be solved under
>> this assumption.
>
>On what basis can/should one regard each non-linear term as a
>(independent) variable? Further, there can be non-linearity of
>different nature, so that a 'general' treatment of solutions may not
>be practical, I suppose. It seems also to be not clear with your
>'solvability with only one ciphertext'. The opponent is normally
>assumed to have quite a lot more materials to work with.
>
>M. K. Shen
>
>
Who said that each non-linear term could be treated as an
'independent' 'variable'?
A general feistel network with an F that is truly a function
(ie. no state), an always be expressed as some set of
equations for inputs and outputs. These equations will take
the form of high order boolean equations. It is generally not
practical to do this for a cipher such as DES which would
have 2^56 terms.
If a cipher of 8 bits with 12 key bits is expressed as a
set of equations and the cipher is not degenerate with
respect to the key bits, we need 12 equations since we
have 12 variables. One pair only creates 8 equations.
Restated a different way the minimum unicity distance is
1.5.
Finally in the case of a 8 bit cipher the attacker can only
get 256 pairs. That is all that exists so assuming he only
has 1/256 of possible pairs is not that strange.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Joseph Stein)
Subject: Blowfish Implementation
Reply-To: [EMAIL PROTECTED]
Date: Mon, 31 Jul 2000 16:57:16 GMT
Hello, I am tring to create a C++ program to use blowfish to encrypt
and decrypt some text. Either from CString or char. The problem is
all of the algorithims I have downloaded from counterpane.com is for
unsigned long. Please Help... Thank you =)
Joe Stein
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 31 Jul 2000 17:49:09 GMT
Subject: Re: Small block ciphers
>Mack wrote:
>> Certainly using a block size of 32 or 48 is not very secure for
>> modern applications.
>
>That's not certain at all! Using a *key* size that small would
>be insufficiently secure, but block size is only slightly coupled
>to cryptosystem security, and in fact there are stream ciphers
>(in effect, a 1-bit block size!) that are sufficiently secure.
>
>
a 32 bit block size is subject to a dictionary attack fairly quickly.
It is only 4GB. My HD is 5 times that. If I only used one
password in ECB mode it would be readily subject to attack.
48 bits is only 256 times that. Well within the size of a large system.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Corrado Galdini <[EMAIL PROTECTED]>
Subject: Re: PRNG cryptoanalysis
Date: Mon, 31 Jul 2000 17:58:06 GMT
Hello everybody,
I'd like to know if there is any site around dealing with cryptoanalysis
of two common pseudo-random number generators known as "linear
congruential" (maybe the easiest one around) and "linear feedback shift
register" (or LFSR).
I found many sites dealing with related theory and applications but none
dealing with cryptoanalysis. :(
Thank you in advance.
Corrado Galdini
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Mon, 31 Jul 2000 12:55:15 -0500
Steve Weis wrote:
> Lenstra & Verheul recently published a paper, available at
> www.cryptosavvy.com, which indicates that EC keysizes of about 130-140
> would be equivalent to a 1024 bit RSA key. If these smaller keys offer
> the same level of security, would their use improve verification
> performance to something close to RSA?
It goes as n^3, so if you reduce the number of bits from 170 to 130,
you reduce the time from O(170^3) to O(130^3). If the ratio of the
operations reduction gets close, the time will shrink too.
>
> Which techniques have you had the most improvement with? It sounds like
> you have mainly worked in GF(2^n). Have you seen an advantage over GF(p)
> and GF(p^m)? I've focused mostly on improving scalar multiplication and
> simultaneous multiplication and have had good results. Point addition
> seems to be the biggest bottleneck now.
Yes, mostly binary fields. They were more fun. GF(p^m) is good if you
have a modular unit that can do the mod p fast. There's lots of advantages
there, and you might want to look at what Solinas calls "Generalized
Mersenne primes". Also check out the CHES conference in a couple of weeks,
there may be some new papers on exactly this topic.
To do point addition fast, you want inversion to be as fast as multiplication.
This is possible with some GF(2^n) fields. I haven't played with GF(p^m)
for that, I expect it to be pretty messy.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Corrado Galdini <[EMAIL PROTECTED]>
Subject: PRNG cryptoanalysis
Date: Mon, 31 Jul 2000 18:00:31 GMT
Hello everybody,
I'd like to know if there is any site around dealing with cryptoanalysis
of two common pseudo-random number generators known as "linear
congruential" (maybe the easiest one around) and "linear feedback shift
register" (or LFSR).
I found many sites dealing with related theory and applications but none
dealing with cryptoanalysis. :(
Thank you in advance.
Corrado Galdini
------------------------------
** 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
******************************
