Cryptography-Digest Digest #414, Volume #14 Wed, 23 May 01 04:13:01 EDT
Contents:
Re: "computationally impossible" and cryptographic hashs (Nicol So)
Re: Apology to Cloakware (open letter) ("Brian Hetrick")
Re: Unix file encryptor (William Ahern)
Re: PRNG question from newbie (Paul Crowley)
Re: OAP-L3: "The absurd weakness." (Anthony Stephen Szopa)
Re: survey (Pascal Junod)
Re: RSA private key size (Tim Woodall)
Re: OAP-L3: "The absurd weakness." (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Tue, 22 May 2001 22:36:56 -0400
Reply-To: see.signature
David Wagner wrote:
>
> A mathematical function has the property that if you give it the
> same input twice, you'll get the same output. That's part of the
> definition.
>
> A randomly-chosen (or pseudorandomly-chosen) function is just a
> function, so it has the same property.
>
> The phrase "behaves like a function that produces random output"
> is meaningless, because if it produces random output, it might produce
> different outputs on the same inputs, which means that it is not a
> function after all.
The term "random function" is used in more than one sense. In one sense,
it refers to a function chosen uniformly at random from the set of all
functions with a given domain and codomain. In another, it refers to a
function whose values are random variables. I've seen the latter
referred to as a "probabilistic function" as well.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "Brian Hetrick" <[EMAIL PROTECTED]>
Subject: Re: Apology to Cloakware (open letter)
Date: Wed, 23 May 2001 02:37:07 GMT
"JPeschel" wrote ...
> I've never heard good poetry critics talk about "identifying and
> recovering information sidebands" of text! Is this your way of
> making the subject on-top for sci.crypt? :-) Often, in most good
> litetature, the speaker does not equal author.
No, poetry critics talk about tone, connotation as opposed to
denotation, image range, concreteness, tautness, luminscence, subtext,
and a bunch of other terms that boil down to identifying and
recovering information sidebands. Robert Lowell's "Eye and Tooth"
(see, e.g., http://www.geegaw.com/sadpoetry/lowell.html), for example,
is very specifically and highly redundantly about sexual shame, but
Lowell is fairly approachable -- enough so even I can figure out where
he's going. In good poetry, of course, the information sidebands are
deliberately placed there by the poet. And good authors are entirely
comfortable synthesizing speakers.
> I suppose everyone (or everyone who cares) is trying to figure out
> who "Just Looking" is. If he's a regular here, he's fairly literate,
> seems to delight in sarcasm, and isn't above kicking a guy when he's
> down.
The bozo detector meter reading was regarding "Just Looking"'s post.
Sorry if that was unclear.
------------------------------
From: William Ahern <[EMAIL PROTECTED]>
Subject: Re: Unix file encryptor
Reply-To: [EMAIL PROTECTED]
Date: Wed, 23 May 2001 02:48:08 GMT
Arik Shelter wrote:
> I am looking for a command-line Unix file encryptor that uses 128 bit (or
> higher) encryption. Does anyone know of anything out there besides PGP
> (too much $$$) or GnuPG (not recommended for production environments) ?
(lib)mcrypt. it has a huge suite of symmetric ciphers available, a nice
library to access them, and a util (mcrypt) made just for what you want.
the url is on freshmeat.net
------------------------------
Subject: Re: PRNG question from newbie
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Wed, 23 May 2001 05:34:14 GMT
Stefan Lucks <[EMAIL PROTECTED]> writes:
> The paper I mentioned above indicates that something similar cannot exist
> for Random Oracles.
The way the paper works is this. The normal security assumption is
that every party has access to the Random Oracle. But the paper sets
up a situation in which one party is denied access to the Oracle at a
crucial point, because that party is specified to be an agent running
on a plain Turing machine, which by definition does not have
instructions for accessing the Oracle. Then the protocol is shaped
to be insecure if that party were able to access the Oracle anyway.
Thus, when you substitute any computable PRO for the Random Oracle,
the protocol fails, because the agent running on the Turing Machine
can run the code implementing the Oracle and thus access it when it
shouldn't.
If there were some way we could make precise the idea of a Random
Oracle that any Turing machine gains "magical" access to, perhaps the
discrepancy the paper points to could be closed?
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Tue, 22 May 2001 23:08:37 -0700
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >I have addressed this problem some time ago with my explanation of a
> >proposed Version 5.0 that has been on my web site for over a year now.
>
> Do you remember someone claiming they could break OAP-L3 Version 5 and
> challenging you in public? Did anything come of it?
>
> Here's a URL to refresh your memory:
>
>
>http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=8b16a21ca43f3359,2&seekm=8u9t8s%2466h%241%40nnrp1.deja.com
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOwaogF+t0CYLfLaVEQIgrACeIb6N2FEn5y+4A1YLK74RdGw2IeQAoN0N
> gNe+W4qt4iMLNFcLzU4Cnuxr
> =w7o9
> -----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/
I looked over my web site and scanned the Version 5 info.
There are several implementations explained. Which implementation
of Version 5 are you referring to?
------------------------------
Date: Wed, 23 May 2001 08:21:18 +0200
From: Pascal Junod <[EMAIL PROTECTED]>
Subject: Re: survey
On Tue, 22 May 2001, Tom St Denis wrote:
> > g) Most of us are quite busy and don't have enough time to read carefully
> > what you write.
>
> Which is ironic because I know with 90% certainity that you have downloaded
> all my papers including MDFC, NA and TC15 ...
That's right. But there isn't an ounce of irony in my previous sentence. I
have used the word "carefully". Just have a look at a paper is not at all
the same thing than reading it and thinking about it and proof every
sentence, theorem, ...: there is a gap of several hours ! So I keep your papers
on my laptop in order to have them for my retirement time ;-)
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Security and Cryptography Laboratory (LASEC) *
* INF 240, EPFL, CH-1015 Lausanne, Switzerland ++41 (0)21 693 76 17 *
* Place de la Gare 12, CH-1020 Renens ++41 (0)79 617 28 57 *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: [EMAIL PROTECTED] (Tim Woodall)
Subject: Re: RSA private key size
Date: 23 May 2001 07:28:40 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 22 May 2001 21:07:11 GMT,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
<snip>
>... If e=5, then d=5 ...
What fun. A secure replacement for ROT13 :-)
Tim.
--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.
http://locofungus.2y.net/ http://www.locofungus.btinternet.co.uk/
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Wed, 23 May 2001 00:49:06 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > Anthony Stephen Szopa wrote:
> > >
> > > > James Felling wrote:
> > > > >
> > > > > Anthony Stephen Szopa wrote:
> > > > >
> > > > > > James Fe
> > ><SNIP>
> > >weakness. ( Do you know why? Study the Enigma for a
> > > clue)
> >
> > "Note that this particular scramble process should only be performed
> > once on any MixFile(X) because for any number of times it is
> > performed an equivalent outcome can be attained by performing the
> > process just once with another appropriate ten-digit sequence. The
> > odds against will not change. "
> >
> > This is quoted right from the Help Files description for the Scramble
> > Process. Over the past couple of years there have been many many
> > people from all around the world who have downloaded the OAR-L3
> > software with these identical Help Files as well as many who have
> > the full version of OAP-L3 who only need to run the software and
> > read the incorporated help files to see for themselves that this
> > quote is in there.
>
> I pointed it out to you about two years ago. I seem to recall that that
> WAS NOT a part of the file until comentary on this group brought you to
> add it. ( my own plus those of others)
>
> >
> >
> > You did not bring this to anyone's attention. And I had no need to
> > take your advice on this point or change the Help Files because of it.
> >
> > Nowhere in the help files do I say or even imply that the processes
> > provided with OAP-L3 are exhaustive or that no other processes exist
> > that can be used for similar purposes. I could have sworn I said as
> > much in the help files but I could not find it. Maybe I missed it
> > when I looked for it or maybe I said as much in a news group post
> > some time ago. Either way, your coming up with another process is
> > not surprising in the least.
>
> True, if someone does extra work and provides a compatible plugin it can
> be made even more secure. Fine. However, I am attempting to critique the
> product as is. If the added features are brought in, then I will evaluate
> the system based upon them. Until that time I will look at the system and
> assume that that is how its maker intended it to be used.
>
> >
> >
> > The processes chosen for OAP-L3 were chosen for their simplicity and
> > ease of use. Generating and inputting a 14 digit sequence of numbers
> > is far easier than inputting a sequence of 105 numbers, and running a
> > process that uses only a 14 number input sequence is far easier to
> > implement and runs faster. The object of the software and the
> > processes in it is to attaining a desired OTP file security level
> > which makes cracking the encrypted messages generated using the OTP
> > files from OAP-L3 practicably unbreakable by scrambling the entire
> > 3,628,800 possible permutations of the digits 0 - 9 unpredictably.
> > This can be achieved using these 14 number sequences in the
> > particular processes concerned and other number sequences for other
> > processes in OAP-L3.
>
> I agree that the order 14 permutation is a usable size, but why 14, why
> not 7 or 5 or 15? There must have been some design choices there.
>
> >
> >
> > I am sure that your example of randomly ordering 105 permutation
> > groups is of some minor interest to some. Why settle for 105
> > permutation groups, or even 210, or 420, etc.? Isn't randomly
> > ordering only a 105 permutation group merely an inefficient way of
> > randomly ordering the 3,628,800 permutation group? Why not just go
> > for it and randomly order the 3,628,800 permutation group right from
> > the get go. Then you would have 3,628,800! possibilities.
>
> The order 105 group is the generic family that mix a mix file falls into.
> It will fill that space fairly slowly, and unevenly. This means that
> certian permutative structures will be more common thatn others. This can
> lead to a weakness. you also claim that repeating processes will always
> add security. the fact that it is part of an order 105 group meens that
> there is a cap upon how much randomness this permutation can contribute in
> sequential aplication. No, I am not claiming that it is insulficient
> merely that you have a tendency to throw numbers out without an
> apreciation of the phenomena associated there with.
>
> >
> >
> > Hope you get it. Do you get it?
> >
> > Here is a clue: if you randomly shuffled the 3,628,800 permutation
> > file from the get go then you wouldn't need any of the processes in
> > OAP-L3.
>
> Yes.
>
> > Furthermore if you randomly shuffled the 3,628,800 permutation
> > file from the get go then you wouldn't even need any random number
> > generator or encryption software at all.
>
> true.
>
> > You could just use your
> > random process to generate random numbers that then could be used to
> > encrypt messages directly.
> >
> > Are you simply arguing that if you do not use true random numbers in
> > encryption then you do not have random encryption, or that to use
> > random input to generate a stream cypher where you use more output
> > data than random input data provides less than random encryption, or
> > both?
>
> No. what I am saying is that the methods used have slow difusion, require
> alot of work and have weaknesses such as fixed points, poor mixing, and
> other such flaws.
>
> >
> >
> > So far, you seem to have sure gone out of your way to argue the most
> > fundamental encryption dogma. So far, you have not offered us
> > anything new except how to subtly obfuscate a well known principle.
>
> Really? So how would YOU fix that nasty fixed point issue?
>
> What about the other points I raise?
>
> >
> >
> > Mind you, I said, "So far." I am not through reading or evaluating
> > your reply post.
> >
> > Furthermore, the output from the random digit generator is not used
> > to encrypt messages. You must surely know this. And only about 70%
> > of the random digit output is randomly used to generate random
> > numbers from 0 - 255. And you should know that these random number
> > files are processed further before the final OTP file generation
> > process is used that takes more random user input. Your comparing
> > OAP-L3 to Enigma is the greatest enigma of you fundamental position.
>
> Of course I knew that. Your discarding does add strength. However, you
> still have a flaw very similart to enigma. in that the discarding is most
> strongly influenced by 1 of your 3 streams, and that the 0-9 set issue is
> still present just not 100% reliable. It allows prediction of the high
> bit in general better that random guessing. This is bad.( certianly not
> 100% compromising, given apropriate work has been done, but certianly
> suboptimal).
>
> >
> >
> > I will get back to you again on your reply post with more specifics
> > in a day or two.
> >
> > Thanks for the challenge.
You are obviously trying a little too hard to be a little too smooth.
If you want to claim that I took your advice and that of others on
this point regarding the scramble process, go ahead. But I am sure
you will agree that OAP-L3 is basically thoroughly based on
permutation manipulation. With this in mind you must agree that I
most probably am quite well versed in the simplest most fundamental
permutation transformations. If you think your claim of advising me
on the scramble process is believable then anyone who believes this
must be rather gullible. The transformation of permutations is
lesson #1 in linear algebra. But if you say it is so then I have
nothing else to say about this.
There were design choices made. And there is a very good reason I
chose 14. I mentioned it earlier. One reason is that the number
lends itself to easy implementation and ease of use for a user.
Also it provides a certain consistency within the overall program.
"there is a cap upon how much randomness this permutation can
contribute" Can you prove this or is this something we should all
realize on its face? Seems to me what you are saying is analogous
to saying that shuffling a deck of cards by splitting the deck in
two halves then interleaving the two halves card by card from each
half will certainly limit the outcome of the overall sequence of the
deck as compared to some other shuffle. Are you serious? Are you
claiming that there is no way that one can arrive at the same final
outcome sequence of a deck of cards if two different methods of
shuffling them are used?
Your arguments are ridiculous. "It will fill that space fairly
slowly" You realize that the space for three MixFiles is about
1E66,000,000 and 1E22,000,000 for one MixFile.
Each final output sequence occupies just one place in this entire
space. I claim I can fill one of these spaces faster with a
sequence of 14 numbers than you can using a sequence of 105
numbers. Yep. While your method has to search for each number in
105, my process just makes two passes counting off in sequence
either 1, or 2, or 3 or 4, etc. numbers and copying them to the
final output file. Now think about what you just said and you will
see that I am right.
"and unevenly"? Not so. If the user inputs a random 14 number
sequence then each random 14 number sequence has an equal chance
of being input as any other 14 number sequence.
"This means that certian permutative structures will be more common
thatn others." If the user inputs a random 14 number sequence,
after one running of the process there will be 14! = 87,000,000,000
possible outcomes. Run the process twice using another random 14
number sequence the second time and there will be (14!)^2 possible
outcomes. Are you saying that as this process is repeated one per
second in the time remaining in your lifetime that the number of
possible outcomes will be less than (14!)^(years remaining in your
life * 365 * 24 * 60 * 60)?
And are you saying that you know of a method to somehow determine
what the number of times this process was run and what the random
sequences used were in each running of the process by just examining
the final sequence output?
Or are you simply saying that you can predict how many times the
process is run and what the input is and what the final output
sequence of the MixFile will be before the user even generates the
random number sequences and runs the processes?
You ARE really good:
"the methods used have slow difusion, require alot of work and have
weaknesses such as fixed points, poor mixing, and other such flaws."
You must admit that all of these statements are generalities which
completely miss the point of the purpose of OAP-L3. Primarily you
have not quantified any of these points. And this is crucial in any
serious critique of OAP-L3. I believe that you have intentionally
neglected to mention these because your intention is to look good
while feebly attempting to trash OAP-L3. To have flagrantly ignored
any quantification to support your statements proves your intentions
beyond any doubt.
Your flaws are figments of your imagination. Do you refute that
running the process results in the possible outcomes such as: (14!)^
(number of times the process is run using random input)? And if not
is it significant? And why do you not mention the variety of
processes available to a user. This one process is not recommended
to be used exclusively. The software is to be used in its entirety.
Here is my last shot at a fixed target. "So how would YOU fix that
nasty fixed point issue?" (really pathetic innuendo: "nasty.")
I just told you. You use a random combination of the several other
methods.
Thanks for revealing some of what you are. Don't take that personal.
Much of what we are is not of our own doing.
You may confound some with your leaky arguments but I guess we get
what we pay for when we read one of your posts.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
