Cryptography-Digest Digest #478, Volume #12 Fri, 18 Aug 00 16:13:00 EDT
Contents:
Re: Not really random numbers (Anthony Stephen Szopa)
Re: Looking for a DES or RSA chip with write-only key. (Benjamin Goldberg)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Fri, 18 Aug 2000 12:38:15 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > >
> > > > James Felling wrote:
> > > > >
> > > > > > <snip>
> > > > >
> > > > > >
> > > > > > >
> > > > > > > I must state this. Files of this nature can be manufactured by other
>PRNG's. They
> > > > > > > will be manufactured as quickly if not more so, and as securely, if not
>more so. May I
> > > > > > > suggest an apropriately tweaked RC4, or BBS for your use. The issue is
>it will take ~1
> > > > > > > hour of operator time to start generating good data with your mechanism,
>and it will
> > > > > > > also take more than a bit of time after that to actually generate the
>numbers. OTOH,
> > > > > > > it will take 1 minute to setup a good RC4 generator, and it will have
>generated a
> > > > > > > reasonable quantity of data( equivalent to your files) in under a half
>hour.( I think
> > > > > > > the fact that it takes less of MY time, and is done before OAP/OAR gets
>started is a
> > > > > > > HUGE advantage.) BBS is slower, but substantially more secure. It will
>probably take
> > > > > > > 5 minutes of my time to setup, and generate an amount of data sulficient
>to be useful
> > > > > > > in several hours. This is speed wise compeditive with your system, and
>is going to be
> > > > > > > more secure than your system in general.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > > > > > <snip>
> > > > >
> > > > > >
> > > > > > > RC4, BBS, and all others when saved to files encrypt just as fast as
>your method -- The
> > > > > > > issue for the user is forufold
> > > > > > >
> > > > > > > 1) how much of my( the user) time do I wish to invest. (ideally as
>little as possible)
> > > > > > >
> > > > > > > 2)how much computer time do I wish to invest (ideally as little as
>possible)
> > > > > > >
> > > > > > > 3) how much space on my machine/ the remote machine do I want to use for
>this, (
> > > > > > > ideally as little as posssible)
> > > > > > >
> > > > > > > 4) How long is key data going to be lurking in an available form in
>my/remote PC. (
> > > > > > > ideally for as short a period as possible)
> > > > > > >
> > > > > > > versus RC4 you lose on all 4 points.
> > > > > > > versus BBS you lose on points 1,3,4 and cannot deliver security with an
>equivalent
> > > > > > > degree of confidence.
> > > > > > >
> > > > > > > You have a second rate stream cypher -- it is slower than most BLOCK
>algroithims. I
> > > > > > > admit that using large "random files" will give a speed enhancement, but
>they add
> > > > > > > secondary points of attack to your algorithim, and any other stream
>cypher, and most
> > > > > > > block cyphers can do the same trick faster.
> > > > > >
> > > > > > I think your confidence level is not warranted.
> > > > > >
> > > > > > "is going to be more secure than your system in general." This is
> > > > > > clearly over reaching.
> > > > >
> > > > > Does your system have a mathematic proof which indicates that a break of the
>system is
> > > > > equivalent to the solution of the QRP problem? Or tying a its dificulty of
>breaking to the
> > > > > same? If so then feel free to attack BBS, but for well chosen values BBS
>has a known minimum
> > > > > level of security, and cannot have "bad keys". Your system can have bad
>keys, and has no
> > > > > minimum guaranteed security level. I feel that this results in a system "
>more secure in
> > > > > general" than yours.
> > > > >
> > > > > >
> > > > > >
> > > > > > "1) how much of my( the user) time do I wish to invest. " This is
> > > > > > certainly a (modest) concern. It is answered by asking yourself how
> > > > > > much more secure is OAP-L3 than other methods.
> > > > >
> > > > > It is no more secure than any other PRNG. It is less secure than BBS( in
>general) and can
> > > > > probably compare to RC4 with a sulficient investment of operator time. OTOH
>RC4 is faster,
> > > > > takes less effort to setup properly, and is simpler to use for equivalent
>quality random
> > > > > numbers.
> > > > >
> > > > > > As you should know,
> > > > > > OAP-L3 uses no mathematical equations in generating random numbers.
> > > > >
> > > > > Really?
> > > > >
> > > > > >
> > > > > > There is no modulo operation, for instance.
> > > > >
> > > > > None by that name -- but you do out put your numbers with discarded values(
>I believe any
> > > > > value of 3*255 or higher is discarded in post processing when you are
>combining the three
> > > > > streams -- if that is not mudulo truncation what is it?
> > > > >
> > > > > > In other words, there
> > > > > > are no inherent constraints in the random number generation process.
> > > > >
> > > > > Please define "constraints" -- I think you constrain your generator in any
>number of ways --
> > > > >
> > > > > >
> > > > > > With no constraints there is no way to trivialize cracking the
> > > > > > random number generator.
> > > > >
> > > > > There are no such known ways of using such versus any other crypto grade PRNG
> > > > >
> > > > > > This may make the additional time worth
> > > > > > it. Besides, the time need be invested only once since you will be
> > > > > > able to generate more random numbers than you could ever possibly
> > > > > > need with very very little additional effort.
> > > > > >
> > > > > > "2)how much computer time do I wish to invest?" This point also
> > > > > > addresses the limited cost of using OAP-L3. You cannot simply look
> > > > > > at cost. As above you must look at what you are getting for your
> > > > > > cost. See below.
> > > > > >
> > > > > > "3) how much space on my machine/ the remote machine do I want to use
> > > > > > for this,..." This is a valid cost concern. See below.
> > > > > >
> > > > > > "4) How long is key data going to be lurking in an available form in
> > > > > > my/remote PC." This is valid security concern.
> > > > > >
> > > > > > Here is my response to the remaining concerns:
> > > > > >
> > > > > > You may be aware that OAP-L3 Version 4.1 / 4.2 is the original
> > > > > > implementation of the theory / concept. This implementation has
> > > > > > the cost concerns that you have a legitimate reason to point out.
> > > > > > And you may not be willing to incur these costs.
> > > > > >
> > > > > > My proposed implementation for Version 5.0 is available at
> > > > > > http://www.ciphile.com from the What's Ahead web page.
> > > > > >
> > > > > > Version 5.0 is explained in detail in the files available for
> > > > > > download by clicking the blue anchors located at the bottom of
> > > > > > this page: Version 5.0 Tables file and the associated Version
> > > > > > 5.0 Text file.
> > > > > >
> > > > > > Version 5.0 will not require you to generate random number files
> > > > > > beforehand. Permanent hard drive space will not be required because
> > > > > > the key / encryption data will be kept on floppy. This pretty much
> > > > > > dispels #2, #3, & #4.
> > > > > >
> > > > > > I addressed #1 initially, above.
> > > > > >
> > > > > > Depending on which variation of version 5.0 one uses, the
> > > > > > encryption time will vary.
> > > > > >
> > > > > > Here is a brief description. Full details by clicking the blue
> > > > > > anchors at the bottom of the What's Ahead web page.
> > > > > >
> > > > > > ("E" notation means that a number expressed as 5E6 = 5 x 10^6 or
> > > > > > 5,000,000.)
> > > > > >
> > > > > > With only 2920 data bytes you will be able to generate 9.2E15 random
> > > > > > numbers from 0 - 255 with a security level equivalent to 2000 bits;
> > > > >
> > > > > RC4 with a combiner
> > > > >
> > > > > with only 300 data bytes get security equivalent to 2000+ bits
> > > > >
> > > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > or with only 4600 data bytes you will be able to generate 2.3E17
> > > > > > random numbers from 0 - 255 with a security level equivalent to
> > > > > > 10,000 bits;
> > > > >
> > > > > RC4 with a combiner
> > > > >
> > > > > with only 2000 data bytes get security greater than 10000 bits
> > > > >
> > > > > >
> > > > > >
> > > > > > or with only 1,271,000 data bytes (fits on one floppy) you will be
> > > > > > able to generate 1.3E36 random numbers from 0 - 255 with a security
> > > > > > level equivalent to 100,000 bits.
> > > > >
> > > > > Imagine typing in 1271000 random characters. Sound fun to you. It sure does
>not sound fun to
> > > > > me.
> > > > >
> > > > > RC4 with a combiner
> > > > >
> > > > > with only 20000 bytes of data get security superior to 100000 bits.
> > > > >
> > > > > >
> > > > > >
> > > > > > The Version 5.0 Tables file and the associated Version 5.0 Text file
> > > > > > describe how this is done.
> > > > > >
> > > > > > You don't need to keep the key / encryption data on your computer.
> > > > > > Keep it on a floppy disk.
> > > > >
> > > > > Get the floppy stolen and copied. You still have a single point of failure
>which compromises
> > > > > the whole system, and which cannot easily be rekeyed.
> > > > >
> > > > > > Insert it when needed then remove.
> > > > > >
> > > > > > Thanks for your consideration.
> > > > >
> > > > > You just don't get it. your method is less effective, more difficult, and
>slower than other
> > > > > public domain methods. Why should it be used?
> > > >
> > > > I said you are over reaching. What do you mean by less effective and
> > > > support why OAP-L3 is less effective?
> > >
> > > Less effective is fairly easily defined: Given a specific quantity of input
>key, how random is the
> > > output ( your method thends to need more keying data to achive a given level of
>entropy than many
> > > others).
> > >
> > > Annother definition of effective that is useful to examine is how many "weak
>keys" exist in a given
> > > method. Your method possesses numerous weak keys -- if the user selects poorly,
>he may get very
> > > poor random numbers from your system, BBS or RC4 if properly implemented will
>always give a stream
> > > of numbers of known minimum quality.
> > >
> > > A third useful form of effectiveness that you have issues with is key agility.
>Assuming that you
> > > learn that your key is compromised, but also need send data ASAP. To set your
>system up( properly)
> > > will take a highly skilled operator on a fast PC a half hour, while RC4 can be
>swithched keys and
> > > transmiting on an alternate key in less than a minute( assuming an equally
>skilled operator), and
> > > BBS in less than 5 minutes. Maybe your data isn't that urgent, but if it is
>which delay will be
> > > more acceptable.
> > >
> > > A fourth form of effectiveness that your system needs work on is operator time
>consumption -- as an
> > > employer would you rather have your employee spend 30 minutes focused on a rekey
>every keying cycle
> > > or would you rather have them focused for 1 to 2 minutes, and available for the
>extra 20 odd
> > > minutes to perform other tasks?
> > >
> > > > Are you saying it is less
> > > > secure.
> > >
> > > Yes. Where is your proof of security? Who other than yourself will speak up in
>favor of your
> > > claims?
> > >
> > > > I say OAP-L3 is more secure because there are no inherent
> > > > constraints in the random number generation process and therefore no
> > > > constraints can be exploited to trivialize the cracking of the random
> > > > number process.
> > >
> > > What does "no inherent constraints" mean in this context. In what way are BBS
>or RC4 "constrained"
> > > or "restricted" in their output? How do their inherent properties constrain the
>values that they
> > > output in any real sense? How can this be used to "trivialize" the cracking of
>those methods?
> > >
> > > >
> > > > You cannot just say "less effective" in a vacuum. You must state
> > > > the proposed use for the software. What application did you have in
> > > > mind? Encrypting email messages?
> > >
> > > I might use it for encrypting e-mail messages if I felt particularly
>massocistic. It could be used
> > > for person to person traffic if they were willing to invest the effort. But for
>that aplication, I
> > > would rather use RC4 -- it is faster and easier to use.
> > >
> > > >
> > >
> > > >
> > > >
> > > > I claim that the military could use OAP-L3 effectively. For
> > > > instance, the U.S. Navy could use it to encrypt communications to
> > > > the entire fleet.
> > >
> > > (data only? or data+voice?)
> > >
> > > > How many megabytes / gigabytes of data do you
> > > > suppose the entire Navy transmits to its fleet each day?
> > >
> > > Alot of data. Given a desire not to have a compromised key the navy would need
>at least one
> > > fulltime key generator to keep everyone in keys using your system, or they would
>need one person
> > > for an hour each week generating RC4 keys , and available the remainder of the
>week -- which should
> > > they prefer?
> > >
> > > >
> > > >
> > > > OAP-L3 is simple.
> > >
> > > Not for the amateur user( unless substantial upgrades to the interface and
>documentantion have been
> > > made in the past month)
> > >
> > > > And the security benefits outweigh your other
> > > > concerns which are of greatest concern in this first implementation.
> > > > They come down to generating the OTP files beforehand and storing
> > > > them. These concerns are easily dealt with.
> > >
> > > Please let me know what measures have been taken to address my concerns in re
>performance?
> > >
> > > >
> > > >
> > > > And just because you cannot imagine using OAP-L3 effectively does
> > > > not mean that it cannot be done.
> > >
> > > Of course it can be used securely. Of course it CAN do the job. But I if can
>pound nails with a
> > > jagged piece of rusty steel, does that make a jagged piece of rusty steel the
>ideal tool for that
> > > job? No. The same goes for OAP/OAR.It can do the job, but it is a poor tool for
>that purpose.
> > >
> > > > You will admit you have no
> > > > interest in solving your issues with OAP-L3.
> > >
> > > Just as I would have no interest in repairing a car that has gone through a
>crusher -- the return
> > > on investment isn't worth it. But as a customer, it is NOT my job to fix OAP-L3,
>it is your job to
> > > resolve customer issues. If I buy a program with an unusable interface is it my
>job to fix that?
> > > Or if it cannot meet the marketing claims made for it must I fix it?
> > >
> > > > So since you have
> > > > not thought about how to solve these issues for yourself, why should
> > > > anyone listen to you: someone who chooses not to think
> > > > yet make cursory superficial claims which I say again are easily
> > > > dealt with?
> > > >
> > >
> > > Given that I have discussed these issues with you in the past, and further that
>I have examined
> > > your program in deatil and the mechanisms with which it attempts to provide
>security, and that I
> > > have seen other programs in action doing the same thing as well if not better
>than your product,
> > > where have I not been diligent? Have you addressed any of my claims in anything
>other than a
> > > superficial manner?
> > >
> > > >
> > > > Why don't you just say you want to trash OAP-L3 and don't care to
> > > > support your position other than to give vague and general
> > > > statements with no specific situations.
> > >
> > > I see only that you respond to rational arguments with diversions and half
>truths.
> > >
> > > >
> > > >
> > > > Give us your biggest objection to OAP-L3 with a proposed use where
> > > > it would not be effective or where it would be less effective?
> > >
> > > Sure -- e-mail. Compare it to PGP. It costs more, offers security that is at
>best equivalent, is
> > > more easily compromised, is harder to use, harder to change keys with, has been
>subject to
> > > substantially less analisys, is slower, offers fewer features, and offers less
>technical support
> > > for the begining user. Certianly it COULD be used for that aplication, but PGP
>has it beat.
> > >
> > > Or alternatively secure web transactions-- compare it to RC4 as a SSL cypher.
> > >
> > > Or for securing local files -- comapre it to a block cypher or RC4 with a
>memorizable key.
> > >
> > > > And
> > > > how many people need this capability?
> > >
> > > I am not certian -- I'd say most of us who use crypto.
> > >
> > > >
> > > >
> > > > Perhaps Internet backbone service providers who wish to encrypt and
> > > > transmit terabytes of data per hour might find OAP-L3 unacceptable.
> > >
> > > Most certianly.
> > >
> > > >
> > > > But how many users need to encrypt and transmit terabytes or even
> > > > gigabytes each hour through one server or portal?
> > >
> > > Not many.
> > >
> > > >
> > > >
> > > > I say again, you are overreaching to maintain your mostly untenable
> > > > and insupportable position.
> > >
> > > Ditto.
> >
> > Again, let me thank you for taking so much time and effort in your
> > reply.
> >
> > I am short of time now and for the near term.
> >
> > "your method thends to need more keying data to achive a given
> > level of entropy..." First I would like to say that OAP-L3 can
> > match any level of entropy attainable by any other form of
> > encryption, and can approach as closely as the user likes truly
> > random entropy.
>
> Of course, it is possible to reach a very high level of entrophy with your methods.
>OTOH your methods
> take a much more circuitous route on their way there. Given 2 points on a plane, a
>random walk will
> eventually connect them, but it is much less efficient than a straight line from A
>to B. Similarly your
> method takes substantially more user effort to achieve the same results as RC4 or
>other good PRNG's. It
> is not unusable, merely impractical to use.
>
> >
> >
> > One may choose to take the time and make the effort (both
> > reasonable) knowing that there are no inherent constraints in
> > the random number generation process therefore the security of
> > the software is solely due to the random key length. There is
> > no hope of factoring prime numbers for instance, there is no
> > modulo 128 constraint, there is nothing that can be used to
> > attack the process except brute force. (see below)
>
> I would debate that. If an attacker had an idea as to the processes chosen in the
>setup, an effective
> attack will be findable in a faster than bruteforce manner. ( all of your methods
>are reversable except
> your modulo combiner at the very end.). There may well be a cycle detection method
>that will work well
> against your methods.
>
> >
> >
> > "Your method possesses numerous weak keys..." If you use the
> > software according to minimal recommendations you will always
> > generate exceptionally strong keys.
>
> Reading your recomendations through, I do not see any recomendation that would
>prevent an amateur user
> from selecting a weak key for eack of the mix files/ rand files, and getting
>extremely substandard random
> numbers.( assume each mix file is created by a single aplication of the scramble
>method -- there is no
> advisement not to rely on such single passes). There will be a huge level of
>weakness there. ( much less
> than your publicity would indicate). Users MUST use different methods repeatedly to
>make each mix file.(
> otherwise you will run into some HUGE issues with the quality of mix files), and
>therefore with the
> quality of Rand files.) ( Frankly I'd rely more upon a few well mixed mix files than
>upon many
> potentially poorly mixed ones)
>
> >
> >
> > "Assuming that you learn that your key is compromised, ..." When
> > you generate your original key I recommend you (essentially /
> > effectively) continue to generate many many more keys so if you
> > need another key you have one ready to go.
>
> If your keying material is compromised(no matter how much of it you have) then you
>must generate new
> material -- so you cannot have on "ready to go"
>
> >
> >
> > "...as an employer would you rather have your employee spend 30
> > minutes focused on a rekey every keying cycle..." You only need
> > one keying cycle. Think ahead and estimate your greatest possible
> > encryption needs and generate this much random data. Then you might
> > want to then triple this amount and store the other two different
> > sets of data in two different locations, etc. for security reasons.
> >
> > Let's say someone steals one of these sets of CDs. I claim that
> > these stolen CDs cannot be used to generate any random data found
> > on the secure CDs using the current implementation and any proposed
> > implementations. (see below)
> >
> > I will have to end it here with this last point:
> >
> > "Where is your proof of security?" I will restrict my answer to the
> > generation of the random numbers on a stand alone machine (assuming)
> > in a secure location. (We could go on endlessly on how spies or
> > moles can get at your keys, especially if you are as stupid as
> > Security is at Los Alamos.)
> >
> > Let me take one process because one is representative of the others.
> > First of all you need random user input. It is recommended that you
> > shuffle a deck of cards with 56 cards in it to get four random
> > sequences of the numbers 1 - 14. Or you can use numbered beans
> > shaken in a bottle and withdrawn one by one for these sequences.
> > Etc. (see Help Files at http://www.ciphile.com) These and similar
> > random processes will generate the random user input.
> >
> > This one of several processes, will sequentially divide the
> > 3,628,800 unique ten digit permutations of the digits 0 - 9 (the
> > original encryption data file) into 14 files of 259,200
> > permutations each.
> >
> > The permutations in each of these 14 files will be shuffled together
> > one permutation from each file at a time according to the random 14
> > number user input sequence thus generating a now reordered
> > permutation file of the original 3,628,800 unique permutations.
> >
> > This process can be repeated using another randomly generated 14
> > number sequence any number of times using this particular process
> > or one of several others that are equally inherently unbiased to
> > generate a subsequently reordered encryption data file.
> >
> > There are 3,628,800! (factorial) possible orderings of this
> > encryption data file. Three thoroughly different ones are used in
> > the current implementation to generate random numbers. (see Help
> > Files) Therefore there are (3,628,800!)^3 possible orderings of
> > three such files.
> >
> > The generated random numbers are then further shuffled to generate
> > subsequently reordered random number files, etc. (see Help Files
> > for exact processes, etc.)
> >
> > The security of OAP-L3 comes from the fact that it does not take
> > very many random user input sequences used in very many of the
> > possible processes to make duplication of the final OTP files of
> > random numbers practicably impossible to duplicate.
> >
> > Furthermore, even if someone were to gain a significant portion of
> > the random numbers generated, it would not be possible to duplicate
> > the unknown random numbers because without the original key of
> > random user input sequences and the processes used and the order
> > in which they were used could anyone determine them since the
> > final OTP random numbers are essentially the product of a one way
> > series of processes with the known random numbers not providing you
> > with sufficient information to generate the original key.
> >
> > All of this is explained in the Help Files.
> >
> > See you all in a month or three.
>
> You really expect brute force versus your method? There is an extensive body of
>research into
> permutation theory that you seem ignorant of that could be used to attack your
>method with some minimal
> knowlege of the key generation process.
Damn. I am somewhat addicted.
" ...it is much less efficient than a straight line from A to B...."
This is why OAP-L3 is so secure. Place any two points anywhere and
there is an infinite number of ways to get from one point to the
other using OAP-L3. A straight line would make any encryption
much much more insecure. OAP-L3 takes a minimal amount of effort
to set up but this minor cost is well worth it. (see below)
"... all of your methods are reversible..." Taken individually,
each process is certainly reversible but only in the sense that by
trying every possible random user input, you can be sure that at
least one will produce the correct previous state. In my example,
how can you choose the correct prior state from over 87 billion
possible previous states? Note that I said that "...since the
final OTP random numbers are essentially the product of a one
way SERIES of processes..." Now, by repeatedly processing each
subsequent state using new random user input how can you get
back to the first original encryption data file?
Figure it out. Let's say I use 100 processes and you do not know
which ones I've used or in what order, and you do not know the
random user input to each process, theoretically, you could
determine the correct key but here is your minimal task in a nut
shell: just for starters, there will be only one chance in
(87E9)^100 that you are correct. You must carry out all theses
steps with all your guesses before you can test to see if you are
correct. If not, try your next guess, and so on. You have to make
a guess of 100 processes, with 100 sequences of random input,
guess the order of the processes, then run the processes to get
output you can test, AND you have to do this procedure (87E9)^100
times.
Okay, let's assume the person you are targeting is paranoid and uses
encryption keys with a minimum of 1000 processes, then with this
random number output, he or she combines the random number output
from one or more other random number outputs from 1000 process keys
to create the final OTP random number files.
I recommend you not even waste your time trying to crack the
encryption. Try to steal the key / final OTP random number data
files, or arrest the target and try your powers of persuasion to
get what you want.
"...I do not see any recommendation that would prevent an amateur
user from selecting a weak key..." There is no restriction on
the security level the user decides to implement. The user is
given the details as to how strong to make the encryption desired.
This is not a fault of the software but an advantage. The user can
choose a short key length and thus a less secure key, or a very
long key length and thus a much more secure key. The user is
given examples as to how to determine the strength of the key
chosen.
"If your keying material is compromised (no matter how much of it
you have) then you must generate new material -- so you cannot have
on "ready to go." This is really rudimentary stuff. Let's say I
generate a key using 100 processes. Then I continue on and proceed
to generate another subsequent key with an additional 100 processes.
And a subsequent key with another 100 processes, and so on.
I initially use the key of 100 processes. It gets compromised
somehow. Okay. I have the 200 process key ready to go. Lets say
this 200 process key gets compromised somehow. Okay. I have my
300 process key ready to go, and so on.
You say that my 200 process key is compromised? Even if I told you
starting encryption data file I begin the second 100 processes with you
would still have to determine the subsequent 100 processes, etc.
Or let me suggest that your paranoid target, in the final OTP random
number files generation process always combines more than one set of
random numbers. Now you only know that the random numbers that you have
compromised came from one or more 100 process or more keys.
How in your god's great creation are you ever going to break this
down? I know: "I am sure there must be a way."
Have you ever heard of the uncertainty principle? Some things can
never be known. Just accept it.
"...that could be used to attack your method with some minimal
knowledge of the key generation process." A cracker has 100%
knowledge of the processes involved in the software. He can
have vast quantities of cypher text / plain text pairs. What the
cracker is assumed not to have is the random user input, knowledge
of what processes are used or what order the processes were used in.
An additional reason I say that even with all this knowledge the
OTP random data files are not compromised is that the nature of
the random number generator is that only about 76% of the random
digits generated are used. About 24% are discarded. And these
random digits are discarded at random. So the random numbers from
0 - 255 that are finally generated and further "shuffled" have lost
too much information for any meaningful analysis to be performed
with the hope of cracking the key.
Thanks again for your consideration.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Looking for a DES or RSA chip with write-only key.
Date: Fri, 18 Aug 2000 19:49:07 GMT
[WARNING: place coffee cup firmly on the table to avoid making mess]
Mark Currie wrote:
>
> I would not recomend *burning-in* of keys. The Pijnenburg chips -
> PCC101 (DES) & PCC201 (Exponentiator) have write-only key registers
> that (I think) can be retained with a battery after power-down.
[snip]
Surely you don't *really* mean "write-only", do you?
------------------------------
** 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
******************************
