Cryptography-Digest Digest #485, Volume #11 Tue, 4 Apr 00 12:13:01 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
Encryption strength proportional to encrypted message length? ([EMAIL PROTECTED])
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
Re: Encryption strength proportional to encrypted message length?
([EMAIL PROTECTED])
Re: Cipher Contest ([EMAIL PROTECTED])
Re: Q: Entropy (Niklas Frykholm)
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Tue, 04 Apr 2000 10:18:19 -0500
Anthony Stephen Szopa blathered:
> "Trevor L. Jackson, III" wrote:
> >
> > Anthony Stephen Szopa wrote:
> >
> > > Now, for any of those interested, Version 4.3 will be available
> > > very soon. Here are the additions to OAP-L3 in Version 4.3:
> > >
> > > 1) you will get two more random number generators: they are
> > > exactly the same as the current one where only MixFile1 is
> > > rotated except that PRNG2 will only rotate MixFile2, and PRNG3
> > > will only rotate MixFile3.
> > >
> > > 2) you will get several other processes:
> > >
> > > you will be able to scramble every subsequent set of 14 arrays in a
> > > MixFile to any one of 14! sequences
> > >
> > > you will be able to reverse the order of each element in each array
> > > in a MixFile
> > >
> > > you will be able to reverse the byte sequence of an entire MixFile.
> > > (Keep in mind that each MixFile is compressed using BCD so each
> > > byte contains information for two digits.)
> > >
> > > you will be able to reverse the array sequence of an entire MixFile
> > >
> > > you will be able to add 1 - 9 to each element in all arrays in a
> > > MixFile
> > >
> > > you will be able to shift all elements in each array in an entire
> > > MixFile
> > >
> > > These additional processes will greatly increase the possibilities
> > > of ordering the MixFiles thus making the MixFiles that much more
> > > difficult to determine
Agreed. This might give you an efective keyspace (versus kiddie cryptography) in
the neigborhood of some of the AES cyphers. And your setup time is only 100X longer,
and your encryption runns at only 1/4 their speed(or worse). In addition people
really love having large key files on their HD. This program offers so much, how
could I resist pruchasing it.
>
> >
> > But according to your advertising the older product provided "absolute
> > privacy". Why would anyone want more than that?
> >
> > >
> > >
> > > The additional PRNGs will provide more random numbers from which
> > > to create the OTPs, again making predicting the OTPs that more
> > > improbable.
> > >
> > > (I like to say that much more impossible.)
> >
> > If your claim that much more is possible is true than it must be the case that
> > there are very many holes in your absolute privacy. One can only improve an
> > imperfect product.
> >
> > Please stop posting in sci.crypt until you believe your product does not need
> > more strength.
Agreed. If you had a working product that was "good enough to offer absolute
privacy" then either
1) you were mistaken about your earlier claim-- no shame in admitting that, though
it makes me wonder about your ability to produce a good code( part of code design is
attempting to develop viable attacks vs. your own algorithim) -- and the weakness
that this corrects should be publicised, I will wait until your program is out of
alpha/beta testing( when the code is fixed and final) before purchasing/examining
your code. I will advise others that this is a "pre-release quality" product until
you inform me that the code is final.
or
2)you were deliberately deceptive previously which makes me doubt the product
entirely,
or
3) These upgrades improve a non cypher related aspect of your program such as speed
or user interface.( both are much needed improvements, but I do not see how adding
more steps to mix file generation makes it work faster or more efficient.)
If this improves some other aspect not mentioned here feel free to enlighten me as
to what it was.
or
4)These are frivolous upgrades intended to make the program look more impressive
>
>
> As you may be aware, there is an extremely large key space
> available with OAP-L3. Adding a few more processes is
> tantamount to approximately doubling the "through put"
> to this very large key space. It does make determining
> the key phenomenally that much more difficult. No one
> has to use them. They are simply made available. Their use
> is up to the user. And my position remains the same.
Excuse me -- "doubling the throughput of a keyspace" -- What do you mean? This
sounds like doubletalk -- like "reversing the polarity of the neutron flow" -- it
sounds impressive, but is empty of meaning. Please describe what their puropse is in
a manner that means something. Thank you.
>
>
> Address the software theory and processes and procedures with
> factual support. Are you not up to it?
I agree. Explain why the procedures that you have chosen were chosen with the values
they have. Argue your position with reason not buzzwords.
>
>
> You should spend more time devising your own encryption method
> and impress us with that. You are not very convincing telling
> me of what I should do.
------------------------------
From: [EMAIL PROTECTED]
Subject: Encryption strength proportional to encrypted message length?
Date: Tue, 04 Apr 2000 15:17:26 GMT
Dear All,
Just a beginner question:
Is the Encryption (Public/Private Key) strength proportional
to the encrypted message length???
I think about this:
Two party exchange a message (XML). I want a 3rd party VALIDATE
the message structure (with a DTD) without know the message content.
I can realize this by only encrypted the content.
But, my question is: is it easier to decrypt a lot of small strings
than a big string???
Thank you for your help,
Patrice Krakow
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Tue, 04 Apr 2000 10:36:43 -0500
Anthony Stephen Szopa wrote:
> Taneli Huuskonen wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> > <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > >I'll ask you again: how many raw random digits from the random
> > >digit generator will you need? I will supply them. You can
> > >then give us what you have determined to be the subsequent
> > >raw random digits from the random digit generator.
> >
> > >Then I will provide the key for the software where we all can see
> > >that the random digits I gave you were in fact the ones generated
> > >from the software using this key.
> >
> > OK, fine - no BS, just the facts. However, I have trouble handling
> > very large files (I'd need a couple hundred million digits for
> > predicting the entire output stream), so I propose the following:
> >
> > You supply twenty blocks of a thousand consecutive digits each.
> > Between each block and the next, the "Rotation" is incremented by 10,
> > and the "Offset" is reset to zero. In other words, the starting digits
> > of two consecutive blocks are 10! * 10 places apart in the full output
> > stream of the random digit generator. You may start with any value for
> > the Rotation that you want; just make it known afterwards.
> >
> > You can make the digits available in any reasonable format: ASCII or
> > BCD, all the blocks concatenated in one large file or 20 small files,
> > zipped or not, made available by HTTP or FTP, or e-mailed to me.
> >
> > I will make a thousand predictions of this form: "The digit at Rotation
> > 234, Offset 43 is 5." If you can find one incorrect prediction, I've
> > failed. So, my chances of succeeding by chance are 1 out of 10^1000.
> >
> > Deal?
> >
> > Taneli Huuskonen
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 5.0i for non-commercial use
> > Charset: noconv
> >
> > iQA/AwUBOOjmAV+t0CYLfLaVEQJQHgCdGjNvXKyM32E4mP8dW74Q8i7YPDQAn0rD
> > 1Q6v3/9KiZOajAl/3FjT9CKU
> > =DbCx
> > -----END PGP SIGNATURE-----
> > --
> > I don't | All messages will be PGP signed, | Fight for your right to
> > speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> > the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
>
> You certainly realize that there is at least one person in this
> news group that actually thinks that the random digits from the
> random digit generator are used directly in the encryption
> process. This is because he hasn't a clue.
>
> There may even be some in this news group that think that the
> random numbers from 000 - 255 calculated directly from the random
> number generator are used directly in the encryption process.
> These people also haven't a clue.
>
> For any who need a lesson: first a random digit triplet is formed
> directly from the random digit generator. If this number is
> greater than 767 it is discarded. Otherwise this number is
> divided by 3 and the remainder is truncated. This and all
> subsequent random numbers from 000 - 255 calculated in this manner
> are then stored in RandOut files usually having a length of
> 18144000 binary bytes each. These several RandOut files are
> further processed repeatedly using as many as ten different
> processes. All processes use true random user input as parameters.
> Finally, these RandOut files are combined randomly in the OTPs again
> using true random user input. This is it in a nutshell. Read the
> documentation available in the Help Files for more details at
> http://www.ciphile.com
Look. If your RNG is flawed it is flawed. Perhaps this multitude of steps
makes it harder to attack directly. My bet is you have an algorithim with a
complexity of attack in the neigborhood of the present AES cyphers -- maybe
worse. Justify why I should use your closed source product that does not
offer me more security than an AES algrotihim, offers less flexibility,
slower operation, less robust examination, poor documentation, and a poor
user interface vs Oh say PGP or even something like David Scotts ScottXu.
Make your case.
>
>
> Let's now discuss your proposition strictly regarding the random
> digit generator (this is not a discussion about the OAP-L3 software
> as a whole.)
>
> First let me say this: everyone knows that computer software
> programs are entirely deterministic. Knowing the algorithm and
> the inputs you can predict the output before even running the
> process if you are so inclined. You can also go the other way.
>
> Regarding encryption software I like to think of there being an
> explicit key and an implicit key. It all depends on your point
> of view.
>
> The explicit key is the key I will use to create the three MixFiles
> that I will use as input to the OAP-L3 random digit generator
> software. Then I will generate the random digit streams you seek.
>
> The implicit key is what you will be forced to use. This key is
> the raw random digit output from the random digit generator.
> Theoretically you may be able to determine the original MixFiles I
> actually used. The more raw random digit output you have the more
> possible this becomes: perhaps a few hundred million (I doubt it)
> or a few hundred billion (possibly) or a few trillion (probably)
> raw random digits in sequence directly from the start of the random
> digit generator might do it exactly.
>
> Suppose I do this: I will give you 21 consecutive blocks of
> 3,628,800 digits. The software automatically will rotate and
> reset the increment to zero after each block. You just choose
> the first 1000 or 10,000 or 100,000, etc. digits as you like
> from each file. You can even check your results from the first
> 20 blocks with block 21. I will write these to a CD-R and mail
> it to you.
>
> At my option I would like three tests: this being the first.
> Just give me any address you like. I will try to get it in the
> mail to you within a week. Keep in mind that I am very busy
> trying to get this next OAP-L3 Version 4.3 out.
>
> Now, let us take a brief moment to think about your statement
> that there is a flaw in the random digit generator. You choose
> to call it a flaw. Think about this: we all know that computer
> software is deterministic. By analysis of the process and with
> enough output, anyone can determine subsequent output because
> you will have effectively determined the MixFiles. So you have
> done nothing but confirmed what we already had known (or should
> have known.)
>
> Next, you must agree, that the only way to exploit this fact is
> to have basically unlimited access to the raw random digit output
> of the random digit generator. How is anyone going to get this in
> a real life situation except like I am giving it to you now? If
> you could get the raw random digit output from the random digit
> generator you would certainly have access to the MixFiles or better
> yet, the AutoFile key itself. And possibly the final OTPs.
>
> So what are you proving that is detrimental to the security of the
> OAP-L3 system? You are merely solving a problem in simultaneous
> equations, or solving multiple equations with sufficient numbers
> of constraints (the raw random output from the random number
> generator.)
>
>
> You could not do this unless I gave you the raw random digit output
> of the random digit generator in the first place. Are you next
> going to say that you can crack OAP-L3 encrypted messages if I
> give you the OTPs and then conclude that you have proven your
> statement and therefore OAP-L3 is flawed? Basically this is what
> you are saying and attempting to convince others of with this
> inconsequential "test."
>
> So, if you do manage to predict a few or all the random digits
> subsequent to the random digit stream I provide you with, so what?
You claim that your crypto product is highly secure. You claim that any file
encrypted with it is secure, and if there is a useful attack vs. the
generator this means that in all likleyhood there is a useful attack vs. the
whole system. Yes it may not be "broken" by this, but the security provided
is MUCH less than the amounts claimed if there is a predictable hole in the
RNG.
>
>
> You will have shown us nothing that anyone can use to crack the
> software or any of the encrypted messages using OAP-L3.
>
> Do you disagree? Why? How?
Ever heard of a "Known Plaintext Attack"? It is a very basic concept.
Probably as old as cryptography itself. You intercept a message, and later
find out what it contains say from a prinout that you aquired or the like.
You then have raw stream output available for analisys as your stream cypher
is simply combined with the plaintext.
>
>
> I do agree that you can at least show your employer that you have
> done something in the hopes of justifying your salary but
> unfortunately you have gotten no further to the goal of cracking
> the OAP-L3 software.
>
> Post the address.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption strength proportional to encrypted message length?
Date: Tue, 04 Apr 2000 15:47:58 GMT
[EMAIL PROTECTED] wrote:
> Two party exchange a message (XML). I want a 3rd party VALIDATE
> the message structure (with a DTD) without know the message content.
> I can realize this by only encrypted the content.
I may be overly dense this morning but I can't think of any way to
validate a docuent instance without the tags. Are you planing on
encrypting only the data between them?
If so, then yes, this is _alot_ weaker than encrypting the longer
document. Not because the strings are shorter, but because you have
access to so much info about the structure of the plaintext.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cipher Contest
Date: Tue, 04 Apr 2000 15:42:39 GMT
Sir,
In article <[EMAIL PROTECTED]>,
...
> Quoting the original message:
>
> > Let the right side XOR = B. Here is a four round differential
>
> > Left Right
> > 0 B probabilty of a clash = 1 because B is chosen
>
> > B1 0 p = 1 since the selectors are equal
>
> > 0 B2 p = 1/(2^8), a lucky hit is needed
>
> > B3 0 p = 1
>
> > 0 B4 left side = (L0^L1) = 0,
> > right side (R0^R1) = any value
>
> it is not clear, which way does the procedure go - from
> 1-st round forward or from last round backward. However,
> in any case, the behavior of differences seems to be
> misinterpreted.
>
> Case 1 - forward.
> In this case apparently the difference between the right
> halves is chosen so that the hashes of the 2 right sides are
> the same, and the same multiplier is applied to left halves
> in both cases. Left halves are supposed to be identical.
> This means that in both cases after the first round left
> halves will remain identical, and the multiplier selected
> before the second round will be the same (although different
> from the previous one).
> Here, obviously, the goodies end - the second multiplier
> will be applied to different right halves, and there is no
> realistic way of predicting the values of the resulting
> right half products - modular multiplication does not care
> about XOR differences and does not preserve those, especially
> with randomly chosen multipliers.
>
> The previous table must look this way:
> (B, B2, B3, B4 - differences)
>
> Rd L0^L1 R0^R1
> 0 0 B probabilty of a clash = 1 because B is chosen
> 1 0 B p = 1 since the selectors are equal
> 2 0 B2 B2 can be any value
> 3 B3 B2 B3 and B2 can be any value
>
> 4 B3 B4 left side = (L0^L1) = any value,
> right side (R0^R1) = any value
>
This is the right way. If a cipher is symmetric a differential attack
can run either way. Differenitial attacks are generally assumed to run
on the encryption side unless otherwise stated, as far as I can tell.
Lets examine your table. You neglect the probability of a clash in the
hash.
Rd L0^L1 R0^R1
0 0 B probabilty of a clash = 1 because B is chosen
1 0 B p = 1 since the selectors are equal
2 0 B2 B2 can be any value
True B2 can be any value B2=(b0^b1). Now suppose hash(b0) = hash(b1).
Since the hash ranges from 0 to 256, there is a least 1 in 256 chance of
this occuring.
3 0 B3 The left side must be zero because the hash is equal.
Same thing for this round, prob = 2^-8
4 0 B4 prob = 2^-8
The above characteristic has a chance of 2^-8 * 2^-8 * 2^-8 = 2^-24.
I am a bit confused about your round structure. Are we discussing the
Feistel style network where left and right are switch or a double round
structure as in the code.
I was assuming a Feistel style with left and right blocks switching
after each round. You appears to be using the double round structure.
I believe the output is equivalent.
Run that little program, I included in the previous message. It will
find the differentials with the predicted probability.
The follow up question is if the key can be recovered given a
predictable output differential. I believe that it can using the
seiving attack.
Dont' confuse 2^83 search time with 2^83 plaintext. The seiving attack
on eight rounds will take 2^(8*((8-2)/2) = 2^24 plaintexts to find a
good pair. With 2^64 plaintext the attack will find 2^40 good pairs on
average, plenty.
Also, dont confuse number of differential -pairs- with plaintexts. To
get a pair for Letstief when need the hash of the right side to collide
and the left side to be equal. For any plaintext then, 2^24 pair can be
generated.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Niklas Frykholm)
Subject: Re: Q: Entropy
Date: 4 Apr 2000 15:54:18 GMT
>My point is that the difficulty lies in quantifying (as against
>qualifying) entropy in actual practice. This conforms to what
>you said. To exaggerate a bit, entropy seems like beauty. Most
>people would agree that some of the famous stars are prettier
>than an average woman, but it is hard to say by just how much or
>to compare two of the stars. Under such conditions, I suppose
>that the question could be legitimately asked whether arguments
>in practical situations employing entropy, say, whether a password
>has more entropy than another or how much entropy one has
>collected through certain means, shouldn't be considered to be
>essentially fuzzy and at least looked upon with one or several
>grains of salt.
True, the mathematical definition of entropy may have little to do with the
actual difficulty of guessing a password.
For example, suppose I roll a dice. If the dice shows 1-3 I select the
password "akjhdeiune2894n", if the dice shows 4-6 I select the password
"kfhr3487nfkhed3". Now the entropy is only 1 bit, but the password will
still be hard to guess, because the attacker does not know how I selected my
password.
I. e., the choice of the password selection procedure in itself carries an
ammount of entropy, so perhaps the real entropy is entropy(choice of
password selection procedure) + entropy(choice of password). But then of
course, if the attacker does not know how I selected my password selection
procedure we must add an additional term entropy(choice of way of selecting
password selection procedure) and so on ad infinitum... ;)
Here is another possible definition of the entropy of a password:
The number of extra bits required to specify the password
given all the information in the attacker's brain
// Niklas (who enjoys the occasional swim in the lake of weird science)
------------------------------
** 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
******************************
