Cryptography-Digest Digest #821, Volume #11 Fri, 19 May 00 14:13:00 EDT
Contents:
Reasonably secure OTP passing (Bradley King)
Re: Reasonably secure OTP passing (John Myre)
Re: NSA hardware evaluation of AES finalists ("Scott Fluhrer")
Re: About AES contest ("Scott Fluhrer")
Re: selfmodifying code ("Scott Fluhrer")
Re: AES final comment deadline is May 15 (Andrew Carol)
Re: Unbreakable encryption. (wtshaw)
Re: comparison of ciphers (wtshaw)
Re: Q: Recording on magnetic cards (Mok-Kong Shen)
Re: what is the status finite automata base cryptosystems? (Christopher Pollett)
Re: Q: Recording on magnetic cards (Francois Grieu)
Re: Interpretation of Hitachi patent claims (Mok-Kong Shen)
Re: what is the status finite automata base cryptosystems? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Bradley King <[EMAIL PROTECTED]>
Subject: Reasonably secure OTP passing
Date: Fri, 19 May 2000 11:20:48 -0400
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 (à la virtually all consumer internet commerce) then
the convetionally encrypted OTP should be virtually impossible to tease
out of the cyphertext using cryptanalysis techniques because there would
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). The logical
attack for an eavesdropper (assuming no access to either end device, a
good random number generator to create a sufficiently chaotic OTP, etc,
etc) would then be brute force upon the, say, 128 bit key symetric
transfer of the OTP. The opponent compares the result of each possible
key against the (also intercepted) OTP encrypted ciphertext until
something seems to make sense. Some sort of compression or offset of the
plaintext might also be useful here.
The point of this excercise is not to create an "unbreakable" code, but
to make certain that a brute force attack on the symetric passing of the
OTP itself is the best technique rather than some sort of cryptanalytic
study of vestigal order in the cyphertext (letter frequency or
whatever). The downside is that the exchange is a bit complicated and
the bandwidth is doubled due to the fact that the OTP is as long or
longer than the plaintext message, but I don't see either as a big deal
unless OTP generation is a harder task than I'm aware of.
OK, now tell me how stupid this is... ;-)
-Brad King
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Reasonably secure OTP passing
Date: Fri, 19 May 2000 09:50:53 -0600
Bradley King wrote:
<snip>
> =
> 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). The logical
> attack for an eavesdropper (assuming no access to either end device, a
> good random number generator to create a sufficiently chaotic OTP, etc,=
> etc) would then be brute force upon the, say, 128 bit key symetric
> transfer of the OTP. The opponent compares the result of each possible
> key against the (also intercepted) OTP encrypted ciphertext until
> something seems to make sense. Some sort of compression or offset of th=
e
> plaintext might also be useful here.
<snip>
As usual, this depends on details. As a (bad) example, suppose that
you use RC4 to encrypt the pad. That is, you send
(RC4 keystream) xor (pad)
and
(pad) xor (message)
Then the attacker can just xor these two and get
(RC4 keystream) xor (message)
which is exactly what you have for ordinary RC4, and you have gained
nothing, and cost yourself twice the bandwidth.
If you use a block cipher, or a stream cipher where the plaintext feeds
back into the keystream, then the above trick doesn't work. But still,
you have to know about how the symmetric cipher works. If there is some
weakness in it (if not, why bother with the OTP trick?), then it just
depends on how the weakness is exploited. Depending on how it works,
it is still possible that the attack (or some variation) can be applied.
Or not.
On the other hand, I don't see how the above technique can *hurt*,
except
for the complexity and bandwidth.
(Well, it would be bad if your OTP isn't really random. Then you are
using "not really random" values to protect your message, and so it
might
be cracked without looking at the symmetric cipher stuff at all! And it
would probably pay to consider that "really random" can be tricky.)
John M.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: NSA hardware evaluation of AES finalists
Date: Fri, 19 May 2000 08:53:49 -0700
Paul Koning <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Rubin wrote:
> > ...
> > Generally you can increase performance by increasing chip area, by
> > adding more pipelining and so forth. So assuming both scale the same
> > way, speed per area is still interesting. Changing feature size
> > doesn't affect the relationship either. And high performance doesn't
> > necessarily mean trying to get the maximum possible bits/sec through a
> > single cipher instance. You might want a bunch of instances on the
> > same chip, so you can do parallel encryption with different keys
>
> Yes, that can be useful. On the other hand, single stream performance
> is a really important parameter; if you have two products that both
> do 300 Mb/s but one can do it single stream and the other can only do
> it if you have at least 4 streams (i.e., 75 Mb/s single stream) the
> former clearly has the competitive advantage.
>
> Of course you can do parallel processing on several queued packets
> of a single stream (provided it's stateless, e.g., IPsec). That helps
> a bit...
Also, I would assume that if you did have a stream that did 300 MB/s, that
you would chose a mode that makes parallel processing on the same packet
easy, such as counter mode or an aggressively interleaved mode. This helps
somewhat more...
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: About AES contest
Date: Fri, 19 May 2000 09:04:54 -0700
DJohn37050 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The way I would word it is:
> The conventional "wisdom" is that Ri, Se, and Tw are good candidates and
that
> RC and MA are less so. But it all depends on what one uses for criteria.
ANY
> of the finalists are "best" under some criteria.
Stupid question: what are the criteria where MARS is the best? I
personally can't think of any...
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: selfmodifying code
Date: Fri, 19 May 2000 09:06:36 -0700
Runu Knips <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Casper H.S. Dik - Network Security Engineer" wrote:
> > Runu Knips <[EMAIL PROTECTED]> writes:
> > >However, JIT has nothing to do with self-modifying code. There is NO
> > >self-modifying code, that technique is absolutely forbidden now !
> > >For modern processors can't handle that well anymore. You would have
> > >to disable the first and second level cache to make that work.
> >
> > from a processor's viewpoint, self-modifying code and code-generation
> > on-the-fly are pretty much the same thing.
>
> Wrong. A processor which is executing JIT code can't see any difference
> to normal code. Its just the same.
Except when the JIT logic generates more code, and that new code happens to
be in memory that's already in the cache. Then, either the JIT logic or the
cache logic needs to do something. One possible something is that the JIT
logic partially flushes the cache. Another possible something would be to
make sure that the JIT never generates code onto memory that's already in
the cache, but the cache/OS architecture may not make that practical.
AFAIK, Twofish in self-modifying mode works in a similar manner. The key
expansion takes a key, and expands in into a function that encrypts/decrypts
that key. If it can partially flush the cache where the newly generated
function lives, this is workable.
Now, I was under the impression that the performance gain you got with
Twofish was pretty marginal, so I don't know the performance gain is really
worth the bother. But I suppose if you're *really* desperate...
> On the contrary, a processor executing self-modifying code has always to
check if there isn't already an updated version of the code it is currently
executing. This means, it has to disable its code cache, or its code cache
has to be far more complex that it normally (or often) is.
That is true if the self-modifying code totally ignores the cache.
>
> > In an ideal world, modifications written to instruction space not
> > previously used would not have landed in the Icache; but cachelines
> > are larger then instruction so they often are.
>
> The code cache has not seen those values written by the JIT compiler
> before, while with self-modifying code there is already some code in
> those caches.
Unless you have a unified cache, of course. Not currently in fashion, but
they do exist...
>
> The only way to get selfmodifying code work efficiently is when you're
> able to always put the new version at a new address, or if you have
> some comfortable cache which allows to throw out every instruction
> which has been changed.
Or you can get it to do a partial flush at times, and use it in the (rare)
circumstance that you do need to generate a new executable segment. Many
caches support such an idea.
--
poncho
------------------------------
From: Andrew Carol <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Fri, 19 May 2000 09:43:48 -0700
In article <8g3c8p$1p3$[EMAIL PROTECTED]>, Casper H.S. Dik -
Network Security Engineer <[EMAIL PROTECTED]> wrote:
> from a processor's viewpoint, self-modifying code and code-generation
> on-the-fly are pretty much the same thing.
There is a significant difference. In the case of code generation, the
actual generator is NOT modified and can therefore be reused from the
instruction cache quite quickly (keying several streams at once?).
The instruction cache may not need any flushing or only flushed before
the code in a new area is actually executed. Self modifing code tends
to need immediate flushing.
--- Andy
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Unbreakable encryption.
Date: Fri, 19 May 2000 10:03:29 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> "Douglas A. Gwyn" wrote:
>
> > Mok-Kong Shen wrote:
> > > It is yet 'entirely' not clear to me why do you need real arithemtics
> > > of infinite precisions in encryption at all. Could you show an example?
> >
> > People who base their cryptosystem's theoretical security on properties
> > of the real number system require absolute precision in implementation.
>
> I was questioning in the context of base conversion (and encryption).
> Base conversion may, for exact results, under circumstances need
> infinite precision, but only when converting numbers with digits behind
> the decimal point. One knows that well when converting between the
> decimal and the binary system. However, for whole numbers, which
> is likely to be the only case interesting for encryption (that's why I
> asked for a counter-example), no such problem arises, since any
> representation in any base must be finite.
>
> M. K. Shen
To deal with numbers, you deal with their representation as characters.
Putting anything normally expressable in any fashion is no problem. In
processing, you only have integers to deal with. The biggest barrier here
is mental, to see any data as just more of the same, just more keys that
are pressed, or pixels that are visable.
A note regarding good intensions: Believe it or not, a 13th algorithm
jumped up and became so obviously important as a final addition to the
current family of algorithms at hand that it begs to be done. More delays
I guess, but the mathematics and logic of these things seem to have a life
of their own; I just work here.
--
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: comparison of ciphers
Date: Fri, 19 May 2000 10:15:54 -0600
In article <[EMAIL PROTECTED]>, Lieven Trappeniers
<[EMAIL PROTECTED]> wrote:
> Hello All,
>
> is there any survey available that discusses the amount of security
> offered by various encryption algorithms ? How do DES and 3DES relate
> to blowfish, IDEA, ... concerning intrinsic strength of the algorithm
> ? (and of course, what is the influence of the key size).
>
> As a non-specialist having to implement encryption, I am looking for
> information in order to differentiate between the available algorithms.
>
> I apologize if this question has a rather high degree of FAQness.
>
> Thanks,
>
> Lieven.
You ask a loaded and embarrasing question. The answer depends on what you
know, We generally are forced to admit to not having enough answers to
relevant queries.
The good news is that anyone that has a definitive answer, if there is
such a thing, is not talking. More embarrasing questions about strength
are pending. It is not that it does not exist, but I figure that it
cannot be as simple an answer as you probably want.
--
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: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Recording on magnetic cards
Date: Fri, 19 May 2000 19:03:34 +0200
Francois Grieu wrote:
> <[EMAIL PROTECTED]> wrote:
>
> > How is it possible that the update action (presumably with a
> > relatively strong magnetic field) on the paying card has no
> > interference on the neighbouring credit cards
>
> First, the write field used for magnetic cards is very concentrated,
> and decreases quicly with the distance, something like F(d) = (d0/d)^2
> with d0 say like 0.1 mm
>
> Second, many systems only read a serial number on the card, and store
> the balance of the card's account in a database external to
> the card, with the benefits that
> - the account can be reloaded without using the card
> - if the card is lost, is can be blacklisted and replaced without
> loosing the balance.
No. There is no external database. I happen to have such a card
too. There is a machine at which one can load sums onto the
card with bank notes. Then at the pay-desk the amount to be
paid is computed by a PC connected to an apparatus that
deducts the sum from what is currently recorded on the card.
I have seen people simply put a thick wallet containing the
paying magnetic card and a bunch of credit cards and of
course also lots of coins. It seems that the orientation of
the card relative to the apparatus is also immaterial. I can't
yet understand how the magnetic field employed to update
the amount registered on the paying card doesn't have
ANY effects on the neighbouring credit cards.
M. K. Shen
------------------------------
From: Christopher Pollett <[EMAIL PROTECTED]>
Subject: Re: what is the status finite automata base cryptosystems?
Date: Fri, 19 May 2000 10:18:04 -0700
"Douglas A. Gwyn" wrote:
> Christopher Pollett wrote:
> > Can anyone out there tell me what the current status of finite
> > automata based crypto systems?
>
> What do you mean by that term? Practically any cryptosystem can
> be thought of as a finite-state automaton. If you mean, cellular
> automata, they don't seem to be used very much if at all, perhaps
> because they seem to offer no clear advantage over better-understood
> cryptosystems.
Hi I mean the systems first developed in China by Renji Tao.
Chris
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Q: Recording on magnetic cards
Date: Fri, 19 May 2000 19:25:08 +0200
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> It seems that the orientation of the card relative to the apparatus
> is also immaterial.
If the card is indeed a magnetic card, it is not sensitive to magnetic
fields that remain below some threshold depending on the hysteresis
and coercitivity of the magnetic material. Writing occurs by generating
a strong but very local field that goes over this threshold, again
with a range like 0.1mm.
If there is no close physical contact with some form of sliding
between the card and reader, then it is not a magnetic card.
Maybe a contactless IC Card, where induction between a coil in the
reader and a coil in the card is used to communicate, and possibly
power the card. ISO 14443 is/will be a standard for such cards.
Francois Grieu
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Fri, 19 May 2000 19:53:13 +0200
Richard Heathfield wrote:
> I would be most interested in seeing Hitachi's letter. Unfortunately,
> it's in pdf (Portable Document Format) which, ironically, doesn't work
> on my system. Is it available anywhere in a portable document format
> (i.e. ASCII text)?
The two claims of Hitachi are in the attachment below.
I hope that some native English speaker of our group
would kindly translate the material into concise and clearly
comprehensible mathematical form to enable concrete and
precise discussions on the issue.
Some remarks:
1. In German there are authors who are fond of writing
exceedingly long sentences, with one sentence for a
paragraph. I have however NEVER seen such in English
before. Maybe the lengthy sentences in the patents are
there because they are of Japanese origin?? I conjecture
that the patent reviewer in the US Patent Office probably
hasn't himself fully understood what has passed through
his hands.
2. I believe that, if we have a good translation into
mathematics, then there may indeed be a good chance of
finding weakness in the patent claims through careful
scrutiny by many persons of our group. I am not very
sure that the terms e.g. 'pair of data', 'predetermined
number of bits', 'process' etc. are precisely defined
in the documents to such a degree that the patents can
claim to unambigiously cover a rotation operation in
in computer in the most general case.
M. K. Shen
===========================================
USP5,103,479 claims:
"Claim 1. An enciphering method for converting a pair of plain
text data into a pair of ciphertext data by sequentially
performing a plurality of encipherment processes on said pair
of plaintext data, each of encipherment processes having a
function to restore a pair of ciphered text data to a pair of
former text data if each of said encipherment processes is
performed again on said pair of ciphered text data, comprising
the steps of: performing a first encipherment process for
deriving a first pair of data from said pair of plain text
data; performing a second encipherment process for deriving a
second pair of data from said first pair of data by circular
shifting of first intermediate data derived from one of said
first pair of data by a first predetermined number of bits;
performing a third encipherment process for deriving a third
pair of data from said second pair of data by circular
shifting of second intermediate data derived from one of said
second pair of data by a second predetermined number of bits
which are different from said first predetermined number of
bits; and performing a fourth encipherment process or other
encipherment processes by deriving said pair of ciphertext
data from said third pair of data."
"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; performing a second process for generating third
intermediate data by circular shifting of said first
intermediate data by a first predetermined number of bits;
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."
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: what is the status finite automata base cryptosystems?
Date: Fri, 19 May 2000 19:57:31 +0200
Christopher Pollett wrote:
> Hi I mean the systems first developed in China by Renji Tao.
Probably you should give the relevent pointers.
M. K. Shen
------------------------------
** 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
******************************
