Cryptography-Digest Digest #568, Volume #12 Tue, 29 Aug 00 21:13:00 EDT
Contents:
Re: Idea for creating primes ([EMAIL PROTECTED])
Re: 4096 BIT RSA Key ([EMAIL PROTECTED])
Re: RSA n-bit key...is p and q n or is the mod n? (Gregory G Rose)
Re: Idea for creating primes ("Big Boy Barry")
Re: R: R: R: Test on pseudorandom number generator. ("Douglas A. Gwyn")
Re: 320-bit Block Cipher (Gregory G Rose)
Secure Deletion of Data ("Jeffrey Walton")
Re: Serious PGP v5 & v6 bug! (Bj�rn Persson)
Re: A little technical note about intepreters ("Douglas A. Gwyn")
Re: Idea for creating primes ([EMAIL PROTECTED])
Re: A little technical note about intepreters (Andrew Carol)
Re: e-cash protocol concept, comments wanted (Julian Morrison)
Re: e-cash protocol concept, comments wanted (Julian Morrison)
Re: Serious PGP v5 & v6 bug! (Shawn Willden)
Re: Optimal length of the sieve before a Miller-Rabin test (Bryan Olson)
Re: 4096 BIT RSA Key (No User)
Schneier's RC 2-Cracking Screen Saver (Champerty)
Re: 4096 BIT RSA Key ([EMAIL PROTECTED])
Re: 4096 BIT RSA Key (Steve)
Re: R: R: R: Test on pseudorandom number generator. (Terry Ritter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Idea for creating primes
Date: Tue, 29 Aug 2000 21:59:25 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > [snip]
> > > > You can test to see if a number is a genrerator by performing g^
> > (p/q) !
> > > > = 1 for various 'q's that divide your testing prime 'p'.
> > > [snip]
> > >
> > > I suspect there is a printing error here. If one knows that
> > > there is a q that divides p, then p is certainly not a prime,
> > > isn't it? Or how should one properly interpret that phrase
> > > above? Thanks.
> >
> > Simple typo.
> >
> > You have your list of smaller primes N1, N2, N3 ...
> >
> > then you have the value p' = 2*N1*N2*N3*N4*...
> >
> > Then you have the value p = p' + 1
> >
> > Sorry for the confusion. You are looking for a value q that divides
> > the value p'
>
> Questions:
>
> (1) Your g is such that (g,p)=1 and g^p' = 1 and g^s != 1
> for all s equal to p' divided by one of its factors?
> Is that right?
Yea, you want to make sure that g doesn't belong to a sub-group.
> (2) How much do the tests g^s != 1 help in practice (in
> comparison to omitting these but retaining the other
> conditions) for the purpose of finding primes?
Once you find one g that doesn't belong to any subgroups you know that
p is prime.
> (3) Could some of the factors of p' be equal or must they
> be distinct? (In the latter case why?)
They need only be known, and they must be prime for this to be provably
exact.
> (4) What is the rationale of having the N's of the same
> magnitude (the same number of bits)?
It makes finding real primes easier. All theprime factors of p' must
in fact be provably prime for this whole scheme to work. It's easier
to find a whole bunch of provable primes if they are smaller.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 4096 BIT RSA Key
Date: Tue, 29 Aug 2000 22:00:07 GMT
In article <[EMAIL PROTECTED]>,
No User <[EMAIL PROTECTED]> wrote:
> How can I make a 4096 bit RSA Key for use in PGP 6.5.8? I tried
generating one
> using the Cybernights Templar 2.6.3 version. But when I import the
key into
> 6.5.8. It says the key is invalid.
Why on earth are you making RSA keys that big?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: RSA n-bit key...is p and q n or is the mod n?
Date: 29 Aug 2000 15:17:18 -0700
In article <[EMAIL PROTECTED]>,
John Matzen <jmatzen(at)origin(d0t)ea(d0t)com> wrote:
>When one speaks of a 512-bit RSA key, are p and q 512-bits, or is the
>modulus 512-bits (meaning p and q are 256 bits)?
The size of the modulus is what is being referred
to.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
From: "Big Boy Barry" <[EMAIL PROTECTED]>
Subject: Re: Idea for creating primes
Date: Tue, 29 Aug 2000 22:17:56 GMT
did you patent this?
<[EMAIL PROTECTED]> wrote in message news:8ogq3t$l9f$[EMAIL PROTECTED]...
> Say you want to make an 'n' bit prime that is some multiple of 128 (I
> chose this out of my head). What you do is make n/128 128-bit primes
> as described below then multiply them all together (and multiply by
> two) then add one. Next using all the known prime factors try to find
> a primitive generator. If you can find one then you know for a fact
> that the number is prime, iff the 128-bit primes are in fact prime.
>
> You can test to see if a number is a genrerator by performing g^(p/q) !
> = 1 for various 'q's that divide your testing prime 'p'.
>
> To make the 128-bit primes you can use a sieve of divisors, then 8
> Fermats tests and finally five MR tests. I find that no composites
> ever get passed both the sieve and fermat tests, but the MR tests are a
> bit more exacting.
>
> So once you have the product 'p = p' + 1' where p' is the product of
> the smaller primes and you have 'g' a primitive generator modulo p, you
> now have a prime 'p'.
>
> Since the smaller primes must be prime for this to work, we can recurse
> a bit and factor those 128-bit primes and try to find a multiplicative
> primitive.
>
> One problem is that the first multiplicative primitive may be a big
> number. So we can resolve this by testing 2..1000 (or any suitable
> pattern).
>
> This method is exacting (assuming the smaller primes are primes) giving
> what are provable primes. I don't know if it's any faster since it
> requires you to first find a suitable number of pseudo primes, then to
> factor one less then them, then to find a multiplicative generator in
> all the various fields.
>
> Just an idea :)
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: R: R: R: Test on pseudorandom number generator.
Date: Tue, 29 Aug 2000 21:22:12 GMT
Cristiano wrote:
> In this case the test is efficient?
No, because millions of observations have been summarized
into just a few test values (# collisions). However,
given the choice to use 40-bit data there isn't much else
you could have done.
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: 320-bit Block Cipher
Date: 29 Aug 2000 15:23:29 -0700
In article <[EMAIL PROTECTED]>,
Zulfikar Ramzan <[EMAIL PROTECTED]> wrote:
>> >
>> >See also ShaZam (FSE'99, Sundaram and Patel IIRC).
>
>Actually the paper is by Patel, _Ramzan_, and Sundaram. ;)
Please accept my apologies, Zulfikar... I was away
from my books and (normal) computers. I intended
no slight.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Secure Deletion of Data
Date: Tue, 29 Aug 2000 18:39:27 -0400
I thought this page mught have something on CDs (re: Destruction of CDs
message thread). Interesting reading, with references.
http://nondot.org/sabre/os/H3Disks/SecureDeletion.html
------------------------------
From: [EMAIL PROTECTED] (Bj�rn Persson)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Tue, 29 Aug 2000 22:44:22 GMT
Phil Harrison <[EMAIL PROTECTED]> wrote:
>As far as I can see, the system you are suggesting would allow an
>unscrupulous member of the IT department (with access to the keys and
>passphrases) the ability to sign documents in the name of other
>employees. The ADK system does not permit this, but still allows
>decryption.
With RSA keys, a key that can be used to decrypt can also be used to
sign, yes. With the so-called "DH/DSS" keys there is one signing key and
one (or more) decryption keys, so it would be possible to extract the
decryption key and send it alone to the key central. (Not that I
recommend doing so.)
Bj�rn Persson
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: A little technical note about intepreters
Date: Tue, 29 Aug 2000 21:45:59 GMT
Andrew Carol wrote:
> Comments are a good thing.
Only when used appropriately.
To be useful, a comment must be present, informative,
and accurate.
Kernighan & Plauger had something to say about this
in "Elements of Programming Style".
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Idea for creating primes
Date: Tue, 29 Aug 2000 22:47:20 GMT
In article <oEWq5.218345$[EMAIL PROTECTED]>,
"Big Boy Barry" <[EMAIL PROTECTED]> wrote:
> did you patent this?
No, why would I do that?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andrew Carol <[EMAIL PROTECTED]>
Subject: Re: A little technical note about intepreters
Date: Tue, 29 Aug 2000 16:01:46 -0700
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn
<[EMAIL PROTECTED]> wrote:
> Andrew Carol wrote:
> > Comments are a good thing.
>
> Only when used appropriately.
> To be useful, a comment must be present, informative,
> and accurate.
> Kernighan & Plauger had something to say about this
> in "Elements of Programming Style".
No argument there.
------------------------------
From: Julian Morrison <[EMAIL PROTECTED]>
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: Wed, 30 Aug 2000 00:11:28 +0100
Ragni Ryvold Arnesen wrote:
> But then you will need to contact the bank quite often to exchange all the
> small coins you get, and the bank in turn has to contact the originating bank
> of each coin for settlement. The system seems to depend on a lot of
> transactions involving small amounts of money. That is what generates high
> costs.
It's likely though that specialized companies could set up to handle change
specifically, basically an anonymous bounce of old coins plus instruction in, new
coins out, with the company making its money off investment. Incidentally, such
companies would also fog the trail for any IRS snoops.
> > Also, transaction costs would be offset by the
> > opportunity to invest the money until the coins are redeemed into some
> > other bank account.
>
> This opportunity is present for many e-cash systems.
Fair enough
> Sorry if I seem too negative, but I really don't think that coin based systems
> are the way to go. The handling of change and keeping track of individual
> coins just seems too messy.
The trouble is that the alternatives are basically:
(a) virtual wallet. one number, user carries it but can only add/subtract in some
legitimate way. Hard to do safely, since hacking into the magic number inside the
wallet would be a blank check.
(b) virtual debit card. Banks can't invest the money since it's moved instantly
on use, transfers are not even slightly anonymous.
Coins are the only way to generate a currency that can basically be used
independant of a personal bank account, in total secrecy if the users wish.
------------------------------
From: Julian Morrison <[EMAIL PROTECTED]>
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: Wed, 30 Aug 2000 00:13:21 +0100
Eric Murray wrote:
> You don't make it clear, but I'm guessing from the context that the
> 'transaction recipt' is a use count, signed by the bank.
Yup, the term is actually a holdover from an earlier design phase where each coin
would carry an ever-growing trail of individual reciepts, which could be counted -
but I morphed it into meaning a single signed use count.
> Also, does the
> originating bank keep a copy of the coin and check the hash against that,
> or does it only keep the hash and associated use count, and check coins
> against the hash? I'm guessing the latter.
There wouldn't be much actual difference in size, I think, since a coin is just
sign[bank]("I promise to transfer to the bearer the sum of $n"). A hash big enough
not to collide would be pretty much the same size.
Note that because of "Fling", a bank could see a coin being validated and reply
without knowing the identity of the current holder - the most they could know is
the identity of the person who withdrew it originally. Maybe there might be a way
of eliminating even this, but I can't think of any yet.
> [...]
> However, this scheme isn't fully anonymous- it requires that
> you trust the banks not to collude. If Alice is spending a coin
> with Bob and Bob's bank wants to know who he is buying things from,
> it could collude with the other banks to look for coins with the same
> hash value. Since there should only be one that matches, it's
> easy to for the banks to track transactions if they wish.
>
You forget: coins can be used many times *as coins* without ever touching a bank
except for the incrementing of transaction reciepts - a function which would also
be anonymized by the "Fling" system. Banks could theoretically connive to see
where each coin started and ended up - but a batch of 100 various-valued coins
withdrawn from one bank, could "wash ashore" again separately in 100 different
accounts..This also not counting any number of non-collaborating anonymous "change
servers" (described by me in another message in this thread).
It would be a good idea to separate coin validation ("this coin has a hash of foo
and a count of bar" "it's good") from count increment ("here is a signed count"
"here is an incremented one back"). Since signed counts are just a signed number,
banks can't necessarily tell one from another - or even if they keep a record,
they'd have to be prepared to store and collate all the digits of every signature,
a costly undertaking.
> >Are there major improvements you could suggest?
>
> Redesign so that contacting the bank when receiving a coin is not required.
Have you any particular means in mind to do this?
------------------------------
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 29 Aug 2000 17:43:19 -0600
"Nathan Williams" <[EMAIL PROTECTED]> writes:
> Not quite. In my version of the "perfect PGP plan" the end-users
> would create their own keys using a "client" version of PGP. This
> client version of PGP would create the keypair and automatically send
> the keypair and passphrase via e-mail (or ftp, or even floppy) to a
> holding server and that e-mail would be encrypted with a designated
> management key for that purposed use only. No one would see the keys
> or passphrase with out decrypting the e-mail and that management key
> could be SPLIT in order to protect the e-mailed keys from prying
> eyes. Only when you need to access someone's e-mail would you rejoin
> the split keys and then get a copy of the keypair and passphrase.
> I am not a mathematician so I don't know how risky it is to split a
> key. I don't know if that weakens the key or strengthens it. Also
> shipping a full keypair with the passphrase might raise a few
> eyebrows but I figure if we have trust in the encryption methods to
> protect other secrets we can trust it for this.
> I invite comments. But I think this method of handling keys while
> not perfect allows for key management/escrow without the weakness
> that a ADK puts on every message.
No, this solution is far worse than the ADK solution. This solution
gives someone else control of your private key, meaning they can
impersonate you. This scenario allows a tie-dyed, sockless,
ponytailed, late-to-work-every-day geek who hasn't been fired yet only
because HR isn't sure they could find a replacement in this
unbelievably tight technical-labor market to impersonate the CEO; not
a good idea.
[Nothing against tie-dye, ponytails, Tevas or going to work late, BTW;
I fit that profile whenever possible.]
Really, there is no weakness created by an ADK in a proper
implementation. The only "badness" about ADKs in general is that they
create yet another opportunity for making mistakes. But then *any*
key escrow solution creates another opportunity for error. IMO, ADKs
are a reasonable solution, as long as they are properly authenticated
(part of the signed public key package).
Shawn.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Optimal length of the sieve before a Miller-Rabin test
Date: Tue, 29 Aug 2000 23:42:15 GMT
Pedro F�lix wrote:
> On the context of primality testing it is usual to precede
> a probabilistic test, such as the Miller-Rabin, with the
> divisibility test of the candidate by all the primes lower
> than a bound B. My question is how to obtain the
> optimal value of B.
[...]
> Any other thoughts on this topic are welcomed
I've done tests generating crypto-size primes on various
systems and the major finding was that any B within an order
of magnitude or two from the optimal performs almost the
same. Most of the benefit from the sieving comes from the
first few primes. On the other hand the sieving time is a
small part of the overall run time until one tests against
outrageously many. Let B be a few hundred to a few hundred
thousand and the difference from the optimal will be lost in
the noise.
Many sources say to use direct trial division. Actual
sieving is better. If we are going to search for a prime in
N, N+2, N+4..., we can do the long divides to find and store
N mod p1, N mod p2 and so on. We can then test N+i for
divisibility by our small primes with only single precision
operations. Again the improvement is small compared to the
overall run time, so it may not be worth any inconvenience.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 29 Aug 2000 17:50:50 -0500
From: No User <[EMAIL PROTECTED]>
Subject: Re: 4096 BIT RSA Key
>Why on earth are you making RSA keys that big?
I just thought if I could do it, why not? I take it you think
it's not necessary?
---
This message did not originate from the Sender address above.
It was posted with the use of anonymizing software at
http://anon.xg.nu
---
------------------------------
From: Champerty <[EMAIL PROTECTED]>
Subject: Schneier's RC 2-Cracking Screen Saver
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 Aug 2000 20:17:47 -0400
I would like to install Bruce Schneier's screen saver (available here
http://www.counterpane.com/smime.html ).
But first I need a message to decrypt!
Would some kind soul post a short S/MIME message encrypted with 40-bit
RC 2?
Thanks!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 4096 BIT RSA Key
Date: Wed, 30 Aug 2000 00:20:25 GMT
In article <[EMAIL PROTECTED]>,
No User <[EMAIL PROTECTED]> wrote:
> >Why on earth are you making RSA keys that big?
>
> I just thought if I could do it, why not? I take it you think
> it's not necessary?
Obviously three reasons:
1. Slows down all operations involving your key
2. Takes up too much space in messages that involve your key
3. obviously doesn't work with versions of PGP
[4. Shows you have no clue about cryptography.]
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Steve)
Subject: Re: 4096 BIT RSA Key
Date: Wed, 30 Aug 2000 00:57:31 GMT
=====BEGIN PGP SIGNED MESSAGE=====
On Wed, 30 Aug 2000 00:20:25 GMT, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> No User <[EMAIL PROTECTED]> wrote:
>> >Why on earth are you making RSA keys that big?
>>
>> I just thought if I could do it, why not? I take it you think
>> it's not necessary?
>
>Obviously three reasons:
>
>1. Slows down all operations involving your key
>2. Takes up too much space in messages that involve your key
>3. obviously doesn't work with versions of PGP
>
>[4. Shows you have no clue about cryptography.]
Up the the point where they become totally absurd, larger key sizes
are better. I am presently using 2048 bit RSA, which is about 1.79 x
10^308 times stronger than any sane cryptographer would require...
today. Why? Because I figure the performance hits are small enough
that the redundancy is "free of charge".
On the other hand, I don't mind using a cryptosystem that uses 768
bit asymmetrical keys, either... that's plenty, to assure that it's
cheaper to send the van around and steal your key, than breaking it
computationally. And that's the real mission of PC basd crypto.
:o)
Steve
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: PGP ADK BUG FIX: Upgrade to Ver 6.5.8 at MIT or PGP INT'L
iQEVAwUBOaxbxMXTOLlJEtXlAQFB1QgAuOkM3XF0Ru+f969LfE9rtScgOmda//dP
4c5e6fvV8AKhWXncsFVACChaXWLynKoUwpFdqf2FEh8SM98WPE8n7VxfO9z+eRs7
Z8UKB2dopDMjGO6+3nuPzPsg8BBoMqyZt9REB5QIW8xITShIjG3tiokYwM+g1YOQ
CCTeh22ZHsnBHvmL7xkwQ9XdANkrZnSVPHucS+Df7f0kNQYF0088IgdX69n9obwT
L9lfyo31x0nCgzdWqLihwcI4BtE26135NtlPElVquI7eEKMOeHFg/1IQgZWwrObg
uhPGgl/ez47meaKIXl2kyFUXB9NxWAX6OmTS05Nv4I0BNNrnXCWduw==
=Yv6G
=====END PGP SIGNATURE=====
---Support privacy and freedom of speech with---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
My current keys are
RSA - 0x4912D5E5
DH/DSS - 0xBFCE18A9
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: R: R: R: Test on pseudorandom number generator.
Date: Wed, 30 Aug 2000 01:00:01 GMT
On Tue, 29 Aug 2000 21:29:52 +0200, in <8oh1jp$p2g$[EMAIL PROTECTED]>,
in sci.crypt "Cristiano" <[EMAIL PROTECTED]> wrote:
>> >Only when I apply my test to PRNG I need to consider only the 8 msb, but
>> >when I run FIPS PUB 140-2, Maurer and Diehard I take the whole integer as
>is
>> >without any modification.
>>
>> Taking 5 chunks of 8-bits each is not the same as taking a single
>> 40-bit value from an RNG.
>
>I completely agree with you. But if I only need 8 bits what do you suggest?
1. If you are taking 8-bit values from larger state, use tests which
are appropriate for 8-bit values. If you are taking bits, use tests
which are appropriate for bits. One such test would be "runs up /
runs down." See Knuth II and:
http://www.io.com/~ritter/ARTS/RUNSUP.HTM
2. Use 8-bit values as the most-significant-byte only of 32-bit
quantities, with three zero lower bytes.
>> >> Similarly, Diehard expects to see 32-bit integers, not 40 (unless it
>> >> has been modified). If we expect tests to have some meaning, we must
>> >> give the test the data in a format it expects. Then each test can
>> >> tell us about the particular characteristics it detects.
>> >
>> >Diehard read a (big) file. If I generate a file n bytes length, I think
>is
>> >not a problem how I generate the same n bytes, the problem is how
>generate
>> >each byte (as you say in the first paragraph).
>
>> You are confused. If you want to test bytes, you need to have tests
>> which are designed to work on bytes. If you want to use tests
>> designed to work on 32-bit integers, you need to supply 32-bit
>> integers, not 4 bytes. And in fact you supply 5 bytes.
>>
>> It is not a surprise that one can confuse a statistical test by having
>> it read data which is composed of multiple RNG steps.
>
>Where do you have read "Diehard expects to see 32-bit integers". I don't
>understand very well the english, but in the enclosed documentation I cannot
>see this phrase.
from diehard.doc:
[...]
OK, those are some of the ways you can create and test files
with programs on this disk.
But what if you want to test your own---or some other---generator?
[...]
Your random number generator should produce 32-bit integers.
Statistical tests necessarily deal with vectors of individual values
of some value range. If we look at the code for the various tests,
their descriptions often talk about selecting bits from among the
32-bit values they expect. We expect that there will be some value
format, integer or float of some size: We can't just throw arbitrary
data into a file and not expect different possible interpretations of
that data to give different results.
>If it's true what you say, Diehard is not capable to check any
>criptographically secure PRNG because they take only the few least
>significant bits at each step.
If one is taking bits from the RNG, one can use tests which are valid
for bits. None of these tests will tell us about the "strength" of
the RNG, however.
>Can you be more clear?
Probably not, but let's see:
Concatenating the output from several RNG steps is one way we try to
hide what is going on in the RNG. But if we want to know about the
RNG, we do not want to confuse ourselves!
Compare the case of using an entire value per step as opposed to
collecting bits from multiple steps into a single value. Can we
imagine that the statistical results will be unchanged? Clearly the
results will differ. That being so, which result is correct?
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.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
******************************
