Cryptography-Digest Digest #966, Volume #10 Mon, 24 Jan 00 13:13:01 EST
Contents:
Re: Combination of stream and block encryption techniques (John Savard)
Re: from DEAL to ZEAL (Francois Grieu)
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (Richard Herring)
Re: newbie question: symmetric versus asymmetric (Tom St Denis)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Tom St Denis)
Re: How much random needed for random (Scott Nelson)
Re: New Crypto Rules (Eric Lee Green)
Reversibly combining two bytes? (Alan Lawrence)
Re: Transposition over ASCII-coded text (John Myre)
generating "safe primes" (Jonathan Katz)
Re: MIRDEK: more fun with playing cards. (Rex Stewart)
Re: Solution to GCHQ puzzle published (Paul Gover)
Re: UK Government challenge? (Paul Gover)
Re: Twofish question (ciphertext chaining) (Eric Lee Green)
how to break 1timepads with the same pad used N times (Salvatore Sanfilippo)
Re: How much random needed for random (Eric Lee Green)
Re: Codebook URL (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Combination of stream and block encryption techniques
Date: Mon, 24 Jan 2000 13:57:18 GMT
On Sun, 23 Jan 2000 12:36:36 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Yet today, in contrast to ancient times, these shades can be very
>well coded in pixels and black and white are simply two 'special'
>cases (they have difference in pixel value of 255). Why is having a
>more general concept worse than having only two extreme ones in
>science?
Just as the existence of shades of grey is no argument for removing
the words "black" and "white" from the language, I trust you will
admit that stream ciphers and block ciphers do exist.
While shades of grey vary continuously, a cipher is a combination of
discrete steps and procedures. So we don't have a "stream-nature" that
shades imperceptibly into a "block-nature". There certainly are
borderline cases, but these cases are best dealt with by noting the
stream and block components, and their relative importance, within the
cipher.
Whether stream or block encipherment is taking place is a very
important characteristic of a cipher, not an irrelevant or unimportant
one. But other possibilities exist than the extreme cases of ciphers
that are completely of one kind or the other. What makes sense is to
consider the other possibilities: if the distinction, however, becomes
obscured, these possibilities could become less visible.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: from DEAL to ZEAL
Date: Mon, 24 Jan 2000 15:31:31 +0100
In article <86cst9$mr3$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote :
> One property which DEAL has, but ZEAL apparently does not, is symmetry
> of encryption and decryption [and implies] that the security
> against chosen-plaintext and chosen-ciphertext attacks is the same.
Yes, David. Thanks for pointing that issue, which I missed
(worse than that, I failed to properly draw the decryption diagram..)
Also, I was informed that the structure of ZEAL actually is equivalent
or close to that of Matsui's MISTY, which has been shown to be
"one round weaker" than the Feistel construction in certain attacks.
Looks like ZEAL is not as a good idea as DEAL is. Discussion is a
marvelous thing to get quickly rid of bad ideas.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: 24 Jan 2000 15:19:05 GMT
Reply-To: [EMAIL PROTECTED]
In article <869jq2$[EMAIL PROTECTED]>, Guy Macon ([EMAIL PROTECTED])
wrote:
> In article <869h47$8it$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Richard Herring)
>wrote:
> >
> >> No rule is perfect, but "next to the last syllable" comes much
> >> closer than what your foreign friend came up with.
> >
> >As a native speaker of British English, personally I put the stress
> >on the *second* syllable. So does my dictionary.
> Interesting! I am a Los Angeles California native, and we get
> to be the standard for "accent free" American English because
> all of the movies and television shows are made here. ;)
> Clearly, for one or three syllable words both rules act the same.
> For two syllable words and four or more syllable words the rules
> diverge. Do you really say britISH instead of BRITish, highLAND
> instead of HIGHland? InSTALLtion instead of InstaLAtion, and
> therMOnuclear instead of thermoNUclear?
Of course not :-)
I think you've missed the context of the original
discussion, which was about the pronunciation of "omnipotent".
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: newbie question: symmetric versus asymmetric
Date: Mon, 24 Jan 2000 16:03:39 GMT
In article <newscache$3uduof$tmn$[EMAIL PROTECTED]>,
"dee" <[EMAIL PROTECTED]> wrote:
> What essential differences between asymmetric key and symmetric
> key crypto-protocols, including tamper evident hardware, when is
> it neccessary to support revocation of stolen keys?
>
>
Symmetric keys are shared secrets. You can't reveal em.
Asymmetric keys are the result of a one-way function. Your public key
is the computed result of using the private key as an input to the
function. [more or less].
You can't revoke symmetric keys.
You revoke asymmetric keys by signing 'I revoke this key'.
I don't know about the hardware.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Mon, 24 Jan 2000 16:22:08 GMT
In article <86grs9$rh4$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
> > I said that ** IN PRACTICE ** the security of the key only
> > depends on its size. This is because primaility tests will
> > (even probabilistic ones) screen out deliberately constructed
> > p,q which have a large number of prime factors.
>
> Then in practice it does not depend on the size of the resulting
> number, but the size of the primes that make up the number?
> Is that what you are implying? (does the word imply help?)
No it depends on the size of the product.
> > No. For RSA (e.g.) they keysize is fixed. For EC the
> > private keysize is a random variable (with an exponential
> > distribution with mean 1 bit less than the field size)
>
> Why not just set the MSB with an ECC private key? Would that help?
No it wouldn't. You set the msb in RSA to make sure the product is 2b
bits long. This doesn't help [AFAIK] in ecc since they use Discrete
Log over EC fields. You want all of the bits of the exponent to be
random.
> > > The strength of ECC is in the key space being too large to
> > > search and too complex to readily determine the factor,
>
> > What "factor"?
>
> Fine- private key. (Did you read Dr Rosing's book that likened the
> key generation to "point multiplication"?)
The private key in a Discrete Exponenetiation is not a factor. It's an
exponent.
> > Existsing STANDARDS permit the use of a private key selected at
> > random. Note also that if indeed you implement your suggested
scheme,
> > then you have reduced the time to break the key by 1/sqrt(2).
>
> Then the standard needs to sit the MSB. And what is the difference
> between nuclear_strength and nuclear_strength/sqrt(2)? It is
> still nuclear_strength- still strong enough to hide the launch codes
> with. Now if you said sqrt(original_key_size), then I would be
> concerned. Besides, if it secures the key space, it can only
> strengthen the cryptography overall, not weaken it.
He is refering to the pollard-rho attack I believe... [I hope] which
can find the discrete log in sqrt(N) time where N is the size of the
moduli. So if you had a 64 bit exponent I could find it in 2^32 time.
Currently things like sqrt(2^161) are far out of reach.
[actually is it sqrt(N-1)?]
> > > > Further, if it can be guessed that the private key lies in
> > > > a restricted range,...
>
> > > ...then there is something wrong,
>
> > Why? Cryptographers worry all the time about partial key revelation.
>
> But that has nothing to do with the cipher, but with key leakage,
> and entirely different aspect of security. Sure it can be used
> against ECC far more than RSA, but it has nothing to do with either.
Every time you leak a bit of the key you make it easier to attack.
Actually you make it 1/sqrt(2) time faster. Every time you take a bit
off the key you make the range twice as small.
By comparaison
sqrt(2^80)/sqrt(2) = 2^39.5, which means if you took a single bit off a
80 bit exponent you are reduced to 2^39.5 instead of 2^40.
> > > but what ever it is that is wrong has nothing to do with ECC...
>
> > WRONG. With ECC this information is very useful in attacking the
key.
> > With RSA is is not (unless you reveal TOO MUCH)
>
> No, I am right. Key leakage is only a problem "with" ECC if the
> ECC public key can give hints away about portions of the private key.
> Otherwise, key leakage is only a problem "FOR" ECC for the reasons
> you state above. To date, I have not heard anything of the former.
> Have you? I agree with the latter, however. But again, it is
> symptomatic of a problem unrelated to ECC being deployed.
Again you are wrong here. The system works like this.
y = g^x mod p
If you reveal bits of 'x' then you can solve faster.
Where as
n = pq
e = prime
de = 1 mod phi(pq)
Revealing bits of 'd' will not let you find it any faster then
factoring. Unless you cross the threshold and reveal enough bits that
brute force becomes faster then factoring.
> > > Given an elliptic curve of 500 bits and an RSA key of 500 bits,
> > > if you expose half the bits, which key is likely to be cracked in
> > > our life time?
> >
> > May I suggest that
> > you go read the literature on this subject? Especially in terms
> > of what can be done and what has been done?
>
> 500 to 500 was a bit odd, but I thought you were heading along
> that line with 20 bits exposed from RSA with 20 bits exposed from
> ECC. I thought you ment to compare 4 oz apple to 4 oz orange.
>
> And, pray tell, how will I know I have reached enough knowledge
> to begin posting here again? Will you tell me? Of course not.
I think you should just realize that attacking RSA is allot different
then any DLP. Given the pollard-rho attack is the only [?] method to
attack ECC...
BTW If anyone has papers on the pollard-rho method I would love to see
em!!! I want to know how it works.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: How much random needed for random
Reply-To: [EMAIL PROTECTED]
Date: Mon, 24 Jan 2000 17:08:14 GMT
On Sun, 23 Jan 2000 11:59:15 +0200, "Yoni M." <[EMAIL PROTECTED]> wrote:
>I'm using SecureRandom (java) in my SSL implementation to produce the
>random bytes needed for the challanges. My problem is performance, it
>takes too long to generate the bytes. If I'm using a simple Random
>everything is much faster.
If your problem is performance, then you should consider
a language built for performance, rather than compatibility.
Java is nice for some things, but this isn't one of them.
>Can I initialize the secure random with the current time (long), or
>isn't it enough ?
No, it's not enough. If you want to build a secure rng,
then read the Yarrow page http://www.counterpane.com/yarrow.html
It discusses this, and many other pitfalls.
>This way is much faster than initializing the
>SecureRandom without any seed.
Faster yes, but not secure.
>Does anyone knows of a short cut or suggestion how to improve the
>performance without reducing security ?
>
Not in Java.
Normally, you can speed initialization by keeping a pool
of entropy handy which is then hashed for use. That implies
the ability to write files, which is counter to the Java
philosophy. (and introduces another whole host of problems.)
For your app, this would probably need to be a separate program.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: New Crypto Rules
Date: Mon, 24 Jan 2000 10:07:26 -0700
"SCOTT19U.ZIP_GUY" wrote:
> Could someone be nice enough to state Plainly. What is the minimun
> one needs to do to leaglly do to put ones own free source code to ones
> encryption software out on the net for others to download. Please don't
> say look at the BXA rules. THey are of no help to those of use in the game
> for fun. I do not wish to make a profit. I just want the minum hassle of
> putting my source code on the net for FREE.
Verbatim from the BXA rules:
(e) Unrestricted encryption source code.
(1) Encryption source code controlled under 5D002 which would be considered
publically available under section 734.3(b)(3) and which is not subject to an
express agreement for the payment of a licensing fee or royalty for commercial
production or sale of any product developed with the source code, is released
from "EI" controls and may be exported or re-exported without review under
license Exception TSU, provided you have submitted written notification to BXA
of the Internet location (e.g. URL or Internet address) or a copy of the
source code by the time of export.
It goes on to cite another section of the CFR as having the valid contact
information, which gives the following EMAIL address as a valid method of
submitting written notification to the BXA:
[EMAIL PROTECTED]
My take on it: If you release your source code under an Open Source license
(see http://www.opensource.org ), your source code falls under the above BXA
rules. However, note that my signature file says "Software Engineer", not
"Lawyer" or "Attorney". I have, however, taken personal steps to test the
above. See http://twofish-py.sourceforge.net for what I mean.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Alan Lawrence <[EMAIL PROTECTED]>
Subject: Reversibly combining two bytes?
Date: Mon, 24 Jan 2000 17:09:32 +0000
Hi -
I'm having a go at writing some simple encryption software myself and
wonder if anyone has any ideas...system works by combining the plaintext
byte with other bytes, derived from the key, by some of the following
methods:
*add modulo 256
*exclusive or
*multiply modulo 257 - a value of 256 (in modulo 257) is encoded as a
zero. Since 257 is prime, a value of 0 (modulo 257) is never created.
* ????
my problem is that I want a fourth method! It has to be reversible (so if
cipher = plaintext $ xxx, then given cipher and xxx it must be possible to
get back the plaintext value), and it has to take two arguments 0..255 and
return a result also in range 0..255. I have tried division modulo 257,
but that's just the same as multiplying by the reciprocal. I tried
carry-less multiplication (i.e. rather than the conventional shift-add, I
did a shift-XOR) and this did indeed produce unique results in the range
0..65535, but I was unable to store these in 8 bits without producing
duplicates.
Any suggestions much appreciated!
Thanks very much
Alan Lawrence
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Transposition over ASCII-coded text
Date: Mon, 24 Jan 2000 10:17:28 -0700
wtshaw wrote:
>... Messages can be input in a less redundant form, as in using telegraphic
> abreviations. The skill in reading such things is easily learned, as is
> that for writing it.
>
> Interestingly enough, many of those in crypto are already well schooled in
> doing this, almost a complete list of chronic and serious posters in this
> group. ...
Oh, I don't know.
*Some* posters can be quite redundant.
Or did you mean the posters who are both chronic and serious,
not both the serious posters and the chronic posters?
;)
John M.
------------------------------
From: Jonathan Katz <[EMAIL PROTECTED]>
Subject: generating "safe primes"
Date: Mon, 24 Jan 2000 12:26:41 -0500
What are currently used algorithms for generating "safe primes" (numbers
of the form p = 2q + 1 such that p is prime and q is prime)?
Do they just test for primality of q, then calculate p = 2q + 1, and then
test primality of p, or something more efficient...?
======================
Jonathan Katz
[EMAIL PROTECTED]
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Mon, 24 Jan 2000 17:22:27 GMT
Reply to Paul Crowley:
As for your flatmates, how long did it take them to learn it? When I
said 15 hour, I meant to become reliable enough
to get through a short message with only a mistake or two. The
computer program able to guess at mistakes would be a great idea, as
one end of the channel would almost always have access to a computer.
Of course it would take a fair amount of effort to code up ALL of the
possible places a mistake could have been made - and a fair amount of
processing power to recover if there were two or three mistakes in
short order.
>> adding of entropy from the right hand deck should provide
>> enough confusion (it adds 3.5 bits entropy each round, the
>> plain text adds 1.3 bits) to preclude recovery of significant
>> state information in the case of a known plaintext attack
What this means is each time a count cut is performed, it could have
one of 26 possible outcomes. This is entropy (it should have read 4.6
bits though since 25 is 2 raised to the 4.6 power). Each time a normal
plaintext character is encoded, it could have one of several outcomes.
Text is much more predictable than the random IV however, and I have
been told on average it amounts to one out of two or three
possibilities.
> even if you know the next plaintext character
> every ciphertext character is equally probable.
This is what I meant by resistant to known plaintext attack.
> If you knew the state of the left pile and the plaintext,
> you'd be able to infer each right hand character as it
> came up, and so you'd have more information about
> each subsequent character until the last one was
> determined with certainty as the one that hadn't
> come up yet.
The key here is you have to know BOTH the state of the left pile and
the plaintext.
>> (I am not so sure about a chosen plaintext attack).
> I strongly suspect that a chosen plaintext attack would choose the
> plaintext "AAAAA...." since that makes least use of the state of the
> left deck.
> Oh bugger. If you guess where this letter appears in the left pile,
> then you can infer the state of the right deck within 25 characters,
> and thus get the state of both decks in 50. If you're using Mirdek -
> don't encrypt the sequence "A" x 50 :-)
I don't think this is the case - as you say IF you guess where this
letter appears in the left pile. And do it 25 straight times.
> Redesign time, I think.
I don't think so. Prove the flaw exists first - it may not.
As I said in another post, the only way I can see to crack this is to
recover the state of the RIGHT deck by encrypting 25 separate texts
differing by only a single letter always occuring in the same position
- and then 25 more with the positions incremented. And encrypting
those 25 separate texts with the same key and the same IV. And then
repeating the ENTIRE process again at a different point in the text to
recover the other deck after the switch. I can see no way to recover
the left deck directly. While you would develope a substitution table
for the left deck I do not think that is the same. You would only be
able to tell something about the rotations induced on the left deck by
the right deck.
>> The 26 mixing steps themselves seemed at first to be
>> aimed at insulating the key from the state information,
>> but because the IV is sent in the clear this is not the case
>> and in fact Paul Crowley, the author, clearly warns it is not
>> the case. These steps appear aimed at using the key
>> information to hide the IV.
> These steps are meant to ensure that both decks depend
> strongly on the key, if that's what you mean.
Well it is more complicated than that. During the keying operation the
first deck becomes dependent on both the key and the IV. But the
second deck is left unchanged. Then you switch decks and mix the IV 26
times with the first deck. Awsome. The IV is permutated 26 times by
the first deck. If the IV were also secret, you could not work
backwards through this, but that is not the point - you did exactly
what you set out to do (although I still think 26 times is overkill).
I think I have reached the point where I am beginning to ramble.
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Gover <[EMAIL PROTECTED]>
Subject: Re: Solution to GCHQ puzzle published
Date: Mon, 24 Jan 2000 10:43:16 +0000
Jerry Ennis wrote:
> ...
> The Sunday Times solved the puzzle and has published its solution at
> http://www.the-times.co.uk/news/pages/Times/frontpage.html?999
As it's no longer Sunday, you get the current day's news, and have
to search for the correct edition.. I think a better URL which might
not change is
http://www.the-times.co.uk/news/pages/Sunday-Times/stinwenws02005.html?999
Trust them to spoil the chase.
Paul Gover
------------------------------
From: Paul Gover <[EMAIL PROTECTED]>
Subject: Re: UK Government challenge?
Date: Mon, 24 Jan 2000 10:26:47 +0000
Angus Walker wrote:
> ...
> Couldn't be bothered or couldn't find it? I'm up to four now too
> (thanks to being told the fourth one!) Is it the one that probably
> says ONE!N that you have left?
Nope, we found that (;-), but not the first 1.25 words in the statement.
(I'm not going to give it away here, but it sounds like a C programmer's
first greeting :-)
As I said, the Australian site has cryptographically more interesting
challenges at
http://www.dsd.gov.au/
They took me about a week of spare time (but I'm a complete amateur).
Cheers, Paul Gover.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Twofish question (ciphertext chaining)
Date: Mon, 24 Jan 2000 10:33:22 -0700
David Wagner wrote:
>
> Four comments on your post:
>
> 1. The questions you're asking have nothing to do with Twofish and
> everything to do with chaining modes. They'll apply equally to any other
> block cipher.
>
> 2. You should distinguish between 8-bit CFB mode and 128-bit CFB mode.
> They're different. You seem to be using 8-bit CFB mode.
I think he is using the definition on page 209 of "Applied Cryptography",
which defines an 8-bit stream cipher feedback mode. This mode works as
follows: A shift register (same size as the input block to cipher) is
initialized with a unique initialization vector, which is also sent to the
recipient. This value is then encrypted using the shared symetric key K. The
left-most byte of the encrypted data is XOR'ed with the byte of input data.
This byte of XOR'ed input data is then sent to the recipient and shifted into
the shift register as its first byte (with all other bytes being shifted
downward until the last one "falls off the end").
For the next input byte to be encrypted, the shift register is again encrypted
via the cipher, the first byte of the result XOR'ed with the input stream,
etc.
This process has one full 128-bit encryption for each input byte. I believe
his question is this: Would it be cryptographically secure to perform one full
128-bit encryption for every 16 bytes? I.e., instead of restricting to the low
byte of the encrypted value, use each byte of the encrypted value in turn to
XOR with bytes of the input stream?
The output XOR'ed bytes would still be shifted into the shift register, but
the shift register would only be encrypted after 16 bytes had been shifted
into it.
If this is 128-bit CFB mode, that probably answers his question about whether
it is secure or not. My own analysis is that it would be as secure as the
other way, since the whole point of the symmetric cipher in this case is to
produce an unpredictable XOR mask and presumably all bytes of a symmetric
cipher's output are unpredictable if you don't know the key (if not, it would
be succeptible to known plaintext attacks, right?).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Salvatore Sanfilippo <[EMAIL PROTECTED]>
Subject: how to break 1timepads with the same pad used N times
Date: Mon, 24 Jan 2000 16:16:07 GMT
Can anyone give me some pointer about breaking one time pad
if the same pad is used more then for 1 message?
In other words: how can I obtain Plain1 and Plain2 if I have
Plain1 xor Plain2 (assuming Plain1 and Plain2 english text)?
thx
antirez
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: How much random needed for random
Date: Mon, 24 Jan 2000 10:48:41 -0700
[EMAIL PROTECTED] wrote:
> > I'm using SecureRandom (java) in my SSL implementation to produce the
> > random bytes needed for the challanges. My problem is performance, it
> > takes too long to generate the bytes. If I'm using a simple Random
> > everything is much faster.
> > Can I initialize the secure random with the current time (long), or
> > isn't it enough ? This way is much faster than initializing the
> > SecureRandom without any seed.
> > Does anyone knows of a short cut or suggestion how to improve the
> > performance without reducing security ?
>
> The current time (long) only contains a few bits of entropy
> (unguessable or unpredicatable) information. You need to obtain a
> better source of true random data for your seed.
>
> As for the PRNG, Java's SecureRandom uses SHA-1 as the basis for it's
> PRNG, so it seems ok. The normal Random function is only designed to be
> statistically random, but not designed to protect the seed; I wouldn't
> touch it with a 10 foot poll.
I agree that the normal Random function is not going to produce unpredictable
results, and thus is not appropriate. Furthermore, seeding it with the output
of time() is not appropriate either, since that's basically setting the PRNG
with a single byte (the low byte of the time() value, nothing else changes
during the lifetime of the PRNG).
MD5 is a bit faster than SHA-1, at the expense of being less secure. You may
wish to investigate the Yarrow paper at http://www.counterpane.com and see if
perhaps something similar to the Yarrow design, but using MD5 and a fast
symmetric cipher such as TwoFish, would be more appropriate. If you are using
Linux or FreeBSD you can also get pseudo-random numbers sufficiently strong
for challenges by reading bytes from /dev/urandom. These will typically
contain far more entropy (true unpredictability) than user-space PRNG's, since
they have access to internal interrupt timings and other entropic events not
accessible from user space. They have the plus of also being faster than most
user-space implementations, since they are based on MD5 rather than SHA1.
A thought: If your class heirarchy is set up right, you should never need to
re-seed SecureRandom during the course of your program's execution. If your
program is constantly being stopped and then restarted you will have
performance problems regardless, just as you will if you must continually be
re-seeding the PRNG.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Codebook URL
Date: Mon, 24 Jan 2000 10:57:53 GMT
[EMAIL PROTECTED] (Mike Andrews) wrote, in part:
>I'm in the process of scanning in and making available a WW-II
>US Army training codebook. The URL is
> "http://mikea.ath.cx/codebook".
>It's incomplete, but I get a bit farther into the stack of
>pages every day.
Thank you for putting some more pages on the site today. I find the
site interesting and enjoyable.
There's something on one of the HTML pages that indicates you're
considering typing all this stuff into text form yourself. I think
you've already done enough for the benefit of the world...
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
