Cryptography-Digest Digest #267, Volume #13 Mon, 4 Dec 00 01:13:00 EST
Contents:
Re: keysize for equivalent security for symmetric and asymmetric keys (David Wagner)
Re: The Next Step After OTP (John Savard)
Re: IBM's new algorithm (David Wagner)
Re: "targeted-ciphertext" encryption? (David Wagner)
Re: keysize for equivalent security for symmetric and asymmetric keys (David Wagner)
Re: Encrypting messages in images?? (Nicholas Sheppard)
Re: The Next Step After OTP (John Savard)
Re: The Next Step After OTP (John Savard)
Re: Q: Discrete transforms in practice ("Matt Timmermans")
Re: Hole in MCRYPT_TripleDES ("Randy Sofia")
Re: collision probability with file checksums ("Scott Fluhrer")
Re: SET Protocol -- Question ("David Thompson")
Re: How to find celebrity (Benjamin Goldberg)
Re: Revised cipher (Benjamin Goldberg)
Re: Revised cipher (Benjamin Goldberg)
Re: Revised cipher (Benjamin Goldberg)
Austin (Tx) Cypherpunks - Physical Meet (Jim Choate)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: 4 Dec 2000 02:29:24 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Roger Schlafly wrote:
>I think that you know that this argument is fallacious. That is why
>you are no longer willing to make the argument yourself, but instead
>hypothesize a stupid judge who might be fooled with the fallacious
>argument.
You seem to think that this makes the mechanism pointless, but I am not
so sure.
Not many judges understand the ins and outs of crypto today, so it is not
at all implausible to think that they might be fooled, and in this case,
the mechanism might indeed be a good idea.
Ross Anderson's writings about the importance of surviving "legal attacks"
are well worth reading here. Just because the usual crypto threat model
is about workfactors doesn't mean that this is always the right threat
model; sometimes the right threat model includes smooth-talking lawyers.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Next Step After OTP
Date: Mon, 04 Dec 2000 02:28:57 GMT
On Sun, 03 Dec 2000 06:42:35 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>It is not necessarily an absolutely minimal method to achieve this:
>one could likely use a smaller table if one was encrypting in base 3,
>using a pad with six possible characters, having equivocation between
>the two other plaintexts if the ciphertext is altered.
One certainly can do it in base 3, and the table would look like this:
Key
P A B C D E F
================
0 0 1 2 0 1 2
1 1 2 0 2 0 1
2 2 0 1 1 2 0
Two tables, and in one the columns are in reverse order.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: IBM's new algorithm
Date: 4 Dec 2000 02:34:45 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
John Savard wrote:
>No technical details are in the IBM press release, let alone the news
>items on it, but IBM has a new algorithm that 'authenticates and
>encrypts simultaneously'.
>
>Of course, every secret key algorithm does that for free...if the
>plaintext makes sense, you must have known the key.
This is a misconception, but it is simply not true of most common
symmetric key encryption modes (e.g., CBC, CFB, etc.), unless you
also apply a MAC.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: "targeted-ciphertext" encryption?
Date: 4 Dec 2000 02:36:47 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David A Molnar wrote:
>Suppose I have a message M and a "target" ciphertext C = E_PK(M,r) for
>some randomized public key encryption and padding scheme E_PK with
>padding value r. How difficult is it to find a different M',r' such that
>E_PK(M',r') = C ?
For El Gamal, it is trivial. If C = E(M) and C' = E(M'), then
C*C' = E(M*M'), so generate C' = E(1) [a random encryption of "1"],
and then multiply C by C'.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Date: 4 Dec 2000 02:42:22 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Bob Silverman wrote:
>No. We would not. Look up "pro-active" security.
>Breakthroughs which make current keysizes obsolete simply mean
>that one re-signs or re-encrypts with new keys .
I am somewhat familiar with schemes for "pro-active" security (as the term
is used in the crypto community), but I do not believe that "pro-active"
security provides long-term confidentiality, in the case of encryption,
if the underlying primitive does not provide long-term confidentiality.
If your plaintext was originally encrypted under DES in 1975, and then
in 1978 you re-encrypted under Triple-DES, it is still possible to mount
an exhaustive DES-keysearch attack (2^56 work) to recover the plaintext,
if you can get access to the old DES ciphertext.
Thus, for the case of encryption, it truly _is_ important to encrypt
with a long enough key (and a secure enough cryptosystem) right from
the very beginning. I do not believe that re-encrypting helps.
------------------------------
Crossposted-To: comp.security.misc,alt.security
Date: Mon, 4 Dec 2000 08:53:50 +1100
From: Nicholas Sheppard <[EMAIL PROTECTED]>
Subject: Re: Encrypting messages in images??
On 2 Dec 2000, Scott Craver wrote:
> >A model created a method of embedding messages (like PGP)
> >inside an image so its not obvious the message is encrypted.
> >I remember she is from England and posed nude earlier in her
> >career and she invented this technique I believe.
>
> Hmmm. I know of nobody like that who created a method of information
> hiding, but I really wouldn't know if any researcher had a past as a
> model.
>
> But here's a thought: you might be thinking about Lenna.
I saw a documentary some years ago (it was screened on SBS in
Australia c. 1996) which I am guessing is the one that original poster
saw. If I remember rightly, said model was going by the name "Cipherella",
and is definitely not Lena (who is much older). I tried a few searches on
this name and some obvious variations in the spelling but nothing showed
up.
Whatever the case, a lot of work in steganography has appeared since I
saw the documentary and it should be fairly easy to dig some of this up,
see, e.g. Fabien Petitcolas' Information Hiding Homepage at
http://www.cl.cam.ac.uk/~fapp2/steganography
Hope this helps.
--
Nicholas Sheppard | Ph: +61 2 4221 5290
Research Fellow | Fax: +61 2 4221 4170
School of Information Technology & Computer Science | E-mail: [EMAIL PROTECTED]
The University of Wollongong, Australia | WWW: www.uow.edu.au/~nps
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Next Step After OTP
Date: Mon, 04 Dec 2000 02:52:16 GMT
On Sun, 03 Dec 2000 16:00:44 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>As noted in my other reply, I was simply addressing the idea that the
>OTP is inadequate _as a cipher_, so I wanted to show how one could
>advance from the OTP to something that provides an essentially random
>permutation for each symbol without having to go to a completely
>different type of cipher.
Or, essentially, given that an attractive property of a rotor machine
is that it provides a new alphabet, not merely a new displacement, for
each plaintext symbol (thus avoiding the bit-flipping problem
intrinsically),
I wanted to find out what the minimum conditions were for achieving
this desirable property.
Instead of achieving it haphazardly, by creating a very large amount
of keystream material, with multiple addition or XOR stages with
S-boxes in between - which has its own security benefits - if it is
desired to use a secure keystream generator, whether OTP, or BBS, or
whatever, in as simple and straightforwards a cipher scheme as
possible, how do I simply avoid the possibility of bit-flipping to
begin with?
(After all, with humans in the loop, there is always the temptation to
accept a sensible-looking message, and ignore the bad checksum! Of
course, _that_ could be solved by encrypting the message again, using
the checksum as a key...)
Thus, I boiled it down to the following minimum condition:
Given a set of N plaintext symbols, to be enciphered to ciphertext
symbols from the same alphabet,
devise a procedure such that:
each plaintext symbol has applied to it two keystream symbols, one
from 0 to N-1 (call it A), and one from 0 to N-2 (call it B),
with the result that
a) given a plaintext symbol p, if all keystream symbols A are equally
probable, then the corresponding ciphertext symbol q is equally likely
to be any of the N symbols;
b) given a plaintext symbol p, and its corresponding ciphertext symbol
q, if all possibilities for both keystream symbol A and keystream
symbol B are equally probable, then for any ciphertext symbol q' not
equal to q, the corresponding plaintext symbol p' is equally likely to
be any plaintext symbol not equal to p';
thus, there are exactly N-1 sets (A,B) of keystream symbols that take
p to q, and exactly one of them takes any other p' to any other q'.
This question I thought was of theoretical interest, as it dealt with
constructing an efficient keystream combiner that had the chief
desirable property of elaborate setups like simulated rotor machines.
Given that two symbols, one from a set of N symbols, and one from a
set of N-1 symbols, are involved, I am now prompted to wonder...should
my two operations be ( p * B ) + A with * and + as defined in
(shudder) ... a Galois field?
(and if so, is this connected with why Galois fields are so popular in
cryptography, because the * and + operations between them are, in an
important sense, *complementary*?)
I regret that my naivete is causing me to reinvent the wheel in public
here, but I seek understanding.
It's clear enough that q = (p*B)+A definitely has property (a) above.
(if p=0, p*B is always 0, otherwise p*B takes p to a nonzero value).
Can I deduce (b) from the distributive property? That is:
Given q and p, if q = (p*B)+A = (p*B')+A' where B' is not equal to B
(A' and A may be equal - if and only if p is zero) then if p' is not
equal to p, since B and B' are not equal can I conclude that p'*B xor
p'*B' (which is their difference as well as their sum) cannot equal
p*B xor p*B'?
Yes, from the distributive property, because B xor B' is not zero.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Next Step After OTP
Date: Mon, 04 Dec 2000 03:11:57 GMT
On Mon, 04 Dec 2000 02:52:16 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>should
>my two operations be ( p * B ) + A with * and + as defined in
>(shudder) ... a Galois field?
And before some wiseguy comes along to note this, if I define my
operations in that way, I of course need to redefine B as varying from
1 to N-1 instead of from 0 to N-2, since a zero value of B would spoil
everything.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Q: Discrete transforms in practice
Date: Mon, 04 Dec 2000 03:36:14 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:90dnau$2t1$[EMAIL PROTECTED]...
> Things like the DFT and DCT are not normally "invertable" in practice.
I wrote an invertible fixed-point DCT once -- not for cryptographic
purposes, but just so that I could open and re-save JPEG images without
loss. I've often thought, however, that NTT or something similar might make
an interesting primitive for ciphers or whitening transforms, so:
> The Fast Fourier Transform is used in numerous designs such as the CS-
> Cipher and FFT-HASH (and TC2 out of my personal collection).
Do you have a link to TC2 somewhere, Tom? Did you use an NTT or an actual
FFT? My DCT was invertible on unbounded coefficients, and it would be easy
enough to do the same thing for FFT, but NTT is the only similar thing I
know of that's invertible on bounded information sets.
------------------------------
From: "Randy Sofia" <[EMAIL PROTECTED]>
Subject: Re: Hole in MCRYPT_TripleDES
Date: Sun, 3 Dec 2000 23:22:32 -0500
Would you have any recommendations on any good books to read on encryption
and cryptography so that I could get a good handle on the terminology used
and how everything works?
I've played around many years ago with writing my own encryption algorithms
and understand the basic concept of keys but i've never steped beyond the
scope of self discovery and am oblivious to standard terminology and large
array of public functions and how they work.
Thanks,
~Randy
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: Sun, 3 Dec 2000 20:50:29 -0800
Ed L Cashin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> David Schwartz <[EMAIL PROTECTED]> writes:
>
> > Ed L Cashin wrote:
> >
> > > Why do you say that it's 2^(n/2) work for an n-bit checksum? Do you
> > > mean that an attacker needs to do 2^(n/2) tests?
> >
> > Basically, what it comes down to is how many random numbers between one
> > and 2^N do you have to pick before you have a 50% chance of getting two
> > that match.
>
> But 2^(n-1) is half of 2^n. Not 2^(n/2). So if 2^n tests are needed
> to be sure, then you're halfway there at 2^(n-1) tries.
No. You do need to pick O(2^(n/2)) numbers before you have a reasonable
probability of some collision somewhere. This is somewhat paradoxical, and
is in fact refered to as the birthday paradox. That name comes from this
puzzle: how many unrelated people do you need in a room before there a
better than 50% chance of two of them sharing a birthday. Answer: 23.
A nonrigorous[1] (but still reasonably close) way of looking at it: if you
have picked 2^k items, you have 2^k * (2^k - 1) / 2 ~ 2^(2*k-1) different
pairs of items, and if each pair has a probability 2^-n of happening to
hashing to the same item, then you would expect about 2^(2*k-1-n)
collisions, which is approximately 1 if k = (n+1)/2, which is in the right
ballpark.
[1] The lack of rigor comes in partly from the implicit assumption that all
the probabilities are independently distributed, and they aren't
--
poncho
------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: SET Protocol -- Question
Date: Mon, 04 Dec 2000 05:13:11 GMT
Stefek Zaba <[EMAIL PROTECTED]> wrote :
> In sci.crypt, [EMAIL PROTECTED] wrote:
> > I was reading through the SET Protocol specifications and I realized
> > that all documentation point towards the use of RSA and DES.
...
> SET v1.0 uses single-DES as the bulk encryption algorithm for most of the
> data transmitted. However, some data - including the super-sekrit cardnumber
> and expiry date, ... is encrypted directly in the RSA
> key of the acquirer. (There's room for this since merchant key moduli are
> 1024 bits, so you can directly RSA-encrypt that much, instead of the paltry
> 56 bits of a single DES key or 168 for 3DES.)
>
Correct up to the last clause. Actually for cardholder PI (or authtoken)
it is the acquirer key (modulus) that matters, and the merchant key
only when (and if) the acquirer returns information to the merchant;
but all RSA keys in SET are 1024 bits, except the root CA at 2048.
"Instead of" may be misleading; the per-message 1DES key
is included in the RSA encryption (OAEP block) _as well as_
the PAN, expiry, and a few other bits not relevant here.
> This is the reason for the large variety of encryption and signing
"primitives"
> in the SET documentation - some data is encrypted directly in RSA, some
> under a DES session key, and once it's been encrypted under one DES session
> key the desire is not to encrypt it again, so there are more notational
> conventions introduced....
The primitives to look for on this point are the ones with "Extra"
in the name and "X" in the abbreviation: EncX, EncBX.
There isn't really a crypto session; I call it a message key or DEK.
> As to why single-DES is the bulk cipher for SETv1.0 - well, you have to
> remember that the protocol was being designed in 1995/96, when crypto export
> rules in the US were *much* tighter than they now are. ...
> A future rev of SET might use AES as the bulk cipher, I suppose...
FWIW the message formats (using PKCS#7) could handle a new
symmetric algorithm (and/or a new public-key algorithm) without
changing the protocol, "only" changing all the implementations.
Whether and when this will happen remains unclear.
>
> If you think 56-bit single-DES is understrength, look at the vast keyspace the
> user gets to specify for a session key under which to receive messages from
> the acquirer (such as "we've declined this transaction because you haven't
> yet paid off the dinner-n-drinks-for-500-people-in-Las-Vegas"). That's a
> stonking great 40 bits - to the spec writers' credit, they couldn't bring
> themselves to describe a key that short as offering "encryption", but only
> "data masking".
>
Not really. As written AcqBackKey and AcqCardMsg
(also CaBackKey and CaMsg) can use either 40-bit "CDMF"
or 56-bit 1DES -- but AFAICT no one actually deployed CDMF
before the regs loosened, and now no one with any sense will,
so I think it will just quietly be forgotten.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: How to find celebrity
Date: Mon, 04 Dec 2000 05:44:18 GMT
Jakob Jonsson wrote:
>
> > > Among n people, a celebrity is someone who everyone knows but who
> > > knows no one. To identify the celebrity, if one exists, you are
> > > allowed to ask questions of any of the n people, but only of the
> > > form: "Excuse me, do you that person over there?" Assume that all
> > > answers are correct. Minimize the number of questions you need to
> > > ask to determine the celebrity, if one exists, or to determine no
> > > celebrity exists in a given set of n people.
> > >
> > > suggestions please
> >
> > Learn basic induction.( this problem is easily solved through the
> > use of mathematical induction)
>
> You can use induction to prove that it is possible to find a single
> candidate for the celebrity in n-1 steps.
>
> > the answer as to the minimum is n^2-n. The question then is why is
> > this true?
>
> It is not true. The answer is 3n-4.
>
> Jakob
I got 3n-2 (with method described in my other post to this thread).
How do you manage to ask 2 fewer questions? I'm certainly willing to
admit to the possibility of error, especially since when n=2, we need to
ask exactly 2 question (and 3*2-4 does = 2). So where does my math go
wrong?
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Revised cipher
Date: Mon, 04 Dec 2000 05:44:21 GMT
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > I've done a bit of rewriting on the cipher I recently sent to this
> > NG. I've added a key schedule, and written the decryption function.
> >
> > I'd like some suggestions on how to do differential cryptanalysis,
> > though. I've chosen 3 rounds, arbitrarily, so that I can test it,
> > and so that analysis can be done, but I'm certain that that's not
> > enough.
> >
> > Also, I've no idea how strong the key schedule is; I think it's
> > reasonably strong, but I'm not certain how to analyse it.
>
> May I suggest two things:
>
> 1. Post pseudo-code or algorithmic descriptions
> 2. Post source code on your website only?
>
> This will save bandwidth and help others analyze your design much
> faster.
You're certainly right on this, but there is a problem: I don't have a
website. As to 1), I did describe it, in plain text, at the big page
and a half comment at the beginning of the file.
If you want psuedocode as well:
1) prewhiten txt
2a) run 8 order-16 LFSRs using SIMD parallelism,
with the text as the seed for the LFSRs.
2b) discard the first 16 bytes of this.
2c) replace the text with the next 16 bytes.
3) use a nonlinear sbox to do a substitution on each byte.
4) add the round key to the text, using xor.
5) if we haven't done all the rounds, goto 2
> More often then not if you spend a few hours typing up a brief
> paper and print it to PostScript as a file more people will be able to
> read it.
Unfortuneatly, I'm not reel good at riting papers.
> Make sure if you do explain it that you explain the choices for all
> the primitives and the overall design. It is not enough to mention
> what you do in your cipher, you have to say why.
Ok, I'll do that now.
1) the prewhitening is so there is no unkeyed partial round.
2) using LFSRs as a linear step was chosen because LFSRs are well
understood, because that structure has been highly analysed. Discarding
bytes is done to provide better diffusion, especially wrt the first
byte. Also, for a hardware implementation [with gates and wires and
stuff], all 128 output bits of the linear layer may be calculated in
parallel, independently of each other, in spite of the apparent
computational dependencies seen in the software impl.
3) The effects of byte substitution are reasonably well known, and are
needed here to provide some nonlinearity. Also, the diffusion of the
linear step alone in no way resembles SAC -- changing the 5th bit of an
input byte can only change the 5th bit in each of some of the output
bytes. And of course, all the bytesub operations can be done in
parallel.
Got it?
As for the overall structure... The idea of the round being a linear
xform, a nonlinear xform, and a key addition, was taken from Rijndael's
structure. Except of course, my cipher is much simpler.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Revised cipher
Date: Mon, 04 Dec 2000 05:51:03 GMT
Simon Johnson wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >
> > Benjamin Goldberg wrote:
> > >
> > > I've done a bit of rewriting on the cipher I recently sent to this
> > > NG.
> > > I've added a key schedule, and written the decryption function.
> >
> > A little bit off-topic comments:
> >
> > It is in my view extremely remarkable that the authors
> > of Rijndael have succeeded to realize a fairly simple and
> > very strong block cipher. (Of the four components in its
> > rounds, three are key-independent and 'clean', while the
> > remaining one is simply an addition of the round key.)
> > Independent of Rijndael's status as the future standard of
> > encryption, this fact inevitably means an essential barrier
> > to users' acceptance of alternative future algorithms. For
> > they would ask themselves: Why complicated, if simple
> > stuffs will do? (I subjectively consider your use of LFSR
> > to be not simple.)
> >
> > M. K. Shen
> >
>
> Yeah, if your gonna use an LFSR. Why not replace the whole round-
> function with one. That allows you to have nearly any block size you
> want. Any key-size you want and it would be fast in hardware (but not
> so fast in software).
Removing the bytesub step from my cipher would be like removing the
bytesub step from Rijndael, but worse.
> As an Example, take an Self Shrinking LFSR of length 64-bits. Allocate
> 32-bits to the key shedule and 32-bits to the plain-text block. Then
> clock 32-bits out of the generator as the output of your round
> function.
Self Shrinking LFSRs are not reversible. How would you advise that I
use this in a manner which can be decrypted?
> I'd take a guess and say that this cipher is equal in security to that
> of the LFSR. And is considerably simpler than the one you created.
I have, linear step + nonlinear step + keyadd.
You suggest linear step + keyadd. Somehow, I don't see your suggestion
as leading to security.
> --
> Hi, i'm the signuture virus,
> help me spread by copying me into Signiture File
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Revised cipher
Date: Mon, 04 Dec 2000 06:03:16 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
> >
> > I've done a bit of rewriting on the cipher I recently sent to this
> > NG. I've added a key schedule, and written the decryption function.
>
> A little bit off-topic comments:
>
> It is in my view extremely remarkable that the authors
> of Rijndael have succeeded to realize a fairly simple and
> very strong block cipher. (Of the four components in its
> rounds, three are key-independent and 'clean', while the
> remaining one is simply an addition of the round key.)
What do you mean 'clean'? While I'll admit that I think that the
RowShift is simple, as is the ByteSub step, I don't think that the
ColMix is simple at all.
> Independent of Rijndael's status as the future standard of
> encryption, this fact inevitably means an essential barrier
> to users' acceptance of alternative future algorithms. For
> they would ask themselves: Why complicated, if simple
> stuffs will do? (I subjectively consider your use of LFSR
> to be not simple.)
Although my *explanation* of how I use the LFSR is [overly?]
complicated, what I actually do is not. There is probably a way of
saying it more simply than I did.
Hmm. For each of the 8 rows (which are 16 bits each), raise it to the
power of 32, under GF(2**16), with a different poly for each row?
How about: For each of the 8 rows, replace it with x**32 * p, where p is
a different order-16 poly for each row?
Or even more simple: Do a linear transformation on each rows. Can't
state anything simpler than that.
I'd like to see you describe the MixColumn operation of AES in so simple
a manner.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: [EMAIL PROTECTED] (Jim Choate)
Subject: Austin (Tx) Cypherpunks - Physical Meet
Date: 4 Dec 2000 00:07:31 -0600
Austin Cypherpunks Monthly Physical Meeting
Central Market HEB Cafe
38th & N. Lamar
2nd. Tuesday of each month
Dec. 12, 2000
7-9pm
http://einstein.ssz.com/cdr/index.html
We normaly meet outside at the tables unless the weather is bad. Look for
the red covered 'Applied Cryptography' book to identify the group. Please
visit the homepage for information on joining both the Cypherpunks
Distributed Remailer (CDR) as well as the local mailing list.
--
____________________________________________________________________
Before a larger group can see the virtue of an idea, a
smaller group must first understand it.
"Stranger Suns"
George Zebrowski
The Armadillo Group ,::////;::-. James Choate
Austin, Tx /:'///// ``::>/|/ [EMAIL PROTECTED]
www.ssz.com .', |||| `/( e\ 512-451-7087
-====~~mm-'`-```-mm --'-
--------------------------------------------------------------------
------------------------------
** 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
******************************
