Cryptography-Digest Digest #206, Volume #9 Tue, 9 Mar 99 12:13:03 EST
Contents:
Re: RC5 and RC6 code (free code) + update ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (Mark Currie)
I am on a role (RC4, RC5, RC6) ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (R. Knauer)
Re: RC5 and RC6 code (free code) ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Cyclotomic Number Generators (R. Knauer)
Re: Has anyone given easy-to-understand descriptions of encryption methods? ("almis")
Re: Yarrow (Simon Shepherd)
Does RC4 have the same problems as OTP? ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Ecommerce - Govt. consultation document ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Re: Testing Algorithms [moving off-topic] (Patrick Juola)
Re: Modular Multipliers (Henry Lewsal)
Re: DIE HARD and Crypto Grade RNGs. ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (Mark Currie)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: Does RC4 have the same problems as OTP? (Kent Briggs)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC5 and RC6 code (free code) + update
Date: Tue, 09 Mar 1999 11:28:07 GMT
> They're happy for people to use the algorithm. However, they're in
> business to make money, and figure that since they invented this thing
> they're entitled to a profit from the sweat of their skull, so they
> license it. They publish it so that people can see how clean and tidy
> the structure is and can evaluate its suitability for their applications.
>
> All seems consistent to me. However, if there are free alternatives that
> have similar perceived strength and tidiness, the market is limited to
> companies with specific needs... like the need to buy from a Known Name.
That's true. I still think there shouldn't be restrictions on open source or
non-profit programs. I am just learning. Hmm. Well I wait for a reply from
SecurityDynamics...
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: 9 Mar 1999 10:17:55 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>On 8 Mar 1999 20:20:02 GMT, [EMAIL PROTECTED] (Mark Currie) wrote:
>
>>One way to limit the damage in this situation would be to always hash the
>>output with a PRNG.
>
>I have asked people who want to use hash functions to fix errors in
>TRNGs to demonstrate that they do not cause unwanted correlations to
>become manifest. Thus far I have not gotten an answer, which makes me
>a bit suspicious that hash functions *might* actually do more harm
>than good.
You may be right. Unfortunately though, practical systems that are not allowed
to produce weak keys under any circumstances, cannot rely on a hardware RNG
entirely. The output must be tested and filtered to some degree.
>Again we are talking about the secruoty of the OTP cryptosystem, and
>how to generate crypto-grade keystreams for it. And until that issue
>is cleared up, it is ill advised to use a hash to clean up the output
>of a TRNG.
I am mainly concerned with the RNG used for key generation (symmetric or
asymmetric keys), not specifically for use with an OTP.
Mark Currie
------------------------------
From: [EMAIL PROTECTED]
Subject: I am on a role (RC4, RC5, RC6)
Date: Tue, 09 Mar 1999 02:50:23 GMT
Well I am really bored so I looked up RC4 too. I have an implementation which
actually is more portable (no WORD define) then the others. It works with the
test vectors I used. It's at:
http://members.tripod.com/~tomstdenis/rc4.c
http://members.tripod.com/~tomstdenis/rc5.c
http://members.tripod.com/~tomstdenis/rc6.c
All of them were tested in Micro-C (RC5 and RC6 were tested in DJGPP too). If
you would like to get a free copy of Micro-C checkout
'http://www.dunfield.com'. Note: I am not trying to spam, just to let you
know where I got my tools from.
I got the RC4 from a post on a website. I dunno if it's RSA RC4 but it looks
pretty solid. It works slightly different then RC5 and RC6. It uses the same
reversible function to decrypt. Also the session key (rc4_key) is a little
larger then the RC5/RC6 session keys.
Take a look, make comments if you wish. Enjoy.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Tue, 09 Mar 1999 12:31:11 GMT
Reply-To: [EMAIL PROTECTED]
On 9 Mar 1999 10:17:55 GMT, [EMAIL PROTECTED] (Mark Currie) wrote:
>You may be right. Unfortunately though, practical systems that are not allowed
>to produce weak keys under any circumstances, cannot rely on a hardware RNG
>entirely. The output must be tested and filtered to some degree.
But you would not want to apply meaningless tests and you would not
want to filter the keystream if doing so weakened it substantially.
Just what good does it do to apply statistical tests to the output of
a TRNG, other than serve as diagnostics? And why should you have to
apply filters to the output of the TRNG, if it is properly built to
specifications?
Anyway, you cannot filter the output of a TRNG, if by filter you mean
reject sequences for whatever reason. That would be in violation of
the fundamental specification for crypto-grade random numbers.
The purpose of a TRNG is to circumvent those issues. It is a
stand-alone true random number generator. It does not need to have its
output tested (other than as a diagnostic warning) and it certainly
cannot tolerate having its output filtered.
>I am mainly concerned with the RNG used for key generation (symmetric or
>asymmetric keys), not specifically for use with an OTP.
That is true in general for everyone else here. No one seriously plans
on implementing an actual OTP system since key management is such a
headache.
The OTP serves as an idealization for crypto-grade security. IOW, if
you can come up with keys that satisfy the requirements for proveable
security (or near proveable security) of the OTP system, you have
crypto-grade keys for use in other cryptosystems.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC5 and RC6 code (free code)
Date: Tue, 09 Mar 1999 11:32:57 GMT
In article <7c15pn$gv1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I got the file, but I don't have a RSA key, I have PGPI 6.0.2 and it makes
> DH/DSS keys only. I've attached it to the message (Yes I know I am ignoring
> the web of trust but I rarely use the key).
>
> Tom
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: PGPfreeware 6.0.2i
>
> <encoded_portion_removed>
> Vk5dLlS2ncQxRZWvAJ9teS7zsQyQYXpxqScNTDeDLsH/6A==
> =w4Li
> -----END PGP PUBLIC KEY BLOCK-----
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
1) I cannot help you without RSA key; I use PGP 2.6.3a.
2) Note the 'encoded portion removed' in your message. Apparently
DJN automatically removes keys from posts, so e-mail is recommended.
Robert G. Durnal
Web pages at www.afn.org/~afn21533
and members.tripod.com/~afn21533
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Tue, 09 Mar 1999 12:46:18 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Mar 1999 17:51:39 -0800, Jim Gillogly <[EMAIL PROTECTED]> wrote:
>> OK, then try that with an expansion of pi (to any base).
>> Bet it won't compress worth squat.
>Well, OK, just to test our intuitions and my compression
>estimates I went ahead and did it for 1,254,540 decimal
>places. Gzip compressed it by 52.9% (my "random" samples
>gave 53.0% each), and my 3|4-bit Huffman code compressed
>it by 57.505% (vs. my theoretical estimate of 57.5%).
Would you expand on all this please - it sounds quite interesting.
Where did you get the 1,254,540 decimal expansion of pi?
What is the significance of being able to compress pi by that much?
Is the actual compression of pi itself a true random number, since it
cannot itself be compressed any further?
Can sequences generated by a uniform Bernoulli process in general be
compressed significantly?
>As expected, pi in decimal isn't compressible this way,
I am a bit confused by that statement. In the first paragraph you said
that you were able to compress pi and now you seem to be saying you
could not. Obviously I am missing something, so please explain.
>despite being completely expressible in a single Greek letter.
That single Greek letter points to the actual digit expansion of pi
alright, but that does not mean that that single Greek letter
*describes* pi. If it were that easy, astrology would be a science.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Cyclotomic Number Generators
Date: Tue, 09 Mar 1999 12:47:21 GMT
Reply-To: [EMAIL PROTECTED]
Would you all please discuss cyclotomic number generators, in
particular the class of order 2.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: "almis" <[EMAIL PROTECTED]>
Subject: Re: Has anyone given easy-to-understand descriptions of encryption methods?
Date: Tue, 9 Mar 1999 07:45:27 -0600
[EMAIL PROTECTED] wrote in message
<7btndl$mqq$[EMAIL PROTECTED]>...
|Dear Cryptologers,
|
|I've been searching the Web and Usenet for some time, but I have not found
|what I've been looking for--a detailed description of encryption methods in
|language that I can understand. It would be nice to read a description of
a
|particular algorithm, say blowfish, broken down into steps and described in
|terms understandable to people who don't already know the jargon of
|cryptography or advanced mathematics. I'm particularly confused by
P-arrays
|and S-boxes.
|
|Please don't refer me to the FAQ. I've looked at it, and it confuses me as
|much as everything else. I'm looking for something easier, and I'd
|appreciate all the help I can get.
|
|Pharamond
|
|-----------== Posted via Deja News, The Discussion Network ==----------
|http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Beleive it or not ! There is a small book that meets your requirements.
It;s one of those Time-Life books called 'Computer security' (ISBN
0-8094-5670-2)
( I got a second-hand copy for $4 )
Lot's of big pretty pictures and diagrams. But does a fine job of
presenting the issues.
As to your request for step-by-step... The book goes through two
alternatives. DES and RSA.
The RSA is interesting in that it is in a slightly different (but
isomorphic)
form than the one usually presented.
i.e.
1. Gen two large primes P,Q (must meet some requirements)
2. Calculate N = P x Q
3. Choose an odd number E (must meet some requirements)
N and E form the public key.
4. Calculate T = 1 + (P - 1) x (Q - 1)
5. Calculate D = T / E
N and D form the private key.
Encryption:
I. Break the Plaintext into managable pieces and convert to a number P(i).
(byte and ASCII is OK)
II. Convert each P(i) to ciphertext C(i) via: C(i) = Remainder of (P(i) ^ E)
/ N
Decryption:
I. P(i) = Remainder of (C(i) ^ D) / N
..al
------------------------------
From: Simon Shepherd <[EMAIL PROTECTED]>
Subject: Re: Yarrow
Date: 9 Mar 1999 14:25:30 GMT
Bruce Schneier <[EMAIL PROTECTED]> wrote:
> On Sun, 7 Mar 1999 02:01:27 -0000, "David Barton"
> <[EMAIL PROTECTED]> wrote:
>>Is there a paper on Yarrow describing it in detail other than the
>>implementation available from Counterpane. I'm not a C programmer so I'm not
>>too keen on trying to disect C code to figure out how it works (the
>>details).
> We're putting the finishing touches on a paper; expect it on the
> website in a week or so.
> 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
------------------------------
From: [EMAIL PROTECTED]
Subject: Does RC4 have the same problems as OTP?
Date: Tue, 09 Mar 1999 14:21:03 GMT
I read that if you use the same key to encrypt two messages that you can
weaken the RC4 security? Is that true?
Thanks,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Tue, 09 Mar 1999 15:07:25 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Mar 1999 16:55:39 -0800, Jim Gillogly <[EMAIL PROTECTED]> wrote:
>Very likely -- I'm not tempted. Does this mean we now agree
>Champernowne's Number is not a relevant counterexample for the
>usefulness (or not) of statistical techniques in testing
>[T|P]RNG sequences?
The point I was trying to make was not as comprehensive as the point
you made. Most statistical tests focus on bit bias, and that is an
inadequate test criterion as Champernowne's number illustrates. You
also pointed out something else, namely that Borel normality is not a
sufficent criterion for crypto-grade randomness.
Bob Knauer
"There's no way to rule innocent men. The only power any government
has is the power to crack down on criminals. Well, when there aren't
enough criminals, one makes them. One declares so many things to be
a crime that it becomes impossible to live without breaking laws."
--Ayn Rand
------------------------------
From: [EMAIL PROTECTED]
Subject: Ecommerce - Govt. consultation document
Date: Tue, 09 Mar 1999 15:05:42 GMT
The Institution of Electrical Engineers (IEE) is holding a half-day conference
entitled "Electronic Commerce - Building Confidence?" in response to last
Friday's (5 March) Government Consultation Document on "Building Confidence in
Electronic Commerce". Because of the three week consultation deadline the
conference will be held at the IEE on Monday, 22 March 1999. The aim is for
it to act as a catalyst in providing a forum for the exchange of views and to
inform policy makers.
See <URL:http://www.iee.org.uk/Events/a22mar99.htm> for further information
and regular updates.
APOLOGIES IF YOU RECEIVE THIS MESSAGE MORE THAN ONCE
=========
Martin Barrett <[EMAIL PROTECTED]>
<URL:http://www.iee.org.uk/Informatics>
IEE, Savoy Place, London WC2R 0BL Fax: +44 (0)171 497 3633
"The IEE promotes the advancement of electrical, manufacturing and
information engineering and facilitates the exchange of knowledge and ideas."
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Tue, 09 Mar 1999 15:25:11 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 09 Mar 1999 14:41:04 GMT, [EMAIL PROTECTED] wrote:
>If you can decompress the compressed value, it is not random. It's entropy
>might be high, but what is the nature of the data? Can it be reconstructed
>with ease? Yes!
We have different notions of what constitutes randomness. For purposes
of crypto, a random number is one that is produced by a process (TRNG)
which is capable of generating all possible finite sequences
equiprobably, namely in an independent and equidistributed manner.
That allows the generation of both incompressible and compressible
sequences.
The entropy for such a TRNG process is maximal. If you exclude certain
sequences, such as those that compress greatly, you have limited
output from that of all possible numbers, which lowers the entropy of
the generation process.
What you are discussing is "algorithmic complexity randomness" of the
Kolmogorov-Chaitin variety, which is unsuitable for use in crypto. I
am not saying that you intended it to serve as a specification for
crypto-grade randomness, I am merely pointing out that it is
unsuitable because it excludes regular sequences which are allowed in
the specification of a (crypto-grade) TRNG.
Bob Knauer
"There's no way to rule innocent men. The only power any government
has is the power to crack down on criminals. Well, when there aren't
enough criminals, one makes them. One declares so many things to be
a crime that it becomes impossible to live without breaking laws."
--Ayn Rand
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Testing Algorithms [moving off-topic]
Date: 9 Mar 1999 10:36:09 -0500
In article <7bpipm$drj$[EMAIL PROTECTED]>,
Doggmatic <[EMAIL PROTECTED]> wrote:
>In article <7bonge$81b$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Patrick Juola) wrote:
>> In article <7bn566$b44$[EMAIL PROTECTED]>,
>> Doggmatic <[EMAIL PROTECTED]> wrote:
>> >In article <7b70cj$1li$[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] (Patrick Juola) wrote:
>> >> In article <7b6tmq$ojt$[EMAIL PROTECTED]>,
>> >> Doggmatic <[EMAIL PROTECTED]> wrote:
>> >>
>> >> >But I will look up this "reversible computing." For such a
>> >> >great idea researched 30 years ago, you think I'd have my Free-Energy
>> >> >computer by now.
>> >>
>> >> I'll build one for you. Just buy me a frictionless surface.
>> >[snip]
>[snip my previous condescension]
>> >accepted that there is no such thing as a "frictionless surface" in this
>> >universe. Here is where you can correct me if I'm wrong. I know that
>> >theoretically you can have smoother and smoother surfaces, but I thought that
>> >a frictionless surface is a physical impossiblilty, which is why I've also
>> >wondered about why "parasitic losses" were mention as if they are
>> >inconsequential.
>>
>> Because "parasitic losses" are the sort of things that engineers are
>> really good at reducing as technology improves. Look at the amount
>> of waste heat and waste power that a vacuum tube uses when compared
>> with an identically functioning IC transistor.
>>
>> > If the ideal cannot be reached, which is my current belief,
>> >then why even mention it, since this thread was originally about tractable
>> >solutions and not impossible ideal solutions.
>>
>> Because what is tractable in fifty years will be a hell of a lot closer
>> to the ideal than what's tractable today. And you don't have any idea
>> how much closer.
>>
>> -kitten
>
> Okay .. we'll play your game. Sample program:
>
> Time equals 0; <--- some arbitrary number Friction of surface equals 10;
><-- some random number beginning of a loop { time advances by 50 years;
>engineers reduce friction of surface by a factor of ten so new Friction of
>surface now equals old Friction of surface divided by 10; Tell me what the
>new Friction of surface is; } end of loop...repeat loop only until Friction
>of surface equals 0 then stop; Tell me how many years have passed;
Wrong stopping condition. Tell me; when friction is small enough that
per-bit losses are less than 1/2^256 of an erg. At that point, you'll
be able to count to 2^256 at a total cost of less than an erg of energy.
Let's see : 2^256 is about 10^75, so with the numbers you gave me,
less than 50*75 years.
-kitten
------------------------------
From: Henry Lewsal <[EMAIL PROTECTED]>
Subject: Re: Modular Multipliers
Date: Tue, 09 Mar 1999 08:06:53 -1000
BORIS KAZAK wrote:
>
> Here I have some questions for the gurus of this forum.
>
> Modular multiplication is a well known way to imitate
> S-boxes with a big number of input and output bits. For example,
> IDEA uses multiplication (mod 2^16+1) with the key-dependent
> multipliers. Similar routines can be easily implemented for
> multiplication (mod 2^32+1) and even (mod 2^64+1). The common
> objection that these two last modules are composite, can be
> overcome by choosing the multipliers so that these will be
> relatively prime to the modulus under consideration.
>
> Now the questions are:
>
> 1. What can be said about the properties of the S-box
> defined by this modular multiplication? Is it bijective, is it
> in any way linear, how does it propagate differences?
> (All this without looking at the particular multiplier,
> since we assume the multiplier to be key-dependent)
I assume you mean, the "factors" are key-dependent. In a multiplication
the two factors might be any small values and then mod 2^16-1 is done.
If both factors are smaller than 2^8, then the result will be smaller
than the modulus. A bad situation can occur when the factors are
very small: 4*71 mod 65537 = 00284, then if a small plaintext difference
requires 5*71 to be multiplied the answer is 00355 so error propagation
can be small in these cases. The statistics of these cases is easy to
calculate and the probabilities of input differences versus output
differences can be predicted. A conjecture is that there are
non-uniform probabilities for differentials and Impossible Differentials.
This non-uniformity of differentials is a vulnerability which needs
to be cured by subsequent transformations. If only multiplication
is used under a modulus, a conjecture is that it cannot be secured
against differential cryptanalysis.
Whether subsequent rotations help much is a subject for additional work.
>
> 2. Are there any "weak" or "biased" multipliers (excluding
> the obvious case of trivial multipliers which are their own
> multiplicative inverses)?
> If there are, how can one spot these in order to avoid them
> being used for an S-box?
>
> 3. Why not use the modular multiplication as a combining
> operation in a Feistel-like cipher instead of usual XOR?
> It is easily invertible, at the expense of using the direct
> multipliers for encryption and their multiplicative inverses
> for decryption. Anyway, if one reverses the order of subkeys,
> why not pick the decryption multiplier from an adjacent table?
>
> 4. It is obvious that modular multiplication by itself is
> a closed group, since
>
> A*M1*M2*M3 (mod N) = A*M4 (mod N)
> where M4 = M1*M2*M3 (mod N)
>
> Can these group properties be destroyed by intermediate XOR-ing
> with some key-generated numbers (mixing operations from different
> arithmetic groups)?
>
> Thanks in advance for responses BNK
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Tue, 09 Mar 1999 14:41:04 GMT
> Where did you get the 1,254,540 decimal expansion of pi?
Not too hard use Gregory Series (and if I knew it off the top of my head I
would give it to you).
>
> What is the significance of being able to compress pi by that much?
PI is therefore not random. Or not random enough. A true RNG series
shouldn't compress at all. However some RNG implementations have short
periods (linear- congruetiality) so in a 16-bit implementation, after 2^16
random numbers you could start compressing it based on the first 2^16
numbers.
>
> Is the actual compression of pi itself a true random number, since it
> cannot itself be compressed any further?
If you can decompress the compressed value, it is not random. It's entropy
might be high, but what is the nature of the data? Can it be reconstructed
with ease? Yes!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: 9 Mar 1999 16:05:24 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>On 9 Mar 1999 10:17:55 GMT, [EMAIL PROTECTED] (Mark Currie) wrote:
>
>>You may be right. Unfortunately though, practical systems that are not
allowed
>>to produce weak keys under any circumstances, cannot rely on a hardware RNG
>>entirely. The output must be tested and filtered to some degree.
>
>But you would not want to apply meaningless tests and you would not
>want to filter the keystream if doing so weakened it substantially.
>
>Just what good does it do to apply statistical tests to the output of
>a TRNG, other than serve as diagnostics? And why should you have to
>apply filters to the output of the TRNG, if it is properly built to
>specifications?
>
>Anyway, you cannot filter the output of a TRNG, if by filter you mean
>reject sequences for whatever reason. That would be in violation of
>the fundamental specification for crypto-grade random numbers.
>
>The purpose of a TRNG is to circumvent those issues. It is a
>stand-alone true random number generator. It does not need to have its
>output tested (other than as a diagnostic warning) and it certainly
>cannot tolerate having its output filtered.
>
Any electronic circuit used as a hardware RNG should be tested before use,
firstly in the diagnostic sense, to prevent usage in case of failure. Secondly,
to prevent the use of "bad" values. Even a TRNG, as you mentioned earlier, can
produce long runs of 1's or 0's. These values may not be tolerated in certain
applications. These are non-ideal, practical, real world problems. The question
is how much can be tolerated. Trevor Jackson seemed to have some ideas in this
regard but I wish he would turn off the HTML.
Mark Currie
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 9 Mar 1999 10:54:12 -0500
In article <7c3btu$dbh$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>
>> What is the significance of being able to compress pi by that much?
>
>PI is therefore not random. Or not random enough. A true RNG series
>shouldn't compress at all. However some RNG implementations have short
>periods (linear- congruetiality) so in a 16-bit implementation, after 2^16
>random numbers you could start compressing it based on the first 2^16
>numbers.
Oh, bullshit.
He used the decimal digits of pi; the decimal digits of pi, EXPRESSED
IN ASCII, are easily compressible without affecting the randomness
of pi. Mr. Knauer just specified that the work must be done in decimal
in a quibble with Champer-whatever's number.
-kitten
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Does RC4 have the same problems as OTP?
Date: Tue, 09 Mar 1999 16:29:06 GMT
[EMAIL PROTECTED] wrote:
> I read that if you use the same key to encrypt two messages that you can
> weaken the RC4 security? Is that true?
As with all stream ciphers, you need to add SALT to the key so that you
never produce the same key stream twice. Otherwise, if one plaintext became
known all plaintexts encrypted with the same key would be known.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
** 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
******************************
