Cryptography-Digest Digest #76, Volume #13 Thu, 2 Nov 00 15:13:00 EST
Contents:
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Is RSA provably secure under some conditions? (Philip MacKenzie)
Re: 3-dimensional Playfair? (Mok-Kong Shen)
Re: Newbie about Rijndael ("Brian Gladman")
Re: BENNY AND THE MTB? ([EMAIL PROTECTED])
Re: Certicom's ECC Implementation (DJohn37050)
Re: Is RSA provably secure under some conditions? (Jan Fedak)
Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your Thesis!
([EMAIL PROTECTED])
Re: Crypto Export Restrictions (Scott Craver)
Re: BENNY AND THE MTB? (Bryan Olson)
Re: Give it up? (Tom St Denis)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 10:40:32 -0800
David Schwartz wrote:
>
> Anthony Stephen Szopa wrote:
>
> > Suspect?
> >
> > Anyone who would make such a claim and not support it is clearly a
> > nasty person.
>
> I'll let people judge for themselves, but the following statements on
> your web site are not exactly encouraging:
>
> "Uses no mathematical equations"
>
> "We claim that messages properly encrypted using the full implementation
> of OAP-L3�: Original
> Absolute Privacy - Level3 � (patent pending) encryption software are
> practicably unbreakable. If you
> can demonstrate a generally practicable systematic method for
> consistantly breaking these encrypted
> messages within 180 days from your date of purchase you will recieve a
> full refund."
>
> "The next upgrade, Version 4.3, will include three new routines to
> process the random array files called
> MixFiles: 1) a shift routine where the user may decide to shift each
> element value within an array left or
> right by 1 to 9 elements, 2) a "flip" routine that will reverse the
> order of array element values in each
> array, 3) an add routine where each array element value consisting of a
> digit from 0 - 9 will have a user
> determined number from 1 - 9 added to it, with any result exceeding 9
> having 10 subtracted from it."
>
> "Let me emphasize again using the first example above: your key will
> generate 2920 data bytes. And
> these 2920 data bytes will have a security level equivalent to 2000 bits
> and enable you to encrypt
> 9.2E15 bytes. Can you spare the space on your hard drive to store 2920
> bytes?"
>
> "Okay. So now you have generated the original encryption data file
> containing all 3,628,800 possible
> ten-digit permutations of the digits 0 - 9 with no repeats in ascending
> order. How will this file be used?
> To generate the random numbers that will ultimately be used to create
> the OTP files, three files
> containing 3,628,800 ten-digit permutations of the digits 0 - 9 with no
> repeats are required. They will
> be called MixFile1.otp, MixFile2.otp, and MixFile3.otp. Each of these
> files must be thoroughly shuffled.
> That is to say, the permutation order must be randomly rearranged in
> each file. There are several
> processes the software uses to shuffle the permutation order in each
> MixFile(X) individually, and one
> that shuffles the MixFile(X)s all together."
>
> If course, the biggest problem is that no explanation is given of where
> the randomness actually comes from. You can mix numbers to get random
> numbers, but you need randomness in order to mix. Where does the initial
> randomness come from? No clue.
>
> DS
You asked the $64,000 question. This is why I posted all the Help
files on the web site.
If you want secure encryption enough you should begin reading them.
They are not very long.
Obviously you have read some of the material.
It is all there. You did not quite read far enough.
>From the Theory web page:
"Here are a few practicable solutions to your random number needs.
Get two decks of standard playing cards. Each deck has four suits
from Ace - King and two Jokers. Take two jokers from one deck and
place it in the other deck. With a pen assign one of the four suits
to each Joker. So now you have one deck with 56 cards with four
suits and 14 cards per suit."
Search the Theory web page for this text then read further.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 10:42:14 -0800
CiPHER wrote:
>
> In article <[EMAIL PROTECTED]>,
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> > Anyone who would make such a claim and not support it is clearly a
> > nasty person.
>
> *waggles fingers* OoooOOOooo! 'Nasty person'! lol
>
> --
> Marcus
> ---
> [ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Thank you for your intelligent input.
Like we really need more of this.
------------------------------
From: Philip MacKenzie <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Thu, 02 Nov 2000 13:32:34 -0500
Roger Schlafly wrote:
>
> Philip MacKenzie wrote:
> > ...
> > I think most cryptographers would use the phrase
> > "Proof of security in the random oracle model"
> > ...
>
> Pointcheval and Stern have an article in the Summer 2000 Journal
> of Cryptology in which they use "provable" in quotes, and
> say:
>
> We use the word "arguments" for security results proved in
> this [random oracle] model.
>
OK, not all cryptographers, I guess. :)
> > The question is, when non-cryptographers ask
> > about a scheme that has a proof in the
> > random oracle model, what do you tell them?
> > Do you try to explain the random oracle model?
> > Do you tell them it has a "heuristic proof"?
> > (what in the world does that mean?)
> > Do you tell them you have some heuristic
> > arguments for security? That sounds pretty
> > weak, and some scheme without a proof of security
> > in the random oracle model could be described
> > as having heuristic arguments for security also.
> > Or do you simply say it's proven secure?
>
> So you are practically admitting that you are saying "proof"
> because it sounds good!
>
Actually, I think I'm admitting that I say "proof" because
I feel it is often the most accurate one-word description
of a result of this type. The most accurate (or at least
what I consider to be fairly accurate) 8-word description
would be "proof of security in the random oracle model"
I could even be more accurate given more words.
>
> I think it is fair to say you have security arguments, or
> even proof that certain types of attacks are not possible,
> but I guess you won't think that sounds good enough.
>
Actually, "proof that certain types of attacks are not
possible" sounds fine, but "security arguments" sounds
like "well, it looks pretty secure". Maybe "formal security
arguments" would be better, but if we're up to 3 words,
"random oracle proof" may be more accurate.
> The only reason you can get away with calling these proofs is
> that no one has any real security proofs, except for one-time
> pad.
>
But even one-time pad proofs are based on the
assumption of perfect randomness, something that
is notoriously hard to achieve in the real world.
(Side note: Stephenson presents this idea in an
amusing way in his book Cryptonomicon.)
All proof statements are of the form "If some assumptions are true,
then some result is true". The statement of one-time pad
security is something like "If two parties share a perfectly
random string of bits of size n, then one can encrypt a
single message of size n for the other, with the
encryption being information-theoretically secure"
(OK, that's a horrible statement of the theorem, but you
get the idea.)
So my point is, I'm not sure why you disparage my use
of the word proof. It's a completely accurate description
of many results--in a certain model and assuming certain
functions are hard to compute, a certain scheme is
_provably_ hard to break.
> Yes, the random oracle model is useful. Altho sometimes I get
> the impression that people will take a scheme, and keep adding
> hash functions to it until they get a random oracle proof.
> It sounds like they've changed an insecure scheme to a secure
> scheme, but we really don't know for sure that any security
> has been added at all.
Well, we don't know anything for sure, since P may equal NP,
but I understand what you're saying, and in some sense,
I think you're right. But I'd be much more comfortable
with a scheme proven secure in the random oracle model
than one not proven secure in any model.
-Phil
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 3-dimensional Playfair?
Date: Thu, 02 Nov 2000 19:48:04 +0100
Daniel wrote:
>
> The largest problem to overcome will be the size of the CT (= 2 times
> the length of the PT - this is the case for a typical Playfair).
I suppose you erred. Playfair encodes a couple of characters
to another couple via the matrix, thus preserving the length.
M. K. Shen
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Newbie about Rijndael
Date: Thu, 2 Nov 2000 18:57:34 -0000
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Bob Deblier) wrote in
> <[EMAIL PROTECTED]>:
>
> >mac wrote:
> >
> >> Hello!
> >>
> >> I'm a newbie with Rijndael, block ciphers and cryptology in general.
> >> I've downloaded Mike Scott's C implementation from Rijndael's home
> >> site. I'm trying to figure out how it works and I have one question.
> >> When I want to encrypt a string of, say three characters(bytes), what
> >> do I have to fill up the rest of the array(another 14 bytes). I had
> >> problems when passing just a null terminated string that is much
> >> shorter that 16 bytes to encrypt/decrypt block functions. It works
> >> fine when I pass a 16-byte long null terminated array. I know this
> >> seems pretty dumb question to you, but I don't understand everything
> >> what's happening in encryption/decryption functions and it's killing
> >> me.
> >>
> >> Thank you very much for any explanations, thoughts or code.
> >
> >On http://www.rsalabs,com, find the document describing PKCS#5; it offer
> >a method for padding and unpadding data blocks. If I recall correctly,
> >the document describes this method for a blockcipher with a block length
> >of 8 bytes, but the method can easily be extended to 16 byte blocks:
> >
>
> Actually those padding methods suck. It might be better to
> do padding in a way that does not add information to the file
> being encrypted see Matt code I have a pointer at mysite.
And it might not.
Brian Gladman
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: BENNY AND THE MTB?
Date: Thu, 02 Nov 2000 18:54:52 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> : (there will be tiny biases in the ciphertext which can be compressed
> : further [...]
>
> That would be suprising. Usually attempts to compress cyphertext
result
> in slight expansion - not slight compression.
It's not really surprising. Consider that the ciphertext is a language,
or at least an obfuscated representation of one. If you can gather
enough information about that language you can build a proper method of
compressing it. In English that tree has a natural granularity of 26
symbols, so the most simplistic compression would identify a unique
encoding with each of those 26 characters that resulted in the smallest
compressed text possible under the circumstances. Under a cipher like
Rijndael (or any other 128-bit block cipher) the natural language is
2^128 symbols, so if we can gather statistics on those 2^128 symbols we
can compress the output of Rijndael just as any other file. The problem
lies in collecting the information about those 2^128 symbols. Our
current encryption schemes are not designed to deal with what appears
to be random data, but that doesn't mean there won't be some order to
it, in fact the order to it is proven by the fact that we have a
generator smaller than the language.
Joe
ps Since there seems to be some confusion allow me to take a moment and
introduce this name and link it with myself, I am the same Joseph
Ashwood that posted under [EMAIL PROTECTED] I have switched because msn
doesn't like taking posts from me.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Certicom's ECC Implementation
Date: 02 Nov 2000 19:06:10 GMT
Certicom does have some patents on implementation speedups, these can be for
particular types of curves or for all curves, depending. For example, a field
operation speedup will translate to an ECC speedup.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Jan Fedak)
Subject: Re: Is RSA provably secure under some conditions?
Date: Thu, 2 Nov 2000 09:24:03 +0000 (UTC)
Is it, really? Could you point me to some literature that says so or
explain it here?
Thanks, Jan
>Here's the obvious example: s is a signature of m if
>
> * s is a Rabin signature of m or
> * s is a program that produces the same result as the hash function,
> at the same speed, for several random inputs.
>
>If factoring is difficult then any attack on this system has low
>probability of success for a uniform random hash function. But the
>system is easily breakable as soon as you plug in a real hash function.
>
>---Dan
--
Jan Fedak talk:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Linux - the ultimate NT Service Pack.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your
Thesis!
Date: Thu, 02 Nov 2000 19:26:12 GMT
In article <8ts9r8$odn$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Oh. You mean that that the prng sequence is s, p(s), p(p(s)), ...,
> where s in G is a random seed and p : G -> G is a group homomorphism.
> Then you take a cipher c : G -> G (also a group homomorphism), and
> apply it to the current item in the prng sequence; thus, the output
> of the enciphered-prng-sequence is c(s), c(p(s)), c(p(p(s)), etc.
> Did I get that right? Is that what you meant? Seems like an
> interesting question.
>
> (Note, by the way, that the composition c o p of homomorphisms c,p
> is itself a homomorphism. This might be useful.)
>
In a cryptographic PRNG, the job of c is to keep you from deducing s.
The job of p is to keep the internal state unpredictable so c can do
its job.
c can be very weak. In fact, you can do
i=c(s), j=c(t=p(i,s)), k=c(p(j,t)), etc
which makes c an intermediate step of p, wasting no effort on c at all.
That's how ISAAC works. RC4 uses m[x+y] for c. I wonder why Ron didn't
use x^y and save some instructions.
- Bob Jenkins
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: 2 Nov 2000 19:33:42 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>CiPHER wrote:
>>
>> *waggles fingers* OoooOOOooo! 'Nasty person'! lol
>>
>
>Thank you for your intelligent input.
>
>Like we really need more of this.
...," he says, posting a follow-up.
Have you posted the algorithm yet for your pseudorandom
number generator, or is it still just the "help files?"
IIRC people could not gleen exactly how the algorithm
worked by reading those files, and thus could not subject
it to analysis.
By the way, since your PRNG uses permutations, it uses
"mathematical equations." If you don't think it involves
math because it uses compositions of permutations rather
than products of large integers, then you need to read some
abstract algebra textbooks. And your customers need to
_know_ that you need to read some abstract algebra textbooks.
You don't need to give out the source code, but something
like pseudocode for the generator part would be ideal.
-S
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Thu, 02 Nov 2000 19:46:51 GMT
Tim Tyler wrote
> [EMAIL PROTECTED] wrote:
> : The argument is fairly simple. If you chop all but 8-bits of
> : a Rijndael block, the decryption is one of 2^120 possibilities.
> : Therefore is Matt's version of "Rijndael" can in fact encrypt
> : to a block of 8 bits (more importantly decrypt that block)
> : there is no possible way for it to be the Rijndael that was
> : reviewed as a part of the AES process, unless he has found a
> : major flaw in Rijndael.
>
> Well, putting it like that the argument is indeed fairly simple.
>
> As is it's refutation: your premise is wrong - Matt does *not*
> "chop all but 8 bits" from a Rijndael block.
Though in the case in Dave's story, that is what the program
did. That's about a one in 2^120 chance, barring a major flaw
in Rijndael.
Of course really what Dave did was fake the example: he
defined his plaintext's "secret code format" to be what the
decryption program put out for a given short ciphertext and
key. He tells the story in the other direction, as if had has
the codebook before he decided to use this encryption program.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Thu, 02 Nov 2000 19:52:54 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > Tom St Denis wrote:
> > > >
> > > > The word "codec" is used quite often in compression groups
because
> > it
> > > > refers to "COmpression DECompression engine". Somies to "COding
> > > > DECoding" as well...
> > >
> > > However you should consider that not everybody subscribes
> > > to the other groups and the same shorthand may have different
> > > meaning in different disciplines. (I saw e.g. DES with
> > > an entirely different meaning elsewhere.)
> >
> > Well if you want to talk about crypto/compression you have to know
the
> > lingo.
>
> Mmh, if such do not even appear in standard textbooks on
> data compression!
It's a commonly used term.
> But known-plaintext attack (the zero bytes mean that
> part of the plaintext is known) is one of the commonly
> considered attacks, isn't it? Note also that my contrived
> example was meant only to give some intuitive feeling to
> conceive why a compressed sequence with reduced redundancy
> is better for crypto processing.
Yes, but known-plaintexts attacks normally require much more then a
single block. Just because you have 1,000,000 known plaintext blocks
in something like Rijndael doesn't mean you are one step closer to
learning the key or the message (again assuming the message blocks are
not part of the known space).
> This is in my view not the right type of argument against
> 1-1. If you have an extremely secure block cipher, then
> by definition you don't have to care about anything else
> in the processing, whether you use compression or not. But
> that's not the point. The proponents of 1-1 claim (if I
> understand correctly) that, if you use compression followed
> by a cipher that is susceptible to brute force, then 1-1
> helps.
But if it is a finite algorithm it is breakable in a finite number of
steps. So I can *ALWAYS* brute force a 1-1 or non-1-1 system with
virtually the same ease.
> Please note that I don't consider myself on the side of
> proponents of 1-1 but rather on the opposite side. So
> I am not defending their position, nor, for reasons
> already mentioned, countering their position here.
> (To be honest, I got sort of fed up with discussions
> on the issue and haven't yet recovered from that.) I
> suggest that you, if you really want to discuss 1-1 in
> depth, create a new thread with a clear and explicit
> title line about 1-1 to attract the attention of those
> discussion partners that are properly interested in the
> issue. Good luck!
To be honest I agree that using compression is a good idea. It makes
the messages smaller, and in some contrived cases can reduce the number
of alike blocks (which is why we use block chaining anyways). I doubt
alot of "security" is provided by a good codec.
At anyrate the proponents of 1-1 are mindless anyways. If they claim
reducing redundancy is a key to security (in the plaintext, obviously
we want todo the same to the ciphertext) then a better codec is needed,
not some contrived huffman codec.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
