Cryptography-Digest Digest #826, Volume #11 Sat, 20 May 00 17:13:01 EDT
Contents:
Re: Chosen plaintext attack, isn't it absurd? (Tim Tyler)
Re: AES final comment deadline is May 15 (DJohn37050)
Re: Interpretation of Hitachi patent claims (Mok-Kong Shen)
Re: Q: Recording on magnetic cards (Mok-Kong Shen)
Re: Interpretation of Hitachi patent claims (Mok-Kong Shen)
Re: Base Encryption: Revolutionary Cypher (Mok-Kong Shen)
Re: More on Pi and randomness (Mike Kent)
Fast RC5 (tomstd)
Re: Q: Recording on magnetic cards (Francois Grieu)
Re: Interpretation of Hitachi patent claims
Bigfloat seems to work (Mike Rosing)
Re: Fast RC5 (tomstd)
Re: Bigfloat seems to work (tomstd)
TEST! (Maxim L)
Re: TEST! (tomstd)
Re: An argument for multiple AES winners (Tim Tyler)
Who has got RSA simple program (sources on C/C++)? (Maxim L)
Re: Base Encryption: Revolutionary Cypher (wtshaw)
Re: AES final comment deadline is May 15 (wtshaw)
Re: Who has got RSA simple program (sources on C/C++)? (tomstd)
FAQ out of date? (tomstd)
Re: Compare 3DES's. (William Rowden)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Chosen plaintext attack, isn't it absurd?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 20 May 2000 14:36:08 GMT
Boris Kazak <[EMAIL PROTECTED]> wrote:
: [...] 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 - DES or BLOWFISH or CAST or
: whatever.
Well, we've now wandered from the topic of chosen plaintext attacks, and
whether or not they make any sense, but...
Even the ability to distinguish the output of two cyphers from one
another is a form of "distinguishing" attack - which could help with
traffic analysis.
Even something like block size can be made use of in this context ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Destroy Microsoft.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: AES final comment deadline is May 15
Date: 20 May 2000 15:19:14 GMT
Key agility is the ability to change keys fast or not. Contrast with
encrypting a large file with one key. The most extreme case is changing a key
for every block. In practise, it is say 4 blocks.
Don Johnson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Sat, 20 May 2000 17:54:41 +0200
Jerry Coffin wrote:
> Here's my translation of claim 10 into something like pseudo code:
>
> I2 = A ! PT1
> I1 = @ I2
>
> I3 = I1 <<< B1
>
> I5 = ! I3
> I4 = PT2 @ I5
>
> I6 = I4 <<< B2
>
> I7 = PT3 @ I6
>
> I8 = ID7 <<< B3 ; This part isn't entirely clear
> I8 = @(I8, I4, I7)
>
> CT = @ I8
>
> Where:
> Data
> A = some predefined set of bits
> Ix = The xth intermediate value of the claim
> PT[x] = Plaintext[x] -- parts are not necessarily equal or ordered
> CT = Ciphertext
> Bx = number of bits of rotation. B1 != B2, B2 != B3
>
> Operations
> ! = Some undefined method of derivation
> @ = Some arithmetic operation (not necessarily always the same)
> <<< = circular shift (rotate)
>
> The part I say isn't entirely clear doesn't seem to define a sequence
> in the claim, but says there's a rotate AND that the eighth
> intermediate data is depends on the eighth intermediate data, which I
> interpreted to mean the operations take place in the order defined,
> but the claim doesn't really say this, nor make the dependency
> entirely clear, as it could have by, e.g., defining a ninth piece of
> intermediate data.
Many thanks for the considerable effort to 'decrypt'
the Hitachi crypto patent claims. I'll bet that that's
at least 95%, if not 100%, of what the text with the
long long long sentence contains and there can't be
any more material in it.
Now what you have classified as '!' and '@' are, as
you pointed out, not clearly defined and general (all
encompassing??) and fuzzy. Such are far from being
acceptable in any serious preliminary specifications of
any software projects, not to mention prototype coding.
Thus what the patent claims is indefinite, incomplete,
ambigious, unclear and misleading. Consequently the
patent should be considered to be invalid. Anyway,
the scheme has a certain structure consisting of eight
steps. So any other scheme differing either in the
nature of the individual steps or in the number of
steps are certainly not covered by the scheme. The
scheme uses at three places rotations. But there IS
(correctly) no claim that the rotations are anything
special, in particular designated as novel 'inventions'
of Hitachi. Hence, the claim, even if it were effective
to cover some realization of certain software according
to minds of the designers of Hitachi, can not at all
cover (the least of) any usage of the rotation
operation, which is one of the fundamental and age-old
computer instructions used in all kinds of programs by
programmers worldwide, in particular in assembly
programming. (If some patented pharmaceutical product
happens to employ water and alcohol as solvent, it
does not follow that the patent covers general usage
of water and alcohol!)
In the above, I have attempted to develop some
arguments that eventually could be useful to refute
Hitachi's claims. (The claim 1 and 10 are basically of
the same nature and can be treated together.) It would
be nice, if a number of persons of the group would
attempt the same task so that with joint efforts there
may soon result in something that is really strong and
useful.
On the other hand, does anyone know a good way to
'elicite' the opinions of the patent experts of NIST,
IBM and RSA? It would be a big big big SHAME in case
these professional experts are shy of saying
anything (even worse, of course, through writing some
unreadable and fuzzy blablabla in the style of
Hitachi's claims) and we amateurs in patents are to
take over the main job of furnishing counter-arguments
against Hitachi.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Recording on magnetic cards
Date: Sat, 20 May 2000 18:13:56 +0200
Francois Grieu wrote:
> 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.
I would not have been puzzled by the issue, if the care were directly
placed over a read/write station and perhaps also in a prescribed
orientation. As I reported, the card is put (face to face) together
with several other bank cards of obviously the same nature and the
bunch is contained in a thick wallet such that there are lots of coins
between the cards and the read/write station. Further, one can
apparently put the wallet in any direction one chooses. Could the
read/write station selectively write onto one of the cards in the same
manner as a RAM is addressed? I simply couldn't conceive of that.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Sat, 20 May 2000 18:14:02 +0200
Lyalc wrote:
> The single element case may not have been considered useful by Hitachi.
That could at least be something positive.
> >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)
Then use of a dynamic value is not covered.
> 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.
If this (hopefully) were the case, then Hitachi's claims would have
no real impact on AES, I suppose.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Revolutionary Cypher
Date: Sat, 20 May 2000 18:26:11 +0200
Tim Tyler wrote:
> He said: "All bases can be represented in base 2", which may be unclear -
> but is unlikely to be wrong.
>
> I would interpret it as meaning "any number, in any base can be
> represented in base 2".
Yes. Base conversion implies of course that one can always convert
back, so the number as such is never changed. But handling a number
in one base may have some advantages over some other bases, much
like in coordinate transformations in geometry, where a certain
coordinate system may permit a particularly neat and simple description
of a given object.
M. K. Shen
------------------------------
From: Mike Kent <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: Sat, 20 May 2000 16:48:30 GMT
Guy Macon wrote:
>
> In article <8g31sv$5rf$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
...
> >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.
Not really; this is a statement about the digits
in _a particular location_ of the decimal expansion
of pi. It says nothing about the frequency or
distribution of long strings of 0's _overall_.
// Mike Kent
------------------------------
Subject: Fast RC5
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 10:07:11 -0700
I worked on my x86 ASM rc5 code some more (included
decrypt/setup routines). I clocked the encrypt routine at 135
cycles per block/avg on my K6-2 350mhz. That is about 16.9
cycles/byte which knocks most ciphers out of the water in terms
of speed. I can share the asm code with anyone via email, but
it's for educational use only...
Tom
--
[EMAIL PROTECTED]
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Q: Recording on magnetic cards
Date: Sat, 20 May 2000 19:08:46 +0200
> lots of coins between the cards and the read/write station
I believe this rules out magnetic stripe; your cards are IMHO
induction-coupled IC card. This explains the at-a-distance operation.
Such cards are used, for example, in fare collection or access control.
Some are dual mode (contact as of ISO 7816, contactless as of
ISO 14443), some are only contactless.
There is no problem with selecting the approriate card; they act
like computers on a network, with individual ids and everything.
Francois Grieu
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Sat, 20 May 2000 17:56:25 GMT
Has anyone compared the Hitachi patents to the two RC5 patents?
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Bigfloat seems to work
Date: Sat, 20 May 2000 18:39:18 GMT
I'm in the process of seeing if I can plot j(tau) for region F (defined
by Silverman
in "Advanced Topics in the Arithmetic of Elliptic Curves"). The complex
routines
appear to work, including exponential (which is a real exp * (cos + i
sin)), all
to about 240 bits out of 256. If any one has hints on how to improve
it, I'm
listening! See http://www.terracom.net/~eresrch/float for details.
Patience, persistence, truth,
Dr. mike
------------------------------
Subject: Re: Fast RC5
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 12:11:37 -0700
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
>I worked on my x86 ASM rc5 code some more (included
>decrypt/setup routines). I clocked the encrypt routine at 135
>cycles per block/avg on my K6-2 350mhz. That is about 16.9
>cycles/byte which knocks most ciphers out of the water in terms
>of speed. I can share the asm code with anyone via email, but
>it's for educational use only...
You can get the 'educational' copy of my source from My Canadian
server at http://www.tomstdenis.com/rc5asm.zip
Please respect the US patent if you live in the states and do
not use this source for outgoing projects (i.e for educational
use only).
Timings available:
K6-2 350mhz: 16.9 cycles/byte (136 cycles/block)
PII 333mhz: 15.26 cycles/byte (122 cycles/block)
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Bigfloat seems to work
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 12:13:29 -0700
In article <[EMAIL PROTECTED]>, Mike Rosing
<[EMAIL PROTECTED]> wrote:
>I'm in the process of seeing if I can plot j(tau) for region F
(defined
>by Silverman
>in "Advanced Topics in the Arithmetic of Elliptic Curves").
The complex
>routines
>appear to work, including exponential (which is a real exp *
(cos + i
>sin)), all
>to about 240 bits out of 256. If any one has hints on how to
improve
>it, I'm
>listening! See http://www.terracom.net/~eresrch/float for
details.
Although I really have no clue about this type of math (at the
moment) I want to wish you good luck.
Keep up the good work :)
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Maxim L <[EMAIL PROTECTED]>
Subject: TEST!
Date: Sat, 20 May 2000 22:50:49 +0300
Reply-To: Maxim L <[EMAIL PROTECTED]>
Hello ,
Best regards,
Maxim mailto:[EMAIL PROTECTED]
------------------------------
Subject: Re: TEST!
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 12:53:04 -0700
In article <[EMAIL PROTECTED]>, Maxim L <maxim-
[EMAIL PROTECTED]> wrote:
>Hello ,
>
>
>
>Best regards,
> Maxim mailto:[EMAIL PROTECTED]
>
Don't be shy, speak up!!!
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: An argument for multiple AES winners
Reply-To: [EMAIL PROTECTED]
Date: Sat, 20 May 2000 19:08:24 GMT
Bruce Schneier <[EMAIL PROTECTED]> wrote:
: (David A. Wagner) wrote:
[Hitachi patent]
:> Of course, one should not draw any conclusions from a sample size of
:> one :-), but are you sure this patent was as well-known as you say?
: I always generalize from one example. Doesn't everyone?
ROTFL ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Maxim L <[EMAIL PROTECTED]>
Subject: Who has got RSA simple program (sources on C/C++)?
Date: Sat, 20 May 2000 23:02:37 +0300
Reply-To: Maxim L <[EMAIL PROTECTED]>
Hello All,
Please HELP ME,
Who has got a simple RSA program with source on C++ (or C), can you
share it with me. I'm trying to write my own program (My diploma
work), but no success. It's really a bad trouble for me.
Best regards,
Maxim mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Base Encryption: Revolutionary Cypher
Date: Sat, 20 May 2000 13:31:37 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, Eric Lee Green
> : <[EMAIL PROTECTED]> wrote:
>
> :>....All bases can be represented in base 2, albeit with some
> :> wasted bits for odd-number (non-power-of-2) bases. Adding other bases thus
> :> can be considered to be a very crude block-cipher diffusion
mechanism, i.e., a
> :> mechanism for diffusing bits across a larger field of bits, with some
> :> properties that make it decidedly inferior to most such mechanisms for
> :> transforming bits (for one thing, a 1-bit change in the input does not have
> :> the desired avalanche property).
>
> : You are quoting dogma which happens to be mathematically wrong. Base 2 is
> : only fundamental to other powers of two.
>
> You are attacking a position which was never presented.
You furnished the quote that says essentially this.
>
> Eric never said: "base 2 is only fundamental to other powers of two."
>
> He said: "All bases can be represented in base 2", which may be unclear -
> but is unlikely to be wrong.
There are values that cannot be expressed clearly as a number in all
systems; base two is a system, hense it is true that some numbers cannot
be definitively expressed as values in base two. Consider that pi even
transcends all normal bases in this regard.
Consider that pi can be used as a base having values that can only be
approximated in other bases.
Part, an important part, is that there is distingishing differece between
bases in efficiency. Also, various manipulations are most awkward in base
two, consider decimal programs for instance. It is tends to be worse in
others that ten because sometimes decimal functions are ioften ncluded at
a very low level.
>
> I would interpret it as meaning "any number, in any base can be
> represented in base 2".
>
> : Avalanching defined in bits has nothing to do with other bases. [...]
>
> The idea is that "flipping a bit" corresponds to making a small change in
> the input. With many popular computer based forms of information, this
> characterisation is good enough.
The mere language of flipping is characteristic of two choices, base two.
You can rotate other information units, and have lots of other states that
are cryptographically useful.
>
> If a systems fails to have proper avalanche properties when viewed from
> the perspective of base 2, it's likely to be completely stuffed.
>
You can see the properties you like and have poor properties in another
base. The point not that bit twiddlers are not doing good things, it is
that unless other evaluations are considered, binary constructors can
blindsight themselves, never know that this is the case because the fail
to look.
It is insufficient to look only at part of the evidence. I would rather
that you open your eyes so that you get better results in what you are
trying to do.
--
Secrets that are told or available are not secrets any more, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES final comment deadline is May 15
Date: Sat, 20 May 2000 13:33:41 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Key agility is the ability to change keys fast or not. Contrast with
> encrypting a large file with one key. The most extreme case is changing a key
> for every block. In practise, it is say 4 blocks.
> Don Johnson
Then, you are saddled with keys of keys.
--
Secrets that are told or available are not secrets any more, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
Subject: Re: Who has got RSA simple program (sources on C/C++)?
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 13:36:55 -0700
In article <[EMAIL PROTECTED]>, Maxim L <maxim-
[EMAIL PROTECTED]> wrote:
>Hello All,
>
>Please HELP ME,
>Who has got a simple RSA program with source on C++ (or C), can
you
>share it with me. I'm trying to write my own program (My diploma
>work), but no success. It's really a bad trouble for me.
If you live in <insert non-us place> you can get a copy of a
cryptographic library (in C) that I wrote...
http://www.tomstdenis.com/cb.html
Even if you live in the states it, you can pick it up to see how
RSA can be used.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: FAQ out of date?
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 13:39:14 -0700
I just briefly poked at the FAQ today, and saw mention of
something called PES? Good god that is old!!!
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (William Rowden)
Subject: Re: Compare 3DES's.
Date: 20 May 2000 20:45:28 GMT
In article <8g5g80$7s9$[EMAIL PROTECTED]>,
Paul Schlyter <[EMAIL PROTECTED]> wrote:
> In article <8g4lqn$1eb$[EMAIL PROTECTED]>,
> William Rowden <[EMAIL PROTECTED]> wrote:
> > . How much stronger is use of 24 bytes of key as compared with 16
> > bytes? That is, how does E(K1,D(K2,E(K3,x))) compare to
> > E(K1,D(K2,E(K1,x)))? A naive view would say that 24 bytes would
> > take at least 2**64 longer to crack than 16 bytes, but this
> > assumes that no attack more efficient than brute force is
> > available.
> 24-byte keys aren't much stronger than 16-byte keys, due to that
> attack on 2DES which reduces a 24-byte key to a 16-byte key.
Thanks! That's exactly the kind of information for which I'm looking.
Where might I read documentation of the details of this attack?
--
-William
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
------------------------------
** 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
******************************
