Cryptography-Digest Digest #852, Volume #12 Thu, 5 Oct 00 17:13:00 EDT
Contents:
Re: It's Rijndael (David Crick)
Re: CRC vs. HASH functions (Bryan Olson)
Re: Idea for Twofish and Serpent Teams (Albert Yang)
Re: It's Rijndael (Doug Kuhlman)
Re: Choice of public exponent in RSA signatures (David Hopwood)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: TEA (David Wagner)
Re: Deadline for AES... (Mok-Kong Shen)
Re: Need help: considerations for IV and Keysetup (Eric Lee Green)
cryptanalysis of TC8 (Tom St Denis)
Re: cryptanalysis of TC8 (Tom St Denis)
Re: Authenticating a PIN Without Compromising the PIN ("Arnold Shore")
----------------------------------------------------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Thu, 05 Oct 2000 20:05:10 +0100
Volker Hetzer wrote:
>
> The AES's guys argument was that you can't simply attach or
> trim rounds without affecting key schedule and perhaps other
> properties too. So, each proposed number of rounds has to
> be analysed.
> Unless round flexibility is *designed* into the algorithm
which it was with Rijndael
> as proposed by Runu, modifying the round number makes
> IMHO little sense.
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Date: Thu, 05 Oct 2000 19:00:36 GMT
Mack wrote:
> 1) CRC are faster than HASH functions of
> comparable size. That is a fact. Many
> hash functions use a CRC like layer at the
> top to mix in data linearly. SHA-1 is no exception.
> A table driven 256 bit hash function requires 4 32-bit word
> lookups/byte, four 32-bit word XORs, a shift and an XOR
> to add data.
A table driven hash function? Did you mean a CRC? In any
case, I'd like to see the algorithm to compute a 256 bit
result with the stated operations.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Idea for Twofish and Serpent Teams
Date: Thu, 05 Oct 2000 19:11:08 GMT
Except two people who know what they are doing won, not a single naked fat
guy who goes fishing all the time...
Albert
"SCOTT19U.ZIP_GUY" wrote:
>
> If you look at this like the survivor series. It is quite possible
> they all picked Rijndael since they expected it to lose. It would be
> interesting to ask that same question today. It would provide a lot
> of insite to how these people really think.
>
>
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> Scott famous encryption website **now all allowed**
> http://members.xoom.com/ecil/index.htm
> Scott LATEST UPDATED source for scott*u.zip
> http://radiusnet.net/crypto/ then look for
> sub directory scott after pressing CRYPTO
> Scott famous Compression Page
> http://members.xoom.com/ecil/compress.htm
> **NOTE EMAIL address is for SPAMERS***
> I leave you with this final thought from President Bill Clinton:
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Thu, 05 Oct 2000 14:04:38 -0500
Mok-Kong Shen wrote:
>
>
> I have the impression that increasing rounds is no problem
> for Rijndael. If this is done by its own team, it appears
> to be not too risky in 'extrapolating' to say that the
> result would also be o.k. just as at the present. Those
> who are very conservative could apply a safety factor
> to take into account of any presumed eventuality, I suppose.
>
At the complete sacrifice of interoperability (as it's currently set
up). And a loss in speed. For a questionable increase in security. No
thanks.
------------------------------
Date: Thu, 05 Oct 2000 18:06:27 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Choice of public exponent in RSA signatures
=====BEGIN PGP SIGNED MESSAGE=====
Benjamin Goldberg wrote:
> David Wagner wrote:
> > Yes, I am familiar with those attacks. As I said, with proper use of
> > random padding (e.g., OAEP), the attacks do not apply. Thus, I do not
> > see why they should provide a justification to prefer e>3.
> >
> > And, in real life, everyone uses random padding, and the random
> > padding is large enough to avoid Coppersmith's attack. Hastad's and
> > Coppersmith's attack are of great theoretical interest, but they do
> > not apply to any real-world implementation that I know of.
>
> Doesn't the security of using OAEP depend on the security of the hash
> function, H, and the generator, G?
Yes.
> The paper on OAEP which I read
> simply used a random oracle model for H and G... practical
> implementations need to use real functions, like SHA1 for the hash, and
> RC4 or SEAL or <pick-your-favorite-cipher>-OFB for the generator.
In practice the generator (or "mask generation function") is normally
MGF1 (see the references to PKCS #1 v2.0 and P1363 I posted earlier),
which is basically a hash of the seed and a counter. This avoids depending
on the pseudorandomness properties of anything other than the hash.
The random oracle model can be criticised on the grounds that
technically, a deterministic function like a hash cannot behave like
a random function, and in some artificially constructed examples, a
"secure" hash function will not suffice as a random oracle. See [1]
for some discussion of this, and counterarguments. I don't think this
is likely to be a problem for OAEP, but it would still be useful to
have a proof of the security of a scheme similarly efficient to OAEP,
in the standard model.
> How much does this affect security?
If there were minor weaknesses in the hash or mask generation function,
this probably would not have much effect on practical security. Note
that the hash is acting on an input that is already pseudo-random and
cannot be influenced by an attacker, and only a small amount of output
is taken from the mask generation function. Also, collision attacks
are not a concern; only non-randomness in the output of the hash or MGF.
[1] Mihir Bellare, Phillip Rogaway,
"Minimizing the Use of Random Oracles in Authenticated Encryption
Schemes"
(probably on Rogaway's home page at http://www.cs.ucdavis.edu/~rogaway/)
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOdv6KjkCAxeYt5gVAQFpUggAqyUhlAf8/rhpdSOZnN4RlEiciR5L2F99
YIYpCmsGo0yzqvAXY7B4/9SU4JH0itcyQb5OKQZ9OATUrXCSgmQWGO5UxAKlqPdD
JH/mYEQXhD9wwnuiT5CB6BlmbIiXel+dcOlTXx/cDezjzSD2KY0PfYmFciskagSl
OqdRrJP5NNVyHrkp7waQj20FBtXxh6JB4Kp2kmh2cb8grm/Gb+YuDBcPWbLy5VMf
UqwpMuVN9SdtrjVKpCfVFHIn617KVJk9WWDA46ZbkTXVMN3eI0Kt4wu2XPI6dKXT
NVPGrxe3UhiBBKCjzt+jukiZPmE4CR5ZuRnmHkogGLD8guHmoYwFzA==
=nkBt
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Thu, 05 Oct 2000 22:18:19 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> [...]
> > Now please tell me what if there is no permutation
> > at all and you have before you the original block cipher
> > and you use a chosen ciphertext on it. Would that involve
> > less work or more work than in the case with permutation as
> > I described? I like to have a definite answer and a tiny
> > bit explanation for that.
>
> If you think your question is so important, why are you
> unwilling to work on it? I think it's nonsense, based on not
> studying the issues. How much work is it to break an
> unspecified block cipher? Have you even thought about whether
> the question is well-formed enough to make sense?
Since you seem to claim that with permutation is poorer
than without (i.e. with the original block cipher) that
clearly would interest me (for the usefulness of the
scheme). Since you are the 'author' of the attack you
conceived, you are the person that can at least give
some useful information, isn't it? Having said the above,
why do you think it is not well-formed? Could you
elaborate that? I want to know whether there is
reduction or enhancement of strength. Is this issue
not well-formed? Where?
>
> > Please do answer my question this
> > time. If you really want to 'laugh', as you indicated in
> > the following part that I snipped, you can do that much
> > much better later on, if indeed you succeed to win your
> > arguments. I am not used to discussions where people don't
> > express their direct opinions. We are discussing science,
> > not politics or theology, etc.
>
> I see nothing in your writing that qualifies as science. I
> explained one way your system fails as directly as I could in
> my very first post in the thread. I later provided further
> detail when it seemed unclear to you. I see no evidence that
> you made any serious attempt to understand either what I wrote
> or the subjects you brought up yourself. In one case, I
> believe you deliberately played dumb, claiming that you could
> not understand my language.
I described my scheme and you even attempted to work
out a method of attack. If you call that not science,
what was the nature of your own work? If you think
that others in this group is not doing work at a level
as high as yours, then you need not deal with them, nor
even subscribe to the group. Simply claiming that others
are at lower level doesn't automatically lead you to
a higher level per se.
>
> > > > The seed of PRNG is of course not to be reset, as I
> > > > mentioned previously several times.
> > >
> > > Then you'll inevitably lose synchronization between sessions.
> >
> > There is fortunately a tradeoff of disadvantage/advantage.
> > The loss of synchronization allows namely the detection of
> > the attack, which cannot be detected for the original block
> > cipher under the same chosen ciphertext attack. Depending
> > on the application, the gain may even overweigh the loss.
>
> The point is that the scheme inevitably loses synchronization
> even in the absence of any attack. How would you handle two
> simultaneous streams? If we have some stored ciphertext, how
> would we know what state to use to decrypt? If we backs up
> keys, how would we restore the PRNG state? If you need a
> different state for each message or session, you can either
> describe the mechanism that provides it or state that the
> system depends on an outside means.
The state of the PRNG at the start of a session (the
first if many sessions to be used with the same secret
material) is given by the secret seed. At the end of
the session the current seed can be stored for use
in the following session (if there are many sessions).
So unless there are attacks of your kind, there is
no problem in synchronization. In certain numerical
computations that is interupted for user reasons,
one employs the same technique.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: TEA
Date: 5 Oct 2000 20:15:10 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Runu Knips wrote:
>Btw, there is a very good russian cipher, GHOST.
I'm not sure I'd call it "very good".
It hasn't seen much scrutiny in the open world, and I wouldn't
recommend it for use.
Use a trusted cipher; 3DES, if you can afford it, or AES, if not.
(It is usually spelled GOST, by the way.)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Deadline for AES...
Date: Thu, 05 Oct 2000 22:36:32 +0200
David Crick wrote:
>
> Mok-Kong Shen wrote:
> >
> > > Would you please point out what is incomplete in the documentation of
> > > *any* of the finalists?
> >
> > The most conspicuous one and about which I have the
> > most concern is that there are lots of numbers (numerical
> > constants) whose derivation is not clear to the reader,
> > i.e. these cannot be reproduced by them in some way. This
> > provides an essential ground to nurish doubts about the
> > absence of backdoors. Certainly it hinders a proper
> > understanding and hence probably also analysis.
>
> Section 7 of the Rijndael submission document explains the
> reasons for the design choices. Is there anything in there
> that you are not happy with?
I want specifically to be able to re-calculate every
number that is in a cipher. If certain groups of numbers
are said to have been chosen to lead to a certain property,
I like to be able to run a program to verify that that
property is indeed (optimally) achieved. The document (or
supplementary materials) needs to be concrete enough so
that such a program can be very easily written. (A well
documented program provided by the author would also
be desirable.) Evidently, this desire is far from being
satisfiable by the current documents of any AES candidates.
M. K. Shen
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Need help: considerations for IV and Keysetup
Date: Thu, 05 Oct 2000 13:32:05 -0700
[EMAIL PROTECTED] wrote:
> moreover, practically able to do to secure data. Btw, tape backup
> applications based on windows do not offer any adequate encryption
> features. Many backup programs use the QIC-113 standard to store data.
> Here you have the possibility to set a password - a password which is
> simply stored as PLAINTEXT in one of the beginning blocks of the tape!
> So much for security...
And then they charge you money to send the tape to them so that they can
"unencrypt" the tape in case you forget the password :-).
(No, we've never done that, but one of our employees remembered doing that
during his tenure at another tape backup company... he said they had a utility
which stripped the header off, dumped the tape to a disk file, created a new
header with a blank password, then dumped the concatenation back onto that
tape... and they charged some outrageous sum of money to do this to
"unencrypt" tapes for people who'd forgotten their passwords).
BTW, that is one of the reasons why I'm somewhat reluctant to add on-tape
encryption. So the sysadmin leaves, and takes the backup password with him.
Now what? Backups which can't be restored are pretty useless :-(. And, if you
have adequate physical security (i.e. don't leave tapes lying around! Keep
them in a vault!), the encryption buys you nothing (unless you're paranoid
that government storm troopers are going to burst in and confiscate your tapes
and make copies of all your valuable kitty porn for use in court, in which
case you have problems far more serious than unencrypted backup tapes). And
the encryption can potentially lose you everything you own, if the tapes whose
password walked off happen to be year-end accounting system backups that can
prove that you are not defrauding the IRS of their rightful slice of your pie
(when dealing with the IRS, you are guilty until you can prove you are
innocent).
If, on the other hand, you are doing network backups over insecure
communication lines, encryption of backup data streams going over the network
is an obvious Good Thing (tm). But that's a different issue altogether. (And
if you look at http://twofish-py.sourceforge.net , and add that info with who
my employer is, you may get an idea of what I'm up to on this front :-).
BTW, it would be nothing to add CBC or CFB-128 encryption at the tape block
level for BRU 16.1. We obviously do not lack the in-house cryptographic talent
to do so (in fact we have at least three people in-house who could do it),
Rijndael (the algorithm we would use, since "AES" will be a good marketing
buzz-word for the marketing types) is quite fast so it would not slow us down
significantly, and each block is tagged with a unique 16-byte
archiveid/sequence # pair so we have an obvious IV to use for encrypting the
data payload. Still debating whether we should do it though. Can you really
call it a backup if you can't recover the data?
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: cryptanalysis of TC8
Date: Thu, 05 Oct 2000 20:26:12 GMT
Well I thought of how to attack it and here we go. It would help if
you look at the structure of the CS-Cipher by Serge Vaudenay to
understand what TC8 does.
Essentially at the core I pair up all the inputs (8 bytes) into a 16x16
(bit) M Function. The M function is it's on inverse since it's an
unkeyed three round feistel.
Now to apply a differential to it we must control the differences
through the M functions. Since the only key is the input whitening and
the sboxes have a max XOR value (xor-pair) of 4/256 we can drive a
characteristic (differential) through any M function with a probability
of 4/256 (1/64). This also means that the M function is a
multipermutation (2,2) with a probability of 63/64 (try it
out... :) ).
So in the first round (let's assume the M function is a
multipermutation with prob 64/64). Then the first step will have a
probability of 1/64 since we are attacking one M function. Since the M
function is a multip we know that two M functions will have differences
in the second step for a probability of 1/64*1/4096=2^-18. Finally in
the last step all four M functions will be active for a probability of
2^-6 * 2^-12 * 2^-24 = 2^-42. I could be wrong, but I think each step
is "independent" of each other such that you have to attack each step
as if they were "rounds of a feistel".
Then in six rounds the attack has a probability of 2^-6(42) = 2^-252.
Out of dream world for now. The M function isn't always a
multipermutation though. In fact there is a 2^-6 that your difference
causes a difference in only one byte (i.e differences of the form (a,0)
or (0,a)). This means in fact the entire round can have a difficulty
of about 2^-3(6) = 2^-18 and all six rounds as 2^-6(18) = 2^-108.
Since the M function never changes I think a "generic" type of attack
can be built and the inputs rotated such that all key bytes are
extracted.
Please comment if you can, I would appreciate the help. If my analysis
is right then four rounds is sufficient to block the attack with a max
differential prob of 2^-4(18) = 2^-72.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: cryptanalysis of TC8
Date: Thu, 05 Oct 2000 20:50:42 GMT
In article <8rio4q$nkr$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Well I thought of how to attack it and here we go. It would help if
> you look at the structure of the CS-Cipher by Serge Vaudenay to
> understand what TC8 does.
Sorry... forgot.
You can get TC8 from http://www.geocities.com/tomstdenis/files/tc8.c
And a triplet is
PT: 01 02 03 04 05 06 07 08
CT: ce bb ea 0e 78 49 4e d0
KEY: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15
16 17 (basically 0..23)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Arnold Shore" <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: Thu, 5 Oct 2000 17:12:41 -0400
Agreed that PIN's are typically too short. Address that (at least in part)
by appending the userID prior to the hashing, which might provide the
measure of difficulty you want.
There's a couple of MD5 Javascript functions around, allowing full
client-side operation. A piece of cake!
Arnold Shore
Ananpolis, MD USA
"Guy Lancaster" <[EMAIL PROTECTED]> wrote in message
news:8rd6d8$4a9$[EMAIL PROTECTED]...
> If it's possible, how could a protocol authenticate a user's
> PIN without revealing information that would make it
> relatively easy to determine the actual PIN value?
------------------------------
** 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
******************************
