Cryptography-Digest Digest #484, Volume #12 Sat, 19 Aug 00 00:13:01 EDT
Contents:
Re: Not really random numbers (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Fri, 18 Aug 2000 20:41:16 -0700
James Felling wrote:
>
> 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
I must give you the last word.
You have it.
------------------------------
** 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
******************************
