Cryptography-Digest Digest #824, Volume #11 Sat, 20 May 00 05:13:01 EDT
Contents:
Re: Using TEA in one-way hash function ("David C. Oshel")
Re: Reasonably secure OTP passing (David Hopwood)
Re: More on Pi and randomness (Mok-Kong Shen)
Re: More on Pi and randomness (Mok-Kong Shen)
Re: AES final comment deadline is May 15 (Mok-Kong Shen)
Re: Chosen plaintext attack, isn't it absurd? (Guy Macon)
Re: Is OTP unbreakable? (Guy Macon)
Re: More on Pi and randomness (Guy Macon)
Re: Q: Recording on magnetic cards (Francois Grieu)
Re: AES final comment deadline is May 15 (David Blackman)
Re: More on Pi and randomness (Guy Macon)
Re: Interpretation of Hitachi patent claims (Jerry Coffin)
Re: More on Pi and randomness (Richard Heathfield)
Re: More on Pi and randomness (David Blackman)
Re: Interpretation of Hitachi patent claims ("Lyalc")
----------------------------------------------------------------------------
From: "David C. Oshel" <[EMAIL PROTECTED]>
Subject: Re: Using TEA in one-way hash function
Date: Sat, 20 May 2000 01:41:45 -0500
In article <[EMAIL PROTECTED]>, "David C.
Oshel" <[EMAIL PROTECTED]> wrote:
> In article <3QPT4.1395$[EMAIL PROTECTED]>, "adam pridmore"
> <[EMAIL PROTECTED]> wrote:
>
> > >
> > > or can i use the "modified Davies-Meyer" that bruce schneider say in 18.11
> > > of applied crypto, but using TEA instead of IDEA???
> > >
> > Or you could use Tandem and Abrest Davies-Meyer with XTea, with a larger
> > output of 128-bit.
> >
> >
>
> op. cit., obviously. Any hints?
http://www.alhamy.net/faqs/crypto/faqref.htm#Pre93
--
David C. Oshel mailto:[EMAIL PROTECTED]
Cedar Rapids, Iowa http://pobox.com/~dcoshel
``Tension, apprehension, and dissension have begun!" - Duffy Wyg&, in Alfred
Bester's _The Demolished Man_
------------------------------
Date: Fri, 19 May 2000 23:52:31 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Reasonably secure OTP passing
=====BEGIN PGP SIGNED MESSAGE=====
Bradley King wrote:
> I had the idea that some properties of OTP could be useful in more
> conventional public key encryption. Please tell me what I'm missing
> here, there must be a loose end somewhere.
> =
> If we pass an OTP over a public medium using a straightforward public
> key/symetric system (=E0 la virtually all consumer internet commerce) t=
hen
> the convetionally encrypted OTP should be virtually impossible to tease=
> out of the cyphertext using cryptanalysis techniques because there woul=
d
> be theoretically no order to be found, the 'plaintext' in this case
> being random noise itself.
>
> If we then use the OTP that both parties now have to transfer the real
> plaintext message, then this cyphertext would also have no real order
> to it (which is the magic of the OTP method, after all).
There is no point in doing this, because if known plaintext would be
available for the straightforward hybrid cryptosystem, then the same
amount of known plaintext will be available for this system, by XORing
the original known plaintext with the OTP ciphertext.
The only thing this method prevents is a chosen plaintext attack, but
it does that at the expense of doubling the bandwidth usage, which would
not normally be considered a worthwhile trade-off (especially since
modern ciphers are designed to be resistant to chosen plaintext attacks
anyway).
- -- =
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOSXFgzkCAxeYt5gVAQEO1ggAujB3FhOa5feo7RWKa9H0QjidmooKfVPb
xUrD5KEm6p/VqL0DeJpcvouiS76F7wKaQ1d83GpF9lJrcdBE5fhhQq8xV4PAwCc/
00QywsaeVMAt+t7b1igXZycSgG7nHczbluQ93FQa63dNVuWYWBFEmkjD7Fz4MKCe
+Ii3IlMOwctFtH7R6GA+M6L86gnVPVwryqxz+wN3cNW7Rd2l8zHPgp6VDsEYlhfP
CLLZZn4KMhr2aBfXqln/k2OKxZ24f9jk/l4BibHIUvEF9LJ+9tZN3eJcezjzr1iL
vNChkUT/1lpyPyvtf9dbnu5/EEO0QfLUg1xrXkUDfBN7QEraa5hs8Q=3D=3D
=3DN7Q5
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: Sat, 20 May 2000 09:35:02 +0200
Richard Heathfield wrote:
> > ): If I tell you the decimal in position N in the expansion of Pi
> > ): you won't be able to tell me anything about the following decimal
> > ): sequence short of doing the computation yourself.
>
> (This is probably true for decimal digits, but not for hexadecimal - er
> - hexits.)
>
> > )Even if you *don't* tell me N, it's still possible to make positive
> > )statements about the sequence. This was discussed on the other thread:
> > )according to mathmaticians, PI doesn't behave randomly.
> >
> > This is not something which can be said with our current level of
> > knowledge of PI. We can make statements about the first x billion
> > digits, but we cannot (as yet) make statements about PI.
>
> I understand the Nth hexit of pi, irrespective of the value of N, to be
> calculable using the equation derived by Borwein, Borwein and Plouffe.
> The 400 billionth hexit of pi has been thus calculated.
>
> (I seem to have switched sides in this debate. :-) )
If one has a hexit or even a number of hexits, it may be very
difficult to determine the corresponding N, I am afraid.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: Sat, 20 May 2000 09:34:31 +0200
Steve and Darla Wells wrote:
> Long ago when computer time was measured in $1/s, I did some distribution
> analysis on pi, it wouldn't make that great of an entropy source, much
> complexity but many recognizable patterns. (Reference Kunth's comment about
> complexity vs randomness)
I remain to believe that on heuristic grounds one could well pass a
segment of Pi (with a randomly chosen starting point) through a
sufficiently good encryption algorithm (which mixes up the input)
and obtain something good enough to be considered random
for all practical applications. Eventually one could also combine
several of such outputs in appropriate ways for further quality
improvement.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Sat, 20 May 2000 09:35:07 +0200
David Blackman schrieb:
> Scott Contini wrote:
> Key agility (on Pentium 2? I'd like to know for custom hardware where
> it's more important):
> 1. Rijndael
> 2. RC6
Excuse me for a question of ignorance: What is the exact definition of
key agility? Thanks in advance.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Chosen plaintext attack, isn't it absurd?
Date: 20 May 2000 03:43:07 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>However, crypto professionals are now considering some additional
>class of attacks which they call "distinguishing attacks". These have
>as a goal just to determine what kind of algorithm was used in order
>to encrypt a particular ciphertext. The attack is deemed successful,
>if the name of the algorithm can be established
Does anyone know if there is a distinguishing attacks for Ciphersaber?
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Is OTP unbreakable?
Date: 20 May 2000 03:47:32 EDT
In article <8g0oct$gtb$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>In article <8frpvj$l2p$[EMAIL PROTECTED]>, Paul Schlyter ([EMAIL PROTECTED]) wr
>ote:
>>
>> Still, OTP has two weaknesses though:
>>
>> 1. An eavesdropper can figure out the length of the message. This
>> can be countered by adding random garbage to your actual message.
>>
>> 2. An eavesdropper can figure out that a message has been sent.
>> This can be countered in two ways: either by steganography (which
>> hides the message somehow), or by sending many extra messages
>> containing nothing but garbage.
>>
>3. An attacker can modify the message. If he knows the position of
>some item within the plaintext, he can change it to any other string
>with the same length.
It seems to me that adding a random length of random garbage at the
start and end of your message would counter 1 and 3.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: 20 May 2000 03:54:56 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>I understand the Nth hexit of pi, irrespective of the value of N, to be
>calculable using the equation derived by Borwein, Borwein and Plouffe.
>The 400 billionth hexit of pi has been thus calculated.
Really?!? (not questioning you, just suprised). Does the time to compute
the answer get larger as N gets larger? Linearaly? Exponentialy?
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Q: Recording on magnetic cards
Date: Sat, 20 May 2000 10:05:08 +0200
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> It is a plastic card with at the back a black strip, just like my bank
> card or my Eurocard. There is apparently no chip on it. If such a
> card is put together with the bank cards, a writing operation on
> on it should have some effects on the others, shouldn't it?
If it is a magnetic stripe card, it works similarly to an audio or
video tape (the card is the tape). And in audio tapes, you are
not surprised that only the portion of the tape that touches the
read/write heads is changed when recording occurs.
Francois Grieu
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Sat, 20 May 2000 18:06:45 +1000
Mok-Kong Shen wrote:
>
> David Blackman schrieb:
>
> > Scott Contini wrote:
>
> > Key agility (on Pentium 2? I'd like to know for custom hardware where
> > it's more important):
> > 1. Rijndael
> > 2. RC6
>
> Excuse me for a question of ignorance: What is the exact definition of
> key agility? Thanks in advance.
>
> M. K. Shen
I don't know of an official one. One definition might be the inverse of
the time it takes to setup a key schedule for a new key, then encrypt
(or decrypt) N blocks with it, assuming the key will not be used again
afterwards. N=3 is of some practical interest in networking. You might
choose a different N depending on application. But for "key agility" the
assumption must be that N is small.
Encrypt and decrypt setup times are different for some algorithms,
especially Rijndael. But Rijndael wins either way.
I suppose for a custom hardware solution, you would also want to know
just how much hardware is needed to do a fast key schedule setup.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: 20 May 2000 04:06:41 EDT
In article <8g31sv$5rf$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
>
>Mike Mccarty Sr wrote in message <8g1kd5$7qf$[EMAIL PROTECTED]>...
>
>>In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>>)In sci.crypt JCA <[EMAIL PROTECTED]> wrote:
>>)
>>): If I tell you the decimal in position N in the expansion of Pi
>>): you won't be able to tell me anything about the following decimal
>>): sequence short of doing the computation yourself.
>>)
>>)Even if you *don't* tell me N, it's still possible to make positive
>>)statements about the sequence. This was discussed on the other thread:
>>)according to mathmaticians, PI doesn't behave randomly.
>>
>>This is not something which can be said with our current level of
>>knowledge of PI. We can make statements about the first x billion
>>digits, but we cannot (as yet) make statements about PI.
>
>Some things are known about the decimal digits of pi in general. For
>example, for no positive integer n are the digits n thru 100*n all equal to
>zero.
...which is NOT true of a true random set of decimal digits.
Thus proving that PI doesn't behave randomly.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Sat, 20 May 2000 02:09:44 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>
> Roger Schlafly wrote:
>
> > A US patent claim must be a single sentence.
>
> Ground enough to have reforms, or developments.
This is actually common to a number of countries. The _intent_ is to
force the author to restrict the patent to covering ONE thing.
In case you care, these may be the longest sentences you've ever
seen, but as claims go they're really not terribly long -- I've seen
some that went on (still as a single sentence) for over a page.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
Date: Sat, 20 May 2000 09:17:07 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Guy Macon wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> >I understand the Nth hexit of pi, irrespective of the value of N, to be
> >calculable using the equation derived by Borwein, Borwein and Plouffe.
> >The 400 billionth hexit of pi has been thus calculated.
>
> Really?!? (not questioning you, just suprised). Does the time to compute
> the answer get larger as N gets larger? Linearaly? Exponentialy?
pi = sum (values of n from 0 to infinity) of (4/(8n+1) - 2/(8n+4) -
1/(8n+5) - 1/(8n+6)) * (1/16)^n
In other words, the nth hexit has the value (4/(8n+1) - 2/(8n+4) -
1/(8n+5) - 1/(8n+6)).
Source: "The Joy of Pi". I tried substituting in the first couple of n,
and it didn't seem to make much sense, but that's probably because I'm
not a mathematician.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
37 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (60
to go)
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: Sat, 20 May 2000 18:17:48 +1000
Mok-Kong Shen wrote:
> I remain to believe that on heuristic grounds one could well pass a
> segment of Pi (with a randomly chosen starting point) through a
> sufficiently good encryption algorithm (which mixes up the input)
> and obtain something good enough to be considered random
> for all practical applications. Eventually one could also combine
> several of such outputs in appropriate ways for further quality
> improvement.
>
> M. K. Shen
Passing just about anything through a sufficiently good encryption
algorithm makes something good enough to be considered random for any
practical application i can think of at the moment.
When cryptanalists discover that the output of your encryption algorithm
looks different to random numbers in some way, it's probably time to get
a better algorithm.
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Sat, 20 May 2000 18:34:57 +1000
Never having read the entire patent, some observations I formed in my career
are included below for thought.
lyal
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>> [snip]
>> I5 = I3 <<< r2
>> I6 = I4 <<< r2
>
>[snip]
>
>> Perhaps C = I5 ^ I6 or some other operation which combines them. Then go
>> round again for the next byte of plaintext. Whether using the same r1
>> and r2 or a different set of rotation values isn't clear to me from the
>> text.
>
>I think that there are two point that could be discussed:
>
>1. If one deviates from the scheme above, say, not having two values
> to be rotated, but one or three, then the claim could be considered
> not applicable.
I don't think the claim means that it applied to 2 only input elements of
data, but that some pair of plaintexts are used - the claim doesn't restrict
the pair to being the only 2 that may be used - it could permit '2 of x"
elements, for instance.
In this case, each pair being used may fall under the scope of this patent.
The single element case may not have been considered useful by Hitachi.
>2. Doesn't 'predetermined' mean something fixed once and for all by
> the chosen key and kept constant for all blocks? If yes, then use
> of a dynamic value wouldn't be covered by the patent.
It could also mean defined by any deterministic method (e.g. Rx = 3+4, or
the 37th digit of PI, the time of day, or whatever)
>> > "Claim 10. A method of generating code data by executing a
>> > plurality of arithmetical processes on message data,
>> > comprising the steps of: performing a first process for
>> > generating first intermediate data by arithmetically operating
>> > on second intermediate data derived from initial data having
>> > a predetermined bit pattern and a first portion of said
>> > message data;
>>
>> This seems ludicrous. It seems to be saying: get your first intermediate
>> value by taking your /second/ intermediate value and munging it.
>
>I have the same impression. So the passage is ambigious and the patent
>claim would be invalid. Further, it is not stated at all what kind of
>process the 'first process' exactly is. One couldn't give patent to
>some 'process' that is not clearly defined in a fixed and narrow domain!
It may mean two operations are applied to the the same initial data, then
the results of operation 2 applied to the result of operation 1.
To understand patent claims, you need to review and understand the entire
text of the patent document. The patent claims may only operate in the
contex of the preceding descriptive text, depending on the country and the
patent rules applying at the time.
>> > performing a second process for generating third
>> > intermediate data by circular shifting of said first
>> > intermediate data by a first predetermined number of bits;
>>
>> Bit rotation again.
>>
>> > performing a third process for generating fourth intermediate
>> > data by arithmetically operating on fifth intermediate data
>> > derived from said third intermediate data and a second portion
>> > of said message data; performing a fourth process for
>> > generating sixth intermediate data by circular shifting of
>> > said fourth intermediate data by a second predetermined number
>> > of bits which is different from said first predetermined
>> > number of bits; performing a fifth process for generating
>> > seventh intermediate data by arithmetically operating on said
>> > sixth intermediate data and a third portion of said message
>> > data; performing a sixth process for generating eighth
>> > intermediate data by circular shifting of said seventh
>> > intermediate data by a third predetermined number of bits
>> > which is different from said second predetermined number of
>> > bits and by arithmetically operating on said eighth
>> > intermediate data, said seventh intermediate data, and said
>> > fourth intermediate data; and performing a seventh process
>> > generating said code data by arithmetically operating on
>> > said eighth intermediate data."
>>
>> This really is extremely badly written. It's most unclear what's being
>> said. The best interpretation I can put on it is that the algorithm
>> consists primarily of many bit rotations by different amounts,
>> presumably with key XORing mixed up in it too.
The process are labled 1, 2 etc by the writer. The labelling has nothing to
do with the order in which the processes are used in a product covered the
patent.
Patents are not written for others to understand them.
They are written to define some intellectual property about a process. The
patent office, patent lawyers, and the courts decide what is actually
defined in the context of a specific challenge to a specific patent.
>> Since I was capable of discovering this for myself, all by myself (with
>> the minor twist that I rotate the whole buffer by a varying number of
>> bits on each round, rather than each byte of the plaintext by a
>> different amount, which is presumably different again on each round) one
>> afternoon late last year when I was bored at work, I can't fathom why
>> Hitachi seem to think they're onto something non-obvious.
We are all capable of discovering these things. The question is - did we,
and did we doing anything about formalsing some claim to being the initial
'discoverer' of these things?
I think the issue is the specific application of bit rotation to a specific
type of data manipulation that has been considered novel by a patent office.
It is very important to read the entire document before discounting the
patent claims.
------------------------------
** 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
******************************
