Cryptography-Digest Digest #176, Volume #13 Fri, 17 Nov 00 08:13:01 EST
Contents:
Re: Q: fast block ciphers (Paul Crowley)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: Big-block cipher, perhaps a new cipher family? (Mok-Kong Shen)
Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
Re: Q: fast block ciphers (Thomas Pornin)
Re: DES question: Has this ever been proven before? (Raphael Phan)
Re: Is Triple DES the BEST Algorithm ? (Pranke)
Re: Q: fast block ciphers (Pranke)
Re: DES question: Has this ever been proven before? (Paul Crowley)
Re: Q: fast block ciphers (Paul Crowley)
Re: DES question: Has this ever been proven before? (Tom St Denis)
Re: Rijndael: Impossible differential cryptanalysis on 5 rounds (Zulfikar Ramzan)
Re: [Question] XOR encryption (Tom St Denis)
Re: [Question] Generation of random keys (Tom St Denis)
Re: [Question] Export restrictions on following algos. (Tom St Denis)
Re: Big-block cipher, perhaps a new cipher family? (Manuel Pancorbo)
Re: Book recommendation, please (Rex Stewart)
----------------------------------------------------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Fri, 17 Nov 2000 10:26:21 GMT
Thomas Pornin wrote:
> (As a side note, all fields of size 2^n are not mutually isomorphic)
Er, are you sure? I know all Galois fields of the same size are
isomorphic, and I thought all finite fields were Galois fields. Can you
give a counterexample?
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hitachi - on what grounds ??
Date: Fri, 17 Nov 2000 11:51:21 +0100
kihdip wrote:
>
> Doesn't this slow down the development of new and better cryptographic
> algorithms ??
> I mean, if someone had already patented a XOR operation, and claimed that
> noone should use this in any ciphers, we would have to wait until his patent
> expired.
>
> I know - XOR's are simpel and obvious - but where's the limit ??
>
> Right now we have a massive discussion on software patents in Europe.
> The argument of slowing/stopping the development is a quite good one against
> patenting software.
I vaguely remember that Vernam had a patent and that
probably was connected to XOR. In general, I think that
you are right in considering that the institution of
patenting, despite its well intended purposes of law
makers, gives ample opportunity to a number of people who
are not genuine inventors to earn money and brings also
very much additional profits to the patent lawyers.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hitachi - on what grounds ??
Date: Fri, 17 Nov 2000 11:51:11 +0100
Paul Pires wrote:
>
> <Snip>
> > If you have other methods which the communication partners
> > can easily and safely employ (i.e. without weakening
> > the cipher) and hinder the work of the opponent, then it
> > would be fine if you would let others of the group partake
> > you knowledge through posting these to the group.
> >
> > Anyway, if you think that posts (not only those of mine)
> > you see in the group do not contain materials giving
> > sufficient answer to your five questions listed in a
> > previous follow-up, then please be kind enough to say so.
> > This is why we have a 'discussion' forum, isn't it?
>
> As usual you and I are misconnected, I'm trying to back out
> of it gracefully. If you wish to continue the discussion by E-mail
> I will be happy to do so. I am feeling a little self concious about
> how the group feels about this and don't want to continue this
> here as it has gone way past anything usefull or interesting.
>
> I don't have any problems, criticisms or questions about the
> thread you mentioned. I also have no interest in the topic.
> I suggested the questions as general content for the hypothetical
> or example situation you originally brought up, not any actual thread
> that might exist. Which, by the way, has nothing to do with the
> original topic of discussion.
I don't think that your last sentence is correct (or else
I misunderstood you). In the other thread mentioned I
suggested some methods that utilizes 'variablity' to
render the job of the opponent hard (e.g. the permutation
of round keys leads to a huge number of cases that he
has to consider). Hitachi's rotation patent depends on
'variable' amount of rotation and is hence an issue of
'variability'.
>
> I do not disparage the content or authorship of any of that
> material since I have not read it and have no interest in the
> topic or knowledge of the subject. You don't have to
> prove me an idiot, I freely admit it after getting sucked
> into another weird exchange with you. We have to stop
> meeting like this.
>
> For someone who has such a problem with English,
> you sure don't seem to have a problem with
> condecension, misdirection and snide comments.
>
> Be careful, that Columbo act is wearing a little thin.
Since I am fairly sure that there are quite a number of other
people who neither have English as native language nor have
mastered it sufficiently perfectly nor are aquainted with
terms in many other fields (maybe not even with all useful
terms in crypto), I like to take this opportunity to appeal
to all posters of the group:
(1) Use simple plain English.
(2) Express opinions as directly as possible.
(3) Keep to objective discussions without launching personal
attacks.
(4) Never employ terminology in fields far away from crypto.
(5) Confine to a general vocabulary that scientists use
in publications.
For otherwise there would be lots of misunderstanding and
unnecessary posts that are nuisance and time-consuming
for the unparticipated readers and possibly even
inadvertantly generate such bad feelings that some poor
and weak souls would have to visit their psychoanalysts.
(I am taking the liberty to remark that your last sentence
is again unfortunately totally not understandable for me,
having never heard of anything about a Columbo act.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 11:51:03 +0100
Terry Ritter wrote:
>
> "Manuel Pancorbo" <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >Nevertheless I don't pretend be original. The question is: if this
> >"large-block-stream-ish" ciphers are really faster than traditional block
> >ciphers, good diffusive and strong against known attacks... why not give
> >them more attention?
>
> http://www.io.com/~ritter/NEWS/HUGEBLK.HTM
> http://www.io.com/~ritter/ARTS/DISTAVA.HTM
> http://www.io.com/~ritter/ARTS/VSBCNONL.HTM
> http://www.io.com/~ritter/MIXCORE.HTM
> etc.
Nevertheless, the prevailing interest in the crypto field
seems to be more concentrated in block encryption. I guess
that this development is more or less history dependent
(like modes).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hitachi - on what grounds ??
Date: Fri, 17 Nov 2000 11:54:52 +0100
Terry Ritter wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> >
> >Lest Hitachi comes onto further ideas of patenting based
> >on variability, let's note that variable block sizes,
>
> http://www.io.com/~ritter/PATS/VSBCPAT.HTM
Just as a matter of interest in the way of general handling
by patent offices, did you have to present related materials
such as those in your
http://www.io.com/~ritter/NEWS/HUGEBLK.HTM
and argue that your idea was novel? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Q: fast block ciphers
Date: 17 Nov 2000 11:16:32 GMT
According to Paul Crowley <[EMAIL PROTECTED]>:
> Can you give a counterexample?
No -- after verification, I found that I was mistaken. All finite fields
of same size are isomorphic.
--Thomas Pornin
------------------------------
From: Raphael Phan <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 17 Nov 2000 11:28:38 GMT
Hmm... John, you are positively sure that a certain DES plaintext XOR
would not cause the same ciphertext XOR? Are there any references
(papers, reports...) where it has been explicitly stated that such a
situation won't happpen?
Raphael
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Fri, 17 Nov 2000 04:21:22 GMT, Raphael Phan <[EMAIL PROTECTED]>
> wrote, in part:
>
> >let x and y be a pair of plaintexts to DES such that the input XOR
> >is x'. Would the corresponding output pair have the same XOR
> >difference?
>
> No, but there might be a _slight_ tendency for the output pair to have
> a particular XOR difference, depending on what the key is, for a
> particular input XOR difference - this is how differential
> cryptanalysis works.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 17 Nov 2000 12:53:38 +0100
From: Pranke <[EMAIL PROTECTED]>
Subject: Re: Is Triple DES the BEST Algorithm ?
Laurent wrote:
> [absolutely nothing]
Who said that ? 3DES ist slow and uses only 64 bit blocks.
Use AES.
------------------------------
Date: Fri, 17 Nov 2000 12:58:59 +0100
From: Pranke <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
David Schwartz wrote:
> Scott Fluhrer wrote:
> > Umm, the OP asked for a block cipher. I do believe that RC4 is normally
> > considered a stream cipher...
> While a block cipher may be difficult to use as a stream cipher
> (actually, it's not hard to use but hard to be sure it's secure), any
> stream cipher can trivially be changed into a block cipher.
Trivial ???
Oh, yes, trivial, in its original meaning.
I never have heared of the idea to use a stream cipher as a block
cipher, and I really would like to know how THAT should work ?
While using a block cipher as stream cipher is indeed trivial.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 17 Nov 2000 12:23:36 GMT
Raphael Phan wrote:
> Hmm... John, you are positively sure that a certain DES plaintext XOR
> would not cause the same ciphertext XOR? Are there any references
> (papers, reports...) where it has been explicitly stated that such a
> situation won't happpen?
It seems almost certain that there must exist *some* (K, X, Y) such that
X XOR Y = DES_k(X) XOR DES_k(Y)
though I think searching for one such tuple would be slightly slower
than breaking DES keys by brute force
However, the probability of events of the form
P(DES'_k(X) XOR DES'_k(Y) = A | X XOR Y = B)
for some A, B and where DES' is some subrange of the DES rounds, is
*extremely* well studied, in DES more than any other cipher, since this
is the basis of differential cryptanalysis. If the event you're
describing had more than non-trivial probability, we would certainly
know about it by now.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Fri, 17 Nov 2000 12:34:09 GMT
Pranke wrote:
> David Schwartz wrote:
> > While a block cipher may be difficult to use as a stream cipher
> > (actually, it's not hard to use but hard to be sure it's secure), any
> > stream cipher can trivially be changed into a block cipher.
>
> I never have heared of the idea to use a stream cipher as a block
> cipher, and I really would like to know how THAT should work ?
I think David Schwartz is confused here, but oddly enough there are
constructions that take a stream cipher and a hash function and return a
block cipher. The catch is that they are large block ciphers: the
minimum sensible block size is around 320 bits and at that size they're
pretty slow, though they're fast for big blocks.
See LIONESS in http://citeseer.nj.nec.com/anderson96two.html - note that
BEAR and LION are vulnerable to attacks based on inducing internal
collisions, and thus their security is limited to the difficulty of
generating collisions in the underlying hash function.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 17 Nov 2000 12:33:38 GMT
In article <8v34p2$8ra$[EMAIL PROTECTED]>,
Raphael Phan <[EMAIL PROTECTED]> wrote:
> Hmm... John, you are positively sure that a certain DES plaintext XOR
> would not cause the same ciphertext XOR? Are there any references
> (papers, reports...) where it has been explicitly stated that such a
> situation won't happpen?
It could happen but it is not likely. The best differential trait is
with a few bits in and a zero difference out (p = 1/234 I think...) so
I would say that anything else would be improbable at best.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 17 Nov 2000 07:49:48 -0500
From: Zulfikar Ramzan <[EMAIL PROTECTED]>
Subject: Re: Rijndael: Impossible differential cryptanalysis on 5 rounds
So, it seems to me that you have five values: (a,b,c,d,a') -- each of which can
take on 2^8 possible values (each value is eight bits long).
Thus, the total number of possible values is:
(2^8)^5 which equals 2^40.
I'm not sure if I've understood your question completely - butI hope this helps...
Zulfikar
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> I refer to the paper by Biham and Keller on impossible differential
> cryptanalysis of 5-round Rijndael.
>
> Looking at page 8...
>
> The pair of plaintexts chosen should be such that they differ in only
> one byte.
>
> They specify that they choose pairs of the form ((a,b,c,d),(a',b,c,d))
> in a column... what about the other columns? The other columns should
> all have zero byte differences... but why is it that there are 2^40
> values in the table? It corresponds to 2^40 possible pairs that meet
> the criteria.. how do you arrive at this figure?
>
> Could anyone elaborate on the second paragraph?
>
> Raphael
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
--Zully
=======
Zulfikar Ramzan (AKA Zully)
Laboratory for Computer Science, MIT
NE43-311, (617) 253-2345
http://theory.lcs.mit.edu/~zulfikar/homepage.html
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: [Question] XOR encryption
Date: Fri, 17 Nov 2000 12:35:51 GMT
In article <[EMAIL PROTECTED]>,
Shri Desai <[EMAIL PROTECTED]> wrote:
> Hi,
>
> If my key is equal or larger then the input text then can simple XOR
> of input text with key give me a good enough encryption?
>
> Would appreciate your input.
If you don't use the key twice, it's a ONE TIME PAD. Completely
useless and overall debatable.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Fri, 17 Nov 2000 12:36:28 GMT
In article <[EMAIL PROTECTED]>,
Shri Desai <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Can someone point me to source code (C or VB) to generate good random
> keys (1024 bit)? Good enough to be used in Diffe Helman algo.
>
> Would appreciate it,
There are numerous packages that use DH/EG. Why not do a web search?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: [Question] Export restrictions on following algos.
Date: Fri, 17 Nov 2000 12:39:39 GMT
In article <[EMAIL PROTECTED]>,
Shri Desai <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I had following few questions:
>
> 1) If I use Blow Fish in an app. which may be used by all over the
> world, are there any export restrictions in US? Actually, I am in
> Canada.
>
> 2) How about the above case for Two Fish algo?
>
> 3) Are the above 2 free for commercial and non commercial use?
I am in Canada too and to the best of my knowledge there are no crypto
export laws (that are actually enforced). Also Twofish/Blowfish (note
the spelling) are both designs of Counterpane and are public domain (if
you cared to read the site where they came from ...)
> 4) What about the restrictions on Diffe-Helman algo. for key exchange?
> Is it also free for non and for commercial use?
The patent (I think there was one on EG) expired quite some time ago.
Perhaps you should actually read up on crypto some more?
DH is *NOT* an encryption algorithm either. So consider using ElGamal,
RSA or some form of ECC.
> Any info. on this would be appreciated. Will great if you email me.
I would suggest you read the Handbook of Applied Cryptography. There
is an online copy avail. for free on the website (just yahoo for it!)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Manuel Pancorbo <[EMAIL PROTECTED]>
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 12:41:21 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Fri, 17 Nov 2000 00:27:03 GMT, in
> <rX_Q5.1169$[EMAIL PROTECTED]>, in sci.crypt "Manuel
> Pancorbo" <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >Nevertheless I don't pretend be original. The question is: if this
> >"large-block-stream-ish" ciphers are really faster than traditional
block
> >ciphers, good diffusive and strong against known attacks... why not
give
> >them more attention?
>
> http://www.io.com/~ritter/NEWS/HUGEBLK.HTM
> http://www.io.com/~ritter/ARTS/DISTAVA.HTM
> http://www.io.com/~ritter/ARTS/VSBCNONL.HTM
> http://www.io.com/~ritter/MIXCORE.HTM
> etc.
>
Really interesting. I didn't realize that huge-block ciphers were
matter of discussion in sci.crypt in the past. But the question stands
up: this can be a new formal family of ciphers worthy of deep(er)
analysis.
Well I conject, from a glance reading of your material, that you are
familiar to this kind of ciphers. So I invite you reading my original
post and answer this questions:
1) What's your opinion of this particular huge-block cipher mode? I.e.
a kernel feedback stream cipher that passes twice -forward and backward-
2) You mention the concept "avalanche distance" that I correspond
to "safe distance" in my original post. IMHO, in this scheme the last
units of the packet (huge-block) are vulnerable up to this "avalanche
distance" and a previous backward encryption that covers only this
distance is enough to prevent chosen ciphertext attacks, am I right?
3) I mention the possibility that this particular scheme would be weak
in small packets. How can I measure the safe minimum size of a packet?
Thanks for your attention.
--
____________________________________________________________________
Manuel Pancorbo
[EMAIL PROTECTED] (Apply ROT13)
____________________________________________________________________
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: Book recommendation, please
Date: Fri, 17 Nov 2000 12:51:19 GMT
You are, of course, completely correct.
I have been away from teaching too many years.
In article <[EMAIL PROTECTED]>,
"John A. Malley" <[EMAIL PROTECTED]> wrote:
> Rex Stewart wrote:
> >
> > I am surprised no one suggested "Handbook of Applied Cryptography"
> > Should I take that to mean it would be overkill?
> >
>
> Ron Rivest's Forward in the book describes it as "a rigorous
> encyclopedia of known techniques, with an emphasis on those that are
> both (believed to be) secure and practically useful." And the authors
> tell us in the Preface their work "is intended as a reference for
> professional cryptographers"....as well as "to provide a solid
> foundation for students and others first learning the subject."
>
> It's a must-have reference for anyone studying cryptology or
conducting
> research in cryptology.
> But a 16 year old would benefit from exposure first to basic
> introductory books on cryptology perhaps with the HAC on hand to
> investigate particular questions/issues in greater depth. I assume
> everyone who gets the HAC eventually reads it from cover to cover in
> some chapter order that best satisfies their needs :-)
>
> John A. Malley
> [EMAIL PROTECTED]
>
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
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
******************************
