Cryptography-Digest Digest #480, Volume #12 Fri, 18 Aug 00 17:13:01 EDT
Contents:
Re: Not really random numbers (James Felling)
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Fri, 18 Aug 2000 15:28:04 -0500
Anthony Stephen Szopa wrote:
> 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)
Minimal .. I don't call 1/2 hour per keysetup "minimal" I can do an RC4 setup in under
a minute, and be
sending/recieving crypto then.
>
>
> "... 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.
The reversibility is both a strength and a weakness. Most good stream cyphers are
composed of reversable
components( it prevents entrophy reduction) with some mechanism of obscuring internal
state ( the mod 256 step
with discard in your case).
> In my example,
> how can you choose the correct prior state from over 87 billion
> possible previous states?
Given your RNG's most recent output, I can guess the 3 internal streams with odds of
1/3. Given even a bit of
this data, I can mount a stream guessing attack which will be more effedctive than
brute force.( if the mix
files are well made, perhaps not much better than brute force, but better than brute
force.
> 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?
I don't have to ( Ideally that is what I want to do because it gives me everything),
in attacking a stream
cypher all I need to do is be able to predict the next byte or some component thereof
at a rate better than
chance If I can guess your output bytes with a probability of better than 1/256, or
some bit of it with a
probability better than 1/2, I can mount recovery atttacks versus the plaintext
bytes.( true the system is
not necessarially totally compromised by this, but it starts leaking data)
As an analyst the goal is to get what you can, not necessarially get everything. You
might not consider it
broken if it is leaking in this manner, but it can lead to a real compromise in
security. All the oposition
needs to do is predict your stream at a rate better than chance would allow, and you
start leaking, and the
better they can predict your stream the worse off you are. If it gets to the point
where I can guess a byte
with a probability of Oh say 192/256, even a poor analyst can recover english
plaintext if he has enough text.
I DON'T NEED YOUR KEY, I just need to be able to guess what comes next with better
than fair odds.
> <snip>
>
>
> "...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 I use 3 mix files that are based upon a single pass of your weakest method, I can
break this code in my
sleep. It becomes possible to predict the next byte with far better than 90% accuracy
-- I'd call that a flaw.
You need to recomend a minimum secure level. As it stands it is quite possible for an
amateur wanting to
quickly implement your method to send messages that may as well be cleartext. As a
responsible vendor you are
obligated to suggest the minimum safe levels for your program, if not weak keying will
be selected, and your
users left vulnerable.
>
>
> "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.
All of these keys are stored somewhere, right? If someone steals them/destroys them,
then how do you rekey? You
must generate a new key and distribute it, right? That is the threat I propose.
>
> <snip>
>
> 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.
Please elaborate how the uncertanty princible applies to mathematical logic. Godel's
Incompleteness theorem
applies to that field, but your method is not sheilded by that. There is no great
unsolved problem that you
link to. Given enough plaintext, and a determined foe, your method WILL fall.
>
>
> "...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.
>
That will most certianly help, but there are other potential avenues of attack.
>
> 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.
You had better hope that the mixfiles used to generate the high digit of your 3 digit
phase are good. Because
that file is responsible for 70% of the discarding that secures the other two. and I
a good method of
prediction can be developed for it, your security on the remaining 2 mix files will be
seriously reduced. It is
the single weak point that must be protected at all costs.
>
>
> Thanks again for your consideration.
------------------------------
** 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
******************************
