Cryptography-Digest Digest #476, Volume #12 Fri, 18 Aug 00 13:13:00 EDT
Contents:
Re: Not really random numbers (James Felling)
Re: What is up with Intel? ("Douglas A. Gwyn")
Re: New Stream Cipher like SEAL ("Douglas A. Gwyn")
Re: 215 Hz five-qubit quantum processor (Robert Harley)
[OT] Re: blowfish problem ("Michael Will")
Just a thought... ("Simister, Shawn [SKY:0000:EXCH]")
Re: Breaking Simple XOR Encryption ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Fri, 18 Aug 2000 11:14:17 -0500
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.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: What is up with Intel?
Date: Fri, 18 Aug 2000 15:07:57 GMT
Benjamin Goldberg wrote:
> lcs Mixmaster Remailer wrote:
> > As for how it is better, specifically it produces more efficient
> > output, with a smaller percentage of rejected bits, preserving more of
> > the entropy in the input.
> This sounds like a good thing... with the von Neumann method of removing
> bias, if we run it on an already unbiased stream of bits, over half the
> bits will be discarded.
The paper I previously cited (May 2000 IEEE Trans Inf Th) gives
a computationally feasible method that is asymptotically 100%
efficient.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New Stream Cipher like SEAL
Date: Fri, 18 Aug 2000 15:10:05 GMT
csybrandy wrote:
> ... If you replace the sizeof(buf)/16 with a static or
> precomputed value it will run faster. I believe that certain
> optimizations will do this automatically, but I feel it is
> good practice to do this manually if you don't have to
> recompute the value all the time.
Every C compiler I know of performs constant folding.
It is much better to express the algorithm clearly
than to attempt manual micro-optimizations that
obscure what is happening.
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: 18 Aug 2000 18:04:40 +0200
"Dennis O'Connor" <[EMAIL PROTECTED]> writes:
> [...] A non-deterministic Turing machine can sort
> of be described as a Turing machine that "goes both ways
> at all branches" until it finds an answer. [...]
Yes.
> A quantum computer operates by starting with a wave
> function that includes all possible solutions to a problem,
> and then "collapsing" that wave function to a correct
> solution. This makes it akin to a non-deterministic
> Turing machine.
No. This is the popular perception which makes people think that a
"quantum computer" could solve NP problems trivially and leap tall
buildings in a single bound.
I have an 8-qubit quantum computer in my pocket: 8 coins. When I want
an 8-bit result I just flip them all without looking. The correct
answer is right there, superposed with all the wrong ones. However
when I open my eyes, the wave function tends to collapse to a wrong
one. Darn! =:-(
I just need to try exponentially many times, or be exponentially lucky
or something. The NMR quantum computer mentioned in the subject line
is no different: its needs an exponential number of molecules. Just
be sure to sweep the exponential bit under a thick carpet when
applying for a grant.
Later,
Rob.
------------------------------
From: "Michael Will" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: [OT] Re: blowfish problem
Date: Fri, 18 Aug 2000 12:28:26 -0400
Richard Bos wrote:
>Michael Will wrote:
>
>> After all these years I see there's always something new to learn.
>> I should go check my K&R to see if I should have known this from the
>> very start. (Yes, the original. The one we had to carry to school
>> uphill in the snow both ways, etc.)
>
>No, you shouldn't. It's quite possible that the word byte is used
>differently in K&R.
That's certainly one outcome. I either don't know or have forgotten.
So, as stated above, that's where I have to start to see whether it was
something I should have learned at the time or if it was added/changed
later. (Which I still should have learned, just at a later time)
Clearer now? This was not a comment about the definition of C, but
about the history and evolution of the language.
(Or maybe more about if I picked the wrong lecture to be more interested
in the girl in the next row)
- Michael
------------------------------
From: "Simister, Shawn [SKY:0000:EXCH]" <[EMAIL PROTECTED]>
Subject: Just a thought...
Date: Fri, 18 Aug 2000 12:31:32 -0400
I've been wondering whether it would be viable to create an encryption
algorithm whose strength would be based upon the fact
that it could only be broken by a brute force attack and that the
encryption/decryption process took so long that going through
every possible key would take wayto long.
Example:
The encrypt/decrypt algorithm is designed so that it takes at
least 0.005s per byte (on a dual P III 600) no matter how it's
programmed.
The key size is 50 bits long.
Therefore...
A 1 MB file would take approx. 1.4 hours to encrypt/decrypt.
If 5 million computers (dual P III 600) attempted to crack this
file using a brute force method (ei. Decrypting the cipher text with
each key and comparing it to a copy of the plain text) it could take
them as long as 36, 000 years.
Obviously there are some cases in which this would be far to
time consuming for the sender and receiver, but if this were
proven to be 100% secure I'm sure there would be some parties who would
be willing to make these kind of sacrifices.
The question comes to mind, why would anyone use this algorithm
when there are already much quicker algorithms which
have yet to be proven faulty. I guess it's just cause I've been thinking
about this for a while and I have the distinct feeling that
there is something I am overlooking.
If anyone has heard of this kind of thing before or knows of any
papers related to this It would be much appreciated.
Thanks in advance!
Shawn Simister
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Breaking Simple XOR Encryption
Date: Fri, 18 Aug 2000 15:44:29 GMT
Peter wrote:
> I would appreciate an explanation of the attack that is
> used against simple XOR "encryption" schemes.
The first thing to understand is that XOR is *not* an
encryption scheme, nor a class of such schemes; it is
just a primitive Boolean-logic operation that has many
uses, including as a *component* in some encryption
schemes (but not in others). Knowing that XOR was used
in a scheme does not tell one nearly enough to make use
of that information.
Different cryptanalytic attacks are applied against
different encryption schemes. I don't have a copy of
Schneier's book at hand at the moment and thus I don't
know which *specific* method he was talking about. For
learning cryptanalysis in general, there are better
texts than Schneier's.
------------------------------
** 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
******************************
