Cryptography-Digest Digest #271, Volume #13 Mon, 4 Dec 00 19:13:01 EST
Contents:
Re: RC4 or Rijndael (John Savard)
Journal of Craptology (Lars Knudsen)
Re: Q: Discrete transforms in practice ("Matt Timmermans")
Re: Revised cipher (Benjamin Goldberg)
Re: Crypto Proceedings ("M.S. Bob")
Re: On mutation of crypto algorithms (Benjamin Goldberg)
Re: hardware RNG's (Tim Tyler)
Re: hardware RNG's (Tim Tyler)
Re: Q: Discrete transforms in practice (Tom St Denis)
Re: Journal of Craptology (Tom St Denis)
Re: Applications of RSA - help appreciated. (Tom St Denis)
Re: MD5 byte order (Tom St Denis)
Re: hardware RNG's (David Schwartz)
Re: RC4 or Rijndael (Benjamin Goldberg)
Re: Simulataneous encryption and authentification (was IBM's new algorithm)
(Benjamin Goldberg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: RC4 or Rijndael
Date: Mon, 04 Dec 2000 20:00:28 GMT
On Mon, 04 Dec 2000 14:09:07 +0000, "Julian Morrison"
<[EMAIL PROTECTED]> wrote, in part:
>Which of RC4 or Rijndael is better for:
>
>- strength of security
Rijndael
>- ease of coding
RC4
>- speed
RC4
>- smaller key
Do you mean more secure with a smaller key? RC4 lets you use smaller
keys than Rijndael does.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Lars Knudsen <[EMAIL PROTECTED]>
Subject: Journal of Craptology
Date: Mon, 04 Dec 2000 12:31:15 -0800
Hi,
A new issue of Journal of Craptology can be found at
http://www.ii.uib.no/~larsr/crap.html
Enjoy
Lars Ramkilde Knudsen, Visiting Prof., UCSD, Dept. CSE, Off. 4101,
Tlph. +1 (858) 534-6265, Facs. +1 (858) 534-7029.
Contact info: www.ramkilde.com/sd.txt
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Q: Discrete transforms in practice
Date: Mon, 4 Dec 2000 14:50:05 -0500
Reply-To: "Matt Timmermans" <[EMAIL PROTECTED]>
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I don't have your experience but from general knowledge of
> numerical computations the finite precision of computer
> must, beginning at certain extent (size of problem etc.),
> be an issue, if there is rounding in the computations at
> all.
As long as ((a+b)-b) = a (i.e., you aren't using floating point), then
Rounding isn't a problem -- any volume-preserving linear transform, like DCT
or DFT (properly normalized), can be decomposed into a sequence of "lifting
steps" or "shears", where some coefficients are offset by linear
combinations of the _other_ coefficients. Each of these steps can be simply
inverted by reversing the sign of the calculated offsets. It works a lot
like a Feistel cipher.
As the number of input coefficients increases, however, the maximum absolute
value of the output coefficients gets larger.
> So I guess your claim of always invertibility of
> discrete Fourier transforms has to be relativated, unless
> you use a package with arbitrarily large precision to
> adapt to the actual need of the sequences being processed.
It's invertible on integers. To completely implement integer math, you need
a bignum package. It's not necessary in most real situations, however,
because the input size is bounded.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Revised cipher
Date: Mon, 04 Dec 2000 21:37:57 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
> >
> > Mok-Kong Shen wrote:
> > >
> > > 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.
>
> By 'clean' I mean it doesn't have things like DES, where
> one doesn't clearly know where the S-boxes come from (the
> issue of possible backdoor). MixColumn uses a Hill matrix
> (applied in Galois field) of a very special (in my opinion
> simple) form.
Ahh, so you're complaining that I didn't explain where/how I chose my
polys, and that they are thus not 'clean', not that the operation
*using* them is not good.
Might I ask... how was the Hill matrix chosen? Does it say that in the
Rijndael paper? I don't have the paper in front of me. I know the
criteria for the choice of the polynomial for the Galois field was
described, but why was that particular Hill matrix chosen?
> > > 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?
Actually, this is sort of an error... what I meant was replace the row
with x * 2**32 % p.
> > 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.
>
> You have to derive a number of polynomials. This (in my
> subjective view) is more complicated than setting up a
> Hill matrix (the general requirement is only that the
> matrix be invertible).
Finding primitive polynomials is indeed difficult, but only if you don't
already have a program for doing so. I do. You can download one from
the net.
I had the program print out all order-16 polys, using the 'permute'
method. This printed them in order from smallest number of taps to
largest number of taps. There were 12 maximally dense polys. Six of
them were the reverse of the other 6. I used half of the 12, then chose
2 of the reversed polys at random.
As to 'setting up a Hill matrix' ... Finding an invertable 4x4 matrix is
not necessarily an easy task, especially considering that the
multiplications and additions are in GF(2^8). I will assume that two of
the criteria that Rijndael's authors used was that the elements of the
encryption matrix have only a few bits, and that those bits be as close
to the right of the byte as possible, but what *other* criteria (if any)
were used? There were surely a fair of 'suitable' matrices, why that
one? Was it randomly chosen?
Not that I'm not claiming there's a backdoor in Rijndael, but rather
that the choice of constants used in Rijndael is by no means as simple,
straightforward, and 'clear' as you (Mok) are claiming.
--
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: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Crypto Proceedings
Date: Mon, 04 Dec 2000 21:41:15 +0000
Mok-Kong Shen wrote:
>
> "M.S. Bob" wrote:
> >
> > Mark Harrop wrote:
> > >
> > > Does anyone know of an ONLINE source of the CRYPTO PROCEEDINGS from as far
> > > back as possible ?
> > [...]
> > Or actually online:
> > link.springer.de or link.springer-ny.com
> > but access is not free or AFAIK cheap.
>
> However the cited Springer stuff doesn't give the actual texts
> of the papers, which the original poster seems to demand.
Yes, Springer's LINK does give you the actual texts, if you pay for
access (or more typically, a group/library you are associated with pays
for access).
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: On mutation of crypto algorithms
Date: Mon, 04 Dec 2000 21:59:00 GMT
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > In scaling-down, one's goal is only having something very
> > similar. One certainly can't have everything the SAME, or
> > else one would remain at the original. The MixColumn matrix
> > is actually a very special Hill matrix (in a Galois field).
> > You can look at its nature and define one of 2*2 that is
> > rather similar, keeping so to say the the 'spirit' of the
> > original. That's the best one can do and expect and with all
> > these small twists (we have changed also the ShiftRow, don't
> > we?) we can at least get a reasonable scaled-down version
> > to carry out our investigation. This is a practical
> > consideration, limited by natural constraints. Engineers
> > and architects also build models that are smaller than
> > the prototypes. It is by definition impossible to have
> > everything exactly the SAME in the models as in the
> > prototypes, only some 'approximations' and 'similarities'.
> > One has naturally to accept certain compromises. (Or else
> > why do we scale-down in the first place?)
>
> The C(x) transform is not only a "hill transform" (whatever that is)
> but also a "MDS transform". You can't change it to a 2x2 unless you
> maintain MDS properties. Otherwise the cipher gets weakers quite a
> bit.
>
> My suggestion is to resize the Rijndael structure by removing columns
> not rows.
Whatever happened to my suggestion, of using 4 bit bytes? This lets you
keep the structure identical to full Rijndael. Of course, you have to
pick a new polynomial for the Galois field, and you have to pick a new
MDS matrix, but at least the structure is the same.
--
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: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Mon, 4 Dec 2000 23:04:40 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> You *can't* deterministically convert a highly non-random stream into a
:> highly random one - while retaining your output rate.
: Your definition of "random" is so bad that in order to make it
: meaningful you _ALWAYS_ have to clarify it. We can't talk about random
: or non-random things we have to talk about "highly non-random" or
: "highly random" ones.
You can talk about randomness as an ideal.
The definition is not a bad one. It's one of the standard usages of the
term in the context of random streams.
For example tests for randomness attempt to measure the sort of
randomness I am discussing - and not ever the sort of randomness you are
talking about.
: However, this really detracts us from what was the main point of this
: thread, which you've attempted to evade by resorting to "proof by
: definition". Not only is your definition flatly incorrect, but the
: argument you're trying to squeeze by through this perverse definition is
: incorrect as well.
I'm at a loss to determine what you're talking about.
: I would submit that useful definition of "random" must be one that
: can't be increased by any determinstic process.
Where does that leave you with your entropy-condensing hash function?
: I would also argue that randomness is the same as unpredictability and
: requires positing a hypothetical predictor with specific capabilities.
Can you cope with leaving the "hypothetical predictor" role unfilled,
and positing *any* predictive - if, for example, they are only given a
stream - and not information about how it was generated?
: If a stream is predictable, it's not random. If it's random, it can't
: be predicted. No determinstic process can make a something harder to
: predict to a predicter who knows the process.
Now I believe you may be running afoul of the facts.
What about catastrophic reseeding?
Processes like Yarrow can take a low entropy stream and apply a
deterministic process to it. The process accululates entropy, and
applies catastrophic reseeding, to foil state-following attacks.
Here it is clear that a determinitstic process is making an attacker's
life *vastly* more difficult - and knowledge of the process involved does
not help him one jot.
: I would further submit that if you asked most mathematicians or
: statisticians whether the sequence "AAAAAABAABAAABAAAABAAABAAAAAB"
: appeared random, they would say that it did [...]
I guess a poll would have to be conducted to decide whether this
assrtion has any truth to it.
I don't know about you, but I would find a question asking me to
decide whether I would describe listed streams as "random" or not
to be irritatingly ill-defined.
: In fact, the first thing someone analyzing that stream would do is to
: 'compress' it by converting it to "623434", thereby concentrating the
: entropy through a determinstic process. I don't think any sensible
: person would argue that the expanded stream is somehow more random than
: the original one.
It is very likely that they would - *if* they were not told that
the streams were representations of the same information, and were
just given the streams.
It appears that - by your definition - the randomness of something depends
on how much of it you are given.
You appear to be using the term "randomness" for what would normally be
described as "entropy".
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Mon, 4 Dec 2000 23:06:54 GMT
Rob Warnock <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
: | The word does not have the universal precise meaning you seem to think.
: |
: | For example, try http://www.io.com/~ritter/GLOSSARY.HTM#Random for another
: | definition of "random".
: And for still another, try this: ;-}
: <URL:http://www.tuxedo.org/~esr/jargon/html/entry/random.html>
That's not a definition - it's ten different ones! ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Chaste makes waste.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Discrete transforms in practice
Date: Mon, 04 Dec 2000 23:09:25 GMT
In article <[EMAIL PROTECTED]>,
"Matt Timmermans" <[EMAIL PROTECTED]> wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I don't have your experience but from general knowledge of
> > numerical computations the finite precision of computer
> > must, beginning at certain extent (size of problem etc.),
> > be an issue, if there is rounding in the computations at
> > all.
>
> As long as ((a+b)-b) = a (i.e., you aren't using floating point), then
> Rounding isn't a problem -- any volume-preserving linear transform,
like DCT
> or DFT (properly normalized), can be decomposed into a sequence
of "lifting
> steps" or "shears", where some coefficients are offset by linear
> combinations of the _other_ coefficients. Each of these steps can be
simply
> inverted by reversing the sign of the calculated offsets. It works a
lot
> like a Feistel cipher.
>
> As the number of input coefficients increases, however, the maximum
absolute
> value of the output coefficients gets larger.
It's the terms of the DCT/DFT/DST matrices that make "exact" values
impossible. It's not the input itself that causes the problem.
> > So I guess your claim of always invertibility of
> > discrete Fourier transforms has to be relativated, unless
> > you use a package with arbitrarily large precision to
> > adapt to the actual need of the sequences being processed.
>
> It's invertible on integers. To completely implement integer math,
you need
> a bignum package. It's not necessary in most real situations,
however,
> because the input size is bounded.
Aha, linear integer matrices (i.e elements from Z or Q) are always
invertable. However, as I stated most other popular computer related
transforms (DCT is used in millions of computers worldwide) are not
bounded to the set of integers.
N.B older implementations of the DCT/IDCT use scaled fixed point
arithmetic which means they are bounded to a fixed size input. They
are not lossless however.
N.B.2 newer versions use scaled MMX routines (I think) and are not
lossless either.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Journal of Craptology
Date: Mon, 04 Dec 2000 23:05:33 GMT
In article <[EMAIL PROTECTED]>,
Lars Knudsen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> A new issue of Journal of Craptology can be found at
>
> http://www.ii.uib.no/~larsr/crap.html
>
> Enjoy
Funny stuff. I liked the PGB idea.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Applications of RSA - help appreciated.
Date: Mon, 04 Dec 2000 23:13:07 GMT
In article <cBSW5.17085$[EMAIL PROTECTED]>,
"Neil Smith" <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm doing a small project into Fermats little theorem, rsa encryption
and
> it's applications.
>
> I would appreciate it if people could post some uses of RSA
encryption that
> they know off. I've found out about PGP etc. and uses in internet
encryption
> but I was just wondering is RSA used for mobile phone encryption,
DVDs and
> such like?
>
> Thanks for your time,
ARRG! "DVDs and such" You cannot encrypt mass-media with a single un-
user-related key and expect security!!!
Anyways to get to your point. RSA is used (and ElGamal and ECC) to
perform online transactions, negotiate keys for other things too.
Quite a few online chat programs (filetopia, peekboo) use these "PK"
algorithms to share private keys.
If you have ever used a SSL or HTTPS online service then you may have
used one of these algorithms.
PK (Public Key) cryptography tries to solve the problem of me sharing a
private key with you (for use in a symmetric cipher obviously) despite
us being 3000miles away. The first real development was of
Diffie/Hellman in the worlds simplest key-exchange protocal. It
allowed two people/computers/dogs/cats/etc.. to calculate a shared
number that only they could easily figure out. Then came a ingenius
modification to create RSA, and the rest is history.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: MD5 byte order
Date: Mon, 04 Dec 2000 23:14:38 GMT
In article <MASW5.146048$[EMAIL PROTECTED]>,
"Bob Luking" <[EMAIL PROTECTED]> wrote:
> When applying a block of text (that is already padded) to the
MD5 "engine",
> is it to be applied bytewise big or little endian? I read from the
> specification
> that the initial seeds to A, B, C, and D are
>
> A 01 23 45 67
> B 89 ab cd ef
> C fe dc ba 98
> D 76 54 32 10
>
> But I cannot tell whether to seed A, for example, with the word
67452301 or
> the word 01234567. This word is sent to the 32 bit pipeline that
makes up
> the engine and I need to know the byte order.
If I am not mistaken MD5 follows a little endian format. You're best
bet is to check out the RFC for MD5 it includes soure code.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Mon, 04 Dec 2000 15:26:02 -0800
Tim Tyler wrote:
> : However, this really detracts us from what was the main point of this
> : thread, which you've attempted to evade by resorting to "proof by
> : definition". Not only is your definition flatly incorrect, but the
> : argument you're trying to squeeze by through this perverse definition is
> : incorrect as well.
>
> I'm at a loss to determine what you're talking about.
In other words, everyone's completely forgot what this thread is about
and it's degenerated into a definitional argument.
> : I would submit that useful definition of "random" must be one that
> : can't be increased by any determinstic process.
>
> Where does that leave you with your entropy-condensing hash function?
The function does not increase the randomness, it simply 'massages' or
concentrates it. The output is, arguably, slightly less random than the
input.
> : I would also argue that randomness is the same as unpredictability and
> : requires positing a hypothetical predictor with specific capabilities.
>
> Can you cope with leaving the "hypothetical predictor" role unfilled,
> and positing *any* predictive - if, for example, they are only given a
> stream - and not information about how it was generated?
You can posit a predictor who has no knowledge of how the stream was
generated. You can posit a predictor with full knowledge. You can posit
a predictor with both knowledge of and access to some portions of the
generator. When you think you are analyzing without any "hypothetical
predictor", what you are really doing is positing a hypothetical
predictor without realizing it.
For example, are the digits of Pi random? I don't think anyone reading
this would fail to accurately predict what comes after "3.1415". The
digits are also, obviously, compressible. When a person asks if the
digits of Pi are random, he (presumably) posits a hypothetical predictor
who is barred from directly using the fact that the digits are the
digits of Pi. In other words, he prohibits access to the algorithm.
> : If a stream is predictable, it's not random. If it's random, it can't
> : be predicted. No determinstic process can make a something harder to
> : predict to a predicter who knows the process.
>
> Now I believe you may be running afoul of the facts.
>
> What about catastrophic reseeding?
>
> Processes like Yarrow can take a low entropy stream and apply a
> deterministic process to it. The process accululates entropy, and
> applies catastrophic reseeding, to foil state-following attacks.
Right. And absent unpredictable input, this process can only produce
predictable output.
> Here it is clear that a determinitstic process is making an attacker's
> life *vastly* more difficult - and knowledge of the process involved does
> not help him one jot.
His life is not more difficult. He would have at least as much
difficulty predicting the input as the output.
> : I would further submit that if you asked most mathematicians or
> : statisticians whether the sequence "AAAAAABAABAAABAAAABAAABAAAAAB"
> : appeared random, they would say that it did [...]
>
> I guess a poll would have to be conducted to decide whether this
> assrtion has any truth to it.
>
> I don't know about you, but I would find a question asking me to
> decide whether I would describe listed streams as "random" or not
> to be irritatingly ill-defined.
Right. Because we wouldn't know what capabilities to assume on the part
of the predictor.
> : In fact, the first thing someone analyzing that stream would do is to
> : 'compress' it by converting it to "623434", thereby concentrating the
> : entropy through a determinstic process. I don't think any sensible
> : person would argue that the expanded stream is somehow more random than
> : the original one.
>
> It is very likely that they would - *if* they were not told that
> the streams were representations of the same information, and were
> just given the streams.
>
> It appears that - by your definition - the randomness of something depends
> on how much of it you are given.
No. In that case, I'm assuming that the stream continues indefinitely
'the same way'. I thought that was clear. Obviously, if the stream then
repeats from the beginning, it's not random. But please don't make a
deliberate attempt to misunderstand me.
> You appear to be using the term "randomness" for what would normally be
> described as "entropy".
Not at all. I'm using the term "random" to mean "unpredictable", which
is reasonable because that's what it means. "Entropy" is much more of an
absolute measure that is independent of the predictor assumed.
DS
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: RC4 or Rijndael
Date: Mon, 04 Dec 2000 23:34:28 GMT
Julian Morrison wrote:
>
> "Bill Unruh" <[EMAIL PROTECTED]> wrote:
> > Yes, RC4 is a stream cypher. The key can never be reused or the
> > strength is essentially zero.
>
> Can you reuse keys with Rijndael, then?
If you encrypt two files with RC4, using the same key with both, the
strength is severely decreased. If you XOR two ciphertexts, the result
is the XOR of the two plaintexts.
If you encrypt two files with Rijndael, using ECB mode (which is the
weakest mode of encrypting many blocks), security is *not* compromised
except that if two plaintext blocks are the same, two ciphertext blocks
will be the same. There is no indication from this what the *contents*
of the plaintext blocks are. If you use CBC, with a random IV (heck,
with any unique IV), two identical plaintexts will encrypt to two
entirely different ciphertexts, even if the key is the same.
> > It is very easy to code, and is much faster. However it is totally
> > useless unless you can choose a random key each use. (eg, by sending
> > the key via RSA).
>
> Random keys aren't a problem; this is the symmetric half of an
> RSA/symmetric pairing.
>
> > Uh, what is wastage of bytes? You don't want to empty the bit bucket
> > too often?
>
> Wasted bytes is network churn sending cryptocrap when it could be
> sending data. I begrudge the fat RSA results, so any wastage from the
> symmetric cypher as well is annoying.
Why not stick part of the symmetric stuff's data into the RSA
encryption? Instead of, x bit key and 1024-x bits of random padding,
send the x bit key, and the first 1024-x bits of symmetrically encrypted
data. As long as your messages are longer than 1024-x-sizeof(iv) bits,
then you aren't wasting any bandwidth at all.
--
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: Simulataneous encryption and authentification (was IBM's new algorithm)
Date: Mon, 04 Dec 2000 23:45:54 GMT
Francois Grieu wrote:
[snip]
> I tentatively propose the following symetric key encryption and
> message authentication technique:
>
> Message Authentication and Encryption
> - pad message as usual to make it n blocks of b bits M[i]
> - compute S = M[0] XOR M[1].. XOR M[n-1]
> - encipher and transmit the ciphertext
> C[0] = ENC(S)
> C[i] = ENC(M[i-1] XOR C[i-1]) for i in [1..n]
>
> Decryption and Message Check
> - reject the ciphertext if not a multiple of the block size b
> - decipher the alledged message
> S = DEC C[0]
> M[i-1] = DEC(C[i] XOR C[i-1]) for i in [1..n]
> - check S = M[0] XOR M[1].. XOR M[n-1] else reject alledged message
> - unpad the M[i] to get the plaintext
>
> Assuming known but non-chosen plaintext with S reasonably random,
> I see no attack that would suceed with sizable probability before
> O(2^b) blocks have been gathered.
>
> I believe there might be an attack with iteratively chosen plaintext
> and O(2^(b/2)) blocks, but can't get it quite right. Still, attacks
> requiring massively chosen plaintext are of little pratical interest,
> and probably even this could be fixed with a random M[0] not chosable
> by adversary (this opens a subliminal channel, though).
>
> Any attack ? Any improvement that do not increase the number of
> encryption per additional plaintext block ?
Umm, why not change S from XOR(M[0..n-1]) to hash(M[0..n-1]) ?
It certainly can't hurt, and it can help.
--
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.
------------------------------
** 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
******************************
