Cryptography-Digest Digest #639, Volume #14 Mon, 18 Jun 01 14:13:01 EDT
Contents:
Re: Is ECB truly more secure than CBC? (John Myre)
Re: Is ECB truly more secure than CBC? (John Myre)
Re: My auction protocol (AY)
Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, ("Douglas A.
Gwyn")
Re: Any good Crypto Books? (Ross Anderson)
Re: Help on GF(2^N) (Mark Wooding)
Re: Bizzare Cryptanalysis (Mark Wooding)
Re: Help on GF(2^N) ("Jakob Jonsson")
XOR256 encryption/decryption method (George Anescu)
Re: quadratic functions ("Tom St Denis")
Re: BigNum Question ("Tom St Denis")
Re: XOR256 encryption/decryption method ("Tom St Denis")
Re: Is ECB truly more secure than CBC? ("Tom St Denis")
Re: SHA2 PRNG. ("Tom St Denis")
Re: Help with error correction (63,48) code (Mike Rosing)
Re: Bizzare Cryptanalysis ("Simon Johnson")
Counter mode, the better way to do it? ("Julian Morrison")
Re: Counter mode, the better way to do it? ("Tom St Denis")
Re: Bizzare Cryptanalysis ("Simon Johnson")
----------------------------------------------------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Mon, 18 Jun 2001 09:46:26 -0600
Tom St Denis wrote:
<snip>
> If you look at what these YAPL (Yet Another Programming Language) provide,
> typically more often than not it's a self-righteous need to feel proud of
> re-inventing the wheel.
<snip>
Pot calling the kettle black, I'd say.
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Mon, 18 Jun 2001 09:59:56 -0600
Paul Pires wrote:
<snip>
> I apologies if I have offended both to you and the OP.
No apology needed (for me, anyway; I won't ask for the OP).
> Now that that is out of the way, I did read it differently
> than you and perceived a disparaging tone that you did
> not. I felt his characterization was misleading. He could
> have just posted Joe's words and asked for comment
> but he set it up in a biased fashion.
No trouble, to each his own. And of course, I could be
biased, too.
>
> > presenting himself as a cryptography expert.
>
> That wasn't clear from the referenced post.
Perhaps not, but I think it is reasonable to conclude that
Joe has posted several times, with various specific opinions.
In a non-crypto group, it would be easy to take such posts as
implicit claims to competence.
> > he offers an argument as to why ECB mode should be supported in addition
> > to CBC!
>
> Mr. Ashwood made no such recommendation.
I think he did, actually. Although I can't remember exactly,
so perhaps it was somewhere else.
> >Should someone who supports the use of ECB mode be
> > considered an expert in a forum where not everyone is knowledgeable
> > about cryptography? It is very worrisome what form the standard will
> > end up taking when this is what passes for expert cryptographic advice.
>
> "passes for expert cryptographic advice." That's disparaging.
Yeah. If I were Joe, I guess I'd take offense.
> As far as the, "Take Prozac" part goes, it was working a bit
> too hard at being cute. I didn't mean to suggest that he was
> mentally ill, just that it was a little hysterical. Perhaps a
> different pharmaceutical would have worked better.
> Upon reflection, I'm in a grumpy mood and it was a cheap
> shot.
>
> Have I used up my quota yet?
:)
You're *way* behind certain others, in both grumpiness and
cheap shots. Just don't forget to take, uh, never mind.
JM
------------------------------
From: AY <[EMAIL PROTECTED]>
Subject: Re: My auction protocol
Date: Mon, 18 Jun 2001 17:06:37 +0100
>
> How would the user know that this information was correct?
> Couldn't the auction server record dummy bids in an attempt to push up the
> price?
> This idea is explored in The Cocaine Auction Protocol by Ross Anderson.
Thanks for this. Yes I have read Ross Anderson's paper. I think this
operates at two levels.
First of all the auction server cannot insert dummy bids by prtending to
be a registered user because the bid message is signed by the bidder,
and the keypair is generated by the client side software. It is assumed
that the auction server receives the correct public (verification) key
to users during registration, i.e. no man in the middle attacks.
But at another level, there is nothing to stop the auction server to
generate a keypair and register itself to the system. I think this is
hard to avoid if not impossible, but there's always a chance that the
server will become a winner which might be an disincentive for them to
do so. Similarly it's hard to stop the seller himself registering as
another user to push up price, or he could simply ask his brother to do
so. It's hard to avoid in traditional physical auctions as well,
therefore I will not attempt to solve this problem, at least not now.
One point I'm not sure whether is clear my original post is that there
are three auction entities: the seller, the server and the bidder, like
eBay, where the server host the auction on the seller's behalf (for a
price). Correct me if I'm wrong but I think in Anderson's protocol the
seller himself _is_ the server, and a broadcasting primitive is also
assumed, which is unrealistic in the Internet environment. There is also
a real-time assumption as well. His protocol therefore is more suitable
in a LAN environement (I think this is mentioned in the paper) as
opposed to the Internet, which is my aim of the project. Sorry if this
wasn't clear before.
AY
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack,
Date: Mon, 18 Jun 2001 15:36:00 GMT
Mok-Kong Shen wrote:
> saying that he hadn't read that book himself, ...
> he expressed certain doubt that a
> person like me without the courses he mentioned could
> read that book in a non-trivial sense.
How would he know, if he hasn't read it himself?
> BTW, are you still in possession of that book?
It's buried somewhere in my collection of unopened boxes
from the last time I moved.
------------------------------
From: [EMAIL PROTECTED] (Ross Anderson)
Subject: Re: Any good Crypto Books?
Date: 18 Jun 2001 16:49:17 GMT
> Both Applied Crypto and the Handbook of Applied Crypto touch on the
> theoretical side of crypto. They are good books, references, etc...
>
> Hmm books on actual cryptosystems? I dunno. It's not a popular topic.
> [not buzzward compliant!]
My new book `Security Engineering' is probably what you're after.
I describe the workings of cash machines, IFF, GSM, remote car door locks,
prepayment utility meters, burglar alarms, copyright management systems,
smartcards, and many more actual applications. I have lots of details on
how they've been broken in the past.
See http://www.cl.cam.ac.uk/~rja14/book.html
Ross Anderson
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Help on GF(2^N)
Date: 18 Jun 2001 16:49:57 GMT
Phil Carmody <[EMAIL PROTECTED]> wrote:
> Can anyone give an example demonstrating why /irreducible/ polynomials
> are not /prime/ in GF(p)[x]? (i.e. a C=AB=XY for irreducible A, B, X, Y.
> I understand (but can't instantly prove) that the field is not a unique
> factorisation domain, I'd just like an example to sweaten the idea).
GF(p)[x] (or, as I prefer to write it, F_p[x]) is not a field: it's a
polynomial ring. It *is* a unique factorization domain. See
http://www.maths.nott.ac.uk/personal/jec/courses/G13NUM/notes/node9.html
for a proof.
> Are there any (families of) GFs that are UFDs?
A nontrivial field can't be a unique factorization domain. Indeed,
there's no concept of a `prime' in a field. Let F be some field.
Select any distint x, y \in F, with neither equal to 0 or 1. Then there
exists a z, not equal to x, 0, or 1 such that x = y z. (Specifically,
choose z = x y^{-1}.)
> Side question (not that important, just curoisity) - Is there such a
> thing as an 'infinite' GF (no finite N)? (I feel I could construct a
> ring that behaves that way, but whether it's actually a field is another
> matter).
I had the impression that a Galois Field was by definition finite.
There are infinite fields, e.g., Q, R, and C.
> When trying to express elements of GF(2^N) in 'polynomial' form, does
> it make any difference what irreducible polynomial in GF(2)[x] I
> chose? I assume all of the choices yield isomorphic fields?
Yes. For any given q = p^f (for prime p and positive integer f), there
is exactly one field with q elements, up to isomorphism.
> How many such polynomials are there?
Quite a few. For each prime p and integer f > 1, there are \phi(p^f -
1)/f /primitive/ polynomials in F_p[x] with degree f (i.e., polynomials
g \in F_p[x] such that x generates the multiplicative subgroup of
F_p[x]/g F_p[x]).
> Is it always that case that if I chose an irreducible polynomial of
> degree N that I'll generate GF(2^N)?
Yes.
> It looks like everything is abelian and the usual distribution of
> operators I'm used to applies - a(b+c)=ab+ac; a^(b+c)=a^b.a^c.
This is part of the definition of a field.
> Finally, can anyone verify my maths:
>
> A) '0...010' ^ (2^N-1) == '0...001', and by extension 'abc...xyz' ^
> (2^N-1) == '000...001'
This is Fermat's theorem. Choose x \in F_q^*. We claim x^{q-1} = 1.
Proof. Consider \prod_{a\in F_q^*} a x. There are clearly q - 1 =
|F_q^*| factors in this product. Suppose two factors a x and b x are
equal: then a = b (because x^{-1} exists). Therefore the product
contains q - 1 distinct terms, and so must be a product of the q - 1
elements of F_q^*. Hence \prod_{a\in F_q^*} a x = \prod_{a\in F_q^*} a.
Multiplying both sides by the inverse of \prod_{a\in F_q^*} yields
x^{q-1} = 1 as claimed.
> B) '...abc'^-1 == '...abc'^(2^N-2),
Follows trivially from A.
> and this yields the quickest method of calculating inverses.
I'd use Euclid's algorithm, to be honest.
> C) '...abc'^2 == '...0a0b0c'
Yes. In F_{p^f}, the map x |-> x^p is linear. Hence (x + y)^p = x^p +
y^p. The above follows immediately.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Bizzare Cryptanalysis
Date: 18 Jun 2001 16:58:24 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> That's true in Analysis. But it's perfectly possible to define
> derivatives symbolically (for polynomials, say), and to derive a
> perfectly consistent theory without any recourse to limits. And it is
> done.
And indeed it's useful. For example, the multiplicity of a root of a
polynomial is related to the behaviour of the derivative at that root.
Messing about with analysis won't work when you're doing abstract
algebra, so we just define the derivative appropriately.
-- [mdw]
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: Help on GF(2^N)
Date: Mon, 18 Jun 2001 19:13:15 +0200
> Can anyone give an example demonstrating why /irreducible/ polynomials
> are not /prime/ in GF(p)[x]? (i.e. a C=AB=XY for irreducible A, B, X, Y.
> I understand (but can't instantly prove) that the field is not a unique
> factorisation domain, I'd just like an example to sweaten the idea).
Whenever F is a field, F[X] is a UFD, a PID (principal ideal domain), and a
Euclidean domain. Maybe you mean that there are irreducible polynomials that
are not _primitive_ polynomials? This means that x does not generate the
multiplicative group of nonzero elements in F[X]/g(X), where g is the
polynomial.
> Side question (not that important, just curoisity) - Is there such a
> thing as an 'infinite' GF (no finite N)? (I feel I could construct a
> ring that behaves that way, but whether it's actually a field is another
> matter).
Yes, there are such fields. The algebraic closure of GF(q) is an example.
This field A is the smallest field containing GF(q) such that every
polynomial in A[X] has a zero in A. I believe such fields are quite
complicated (much more complicated than C, the most well-studied
algebraically closed field).
> When trying to express elements of GF(2^N) in 'polynomial' form, does it
> make any difference what irreducible polynomial in GF(2)[x] I chose? I
> assume all of the choices yield isomorphic fields? How many such
> polynomials are there? Is it always that case that if I chose an
> irreducible polynomial of degree N that I'll generate GF(2^N)?
All such fields are isomorphic to GF(2^N); the choice of irreducible
polynomial does not matter. I think the number of primitive polynomials is
something like \phi(2^N-1)/N, where \phi is the Euler totient function
(\phi(a) = the number of elements between 1 and a-1 that are relatively
prime to a). I think the formula for the number of irreducible polynomials
is a little bit more complicated.
Jakob
------------------------------
From: [EMAIL PROTECTED] (George Anescu)
Subject: XOR256 encryption/decryption method
Date: 18 Jun 2001 10:19:14 -0700
Hi,
Recently I played with some encryption ideas and the results with
source code
are presented in two articles with codeproject.com:
http://www.codeproject.com/useritems/filecrypt.asp
http://www.codeproject.com/useritems/xor256.asp
I have an encryption/decryption method I called XOR256 which can be
applied in the both stream ciphering and block ciphering cases. In
each case I present two variants.
For the block ciphering case the first variant is faster than the
second because is using a smaller number of method constants computed
during the initialization phase.
I am interested to know your opinion about the security of my method
and possible decryption attacks. All the details of the method are
presented in the articles and I am willing to provide any other
information is requested for serious analysis.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: quadratic functions
Date: Mon, 18 Jun 2001 17:21:41 GMT
"Klaus Pommerening" <[EMAIL PROTECTED]> wrote in message
news:9gkodn$ivu$[EMAIL PROTECTED]...
> In <q9TW6.137107$[EMAIL PROTECTED]> "Tom St Denis"
> wrote:
> > F(x) = x^tAx
> > ...
> > Are "quadratic" sboxes ones where each row has a hamming weight of two?
> >
> No. Take a math book and look for "quadratic forms".
> And for "degree of a polynomial".
Yea I figured it out, it will be a sumation of quadratics.
New question: If you recurse won't it augment the degree?
Tom
[NB, It's not useful to say "read this book". I mean seriously I can't
spend my entire life reading book after book. Either answer my questions I
asked [you don't have to go into too much detail] or don't answer at all.]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: BigNum Question
Date: Mon, 18 Jun 2001 17:22:50 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Harris Georgiou <[EMAIL PROTECTED]> wrote:
> :> : Ο Tim Tyler <[EMAIL PROTECTED]> έγραψε στο μήνυμα συζήτησης:
>
> :> :> If there's a problem with Java's cryptography stuff, it seems to be
> :> :> that these classes are immutable, so there's no way of deleting
> :> :> objects - you can only null them, and wait for the garbage
> :> :> collector to clean up afterwards.
> :>
> :> : Not true [...] there are always functions to actually delete any
> :> : object on call. Try Runtime.gc() and destroy() and delete() methods
> :> : in various objects.
> :>
> :> Those don't "eliminate" anything - they just attempt to free up the
memory
> :> that was allocated. This is a *very* different operation to the
> :> repeatedly overwriting with random bitstrings that is often
> :> used in cryptographic applications.
>
> : In memory "repeated overwrites" are not typically required. Once the
bit is
> : changed it's gone!
>
> : And I do believe that the designers of the crypto portions did think of
> : this.
>
> Not in the classes in question. You can check for yourself.
>
> There is no API for wiping them out. There are no destroy() or delete()
> methods in the class, or in any of its parents - and they are immutable -
> so you can't access their contents.
int test[] = new int[32];
int x;
for (x = 0; x < 32; x++) test[x] = 0;
What am I missing?
Perhaps their destructors do such things?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: XOR256 encryption/decryption method
Date: Mon, 18 Jun 2001 17:27:31 GMT
"George Anescu" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> Recently I played with some encryption ideas and the results with
> source code
> are presented in two articles with codeproject.com:
>
> http://www.codeproject.com/useritems/filecrypt.asp
> http://www.codeproject.com/useritems/xor256.asp
I briefly looked at your stuff.
Suggestions for presenting code:
1. Present it as a simple C source code that demonstrates a) how it works
and b) that it does work. Huge classes with 1000s of function calls are not
good. for instance, see my TC ciphers. They are all trivial to read
[except the few that GNU Indent murdered] and generally well laid out.
2. Present speed, size charts.
Suggestions for presenting a cipher in general
1. What does it solve?
2. Is it better than any currently known solutions?
3. Is it original or demonstrate a new design technique?
4. How secure is it in a theoretical model against all attacks it was
designed to prevent?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Mon, 18 Jun 2001 17:28:00 GMT
"John Myre" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> <snip>
> > If you look at what these YAPL (Yet Another Programming Language)
provide,
> > typically more often than not it's a self-righteous need to feel proud
of
> > re-inventing the wheel.
> <snip>
>
> Pot calling the kettle black, I'd say.
Hmm? sorry i haven't heard that before.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: SHA2 PRNG.
Date: Mon, 18 Jun 2001 17:35:13 GMT
"Cristiano" <[EMAIL PROTECTED]> wrote in message
news:9gknsa$rr0$[EMAIL PROTECTED]...
> "Tom St Denis" wrote:
> > "Cristiano" <[EMAIL PROTECTED]> wrote in message
> > news:9gj15m$fan$[EMAIL PROTECTED]...
> > > "Tom St Denis" <[EMAIL PROTECTED]> ha scritto:
> > > >
> > > > "Cristiano" <[EMAIL PROTECTED]> wrote in message
> > > > news:9gimtg$d4d$[EMAIL PROTECTED]...
> > > Now I changed the generator in this way:
> > > 1) I fill a 256 bits vector with 8 pseudorandom 32 bits numbers;
> >
> > Careful here. You should typically bring in more bits then you put out.
> > This is because you want to make sure the amount of entropy comming in
is
> > sufficient. Let's say you bring in 256 bits from say the mouse
> co-ordinates
> > [the lsbs]. But there is a huge skew of say p=0.95 for 1 in the lsb,
this
> > means your 256 bits has only -256 * log2(0.95) = 19 bits of real
entropy.
> > You would need 3460 bits to get your 256 bits of entropy.
>
> Is there any empirical method that allows me to calculate how much do bits
> need?
Typically with bits you can do say an 10-th order adaptive predictor. I.e
given the past 10 bits, what is more likely to come?
If your data is truly random it will be 0.5/0.5 either way. So you train
the model on your data [you will need a lot of data, say 50,000 bits at
least] then for each new bit you add the entropy. If for example you have
0000011111 0, given the ten bits 0000011111 you look up in the model which
is more likely to occur 0 or 1. Let's say P(1) = 0.95, then we know that
only -log2(0.95)=0.07 bits were added to the output.
Of course this is just one way. You could do a plethora of other tests.
Typically if your data fails this test though it's fairly bad source of
entropy.
> > > 2) I hash the vector and I store the result in the same vector;
> >
> > I don't get this part. Use some pseudocode like
> >
> > H[i+1] = HASH(H[i])
>
> This is what I do in pseudocode (RND[i] is a 256 bits vector):
> H[i] = HASH(RND[i])
> H[i+1] = HASH(RND[i+1])
Well of course this would work. But it is not as efficient as say
H[i] = HASH(RND || i)
where || is concatenation.
This is strong in both directions since knowledge of H[i] does not give away
RND. Again I must stress that you re-seed this whenever you make a long
term secret like a public key or symmetric key. Making a 1024-bit RSA key
will require about 363408.74 bits of entropy [given the prime number theorem
holds]. Thus from a short seed with 256 bits of entropy you can make this
longer one. Recall that all 364000 bits must be "good" bits.
> > > 3) I get the 8 numbers;
> > > 4) go to step 1.
> > >
> > > It pass all tests. Is there some weakness now? Is there a better way?
> >
> > Yes it may appear random but keep in mind so do LFSRs.
> >
> > How is your "modification" any better?
>
> The MT19937() is a very good generator. In this way I hash each time 256
> bits with good statistical property and I hope that the hash result is
also
> good (this is what NIST test show to me).
Passing NIST is not hard. Passing NIST and remaining secure is.
Tom
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Help with error correction (63,48) code
Date: Mon, 18 Jun 2001 12:38:59 -0500
Alexander Popov wrote:
>
> Dear forum,
> I need your help!
> I am trying to implement an error correction code over an air
> link. The format of the messages is known as MPT1327. The code is
> (63,48) with the generating polinomial being:
> X15 + X14 + X13 + X11 + X4 + X2 + X0
> The last (64th) bit is used for total parity check.
> The source code for coding and for calculating the syndwome at
> decoding is written. What I need is some information (algorithm,
> sources, links) about how to correct the bits when I have the
> syndrome. I've heard some things about using Berlekemp's algorithm,
> but I don't know what it is all about...
> The problem is that I must implement this thing in a
> microcontroller with only 8K available for code and 512 bytes of data
> memory!
>
> Thank you for any help in advance!
>
> P.S. The algorithms used for coding and calculating the syndrome are
> as follows:
>
> CODING
> The first 15 check bits are derived from a (63,48) cyclic code by
> using codeword bits 1 to 48 as the coefficients X62 to X15 (in that
> order) of a 63 bit polynomial, which is then divided modulo-2 by the
> generating polynomial;
> On completion of the division, the 15 coefficients X14 to X0 of the
> remainder are used as the first 15 check bits (codeword bits 49 to
> 63), with the X0 coefficient (bit 63 of the complete codeword)
> inverted.
> Finally, bit 64 of the codeword is added to provide an even parity
> check of the whole 64-bit codeword.
>
> DECODING
> The parity of the received 64-bit codeword is checked, then bit 63 of
> the codeword is inverted. The first 63 bits of the resulting codeword
> are then used as the coefficients X77 to X15 of a 77 bit polynomial,
> which is then divided modulo-2 by the ?generating polynomial?. If the
> remainder is zero, and the parity check is met, then no errors have
> been detected.
> The 15-bit remainder of this division is used as the least significant
> 15 bits of the 16-bit ?Syndrome? word, while the msb of the Syndrome
> word is set to ?1? if the parity of the received codeword is
> incorrect.
There are several standard books on coding theory that can help with
this. For a quick pointer ask the people on comp.dsp, they do this
for a living. There are several types of error correction codes which
all use similar math. I've only seen "syndrome" used with Reed-Solomon
codes, which tend to be a bit more complicated than BCH. But they
tell you more about where the errors are. I'm sure the other coding
schemes use similar terms, but go ask the experts.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Bizzare Cryptanalysis
Date: Mon, 18 Jun 2001 18:39:47 +0100
"Robert J. Kolker" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Simon Johnson wrote:
>
> > Lets assume for a second that we can define a process by which we can
> > differentiate an algorithm. Now, since all algorithms we use are
> > deterministic and have a period of some description this would seem to
imply
> > that there would also be a period to the differentiation series. Thus,
we
> > can define a Maclaurin expansion for the algorithm..
>
> Hello? What are you really saying. Infinite series expansions only
> have meaning with regard to compact metric spaces, not descrete
> systems. Formal series expansions generally ignore matters of
> convergence and are a neat way of doing recursion.
>
> Bob Kolker
>
Its not the same expansion.. but you can get expansions that give discrete
values.. Besides, there is nothing i know of that says it can't be done.. we
just have to get past the idea that "this area of maths is used for that"
and realise that maybe some areas may be extremely useful to
cryptanalysis...
With that particular expansion.. as long as the differentation chain is
cyclic i'd propose it doesn't actually matter since the (meaningful)
solutions would be at discrete values anyway.
Simon.
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Counter mode, the better way to do it?
Date: Mon, 18 Jun 2001 18:46:01 +0100
Two approaches I've seen to doing CNT mode for Rijndael:
- use the raw count, say a 32 bit unsigned int in one quad of bytes and
the 12 remaining bytes as 0x00. But feeding that much known plaintext into
a cipher function on every single block looks scary to me.
- feed the count through a scrambling function first, such as MD5.
Which is safer and better?
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Counter mode, the better way to do it?
Date: Mon, 18 Jun 2001 17:48:29 GMT
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Two approaches I've seen to doing CNT mode for Rijndael:
>
> - use the raw count, say a 32 bit unsigned int in one quad of bytes and
> the 12 remaining bytes as 0x00. But feeding that much known plaintext into
> a cipher function on every single block looks scary to me.
>
> - feed the count through a scrambling function first, such as MD5.
>
> Which is safer and better?
In a good cipher.....neither.
> I like e-gold. Digital currency based 100% in real physical gold.
> This link ( http://www.e-gold.com/e-gold.asp?cid=) takes you to
> their site and shows me as the introducer if you open an account.
And don't spam the group.
Tom
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Bizzare Cryptanalysis
Date: Mon, 18 Jun 2001 18:55:07 +0100
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > "Robert J. Kolker" <[EMAIL PROTECTED]> wrote :
> > > Fat Phil wrote:
> > > > Simon Johnson wrote:
> > > > > Lets assume for a second that we can define a process by which
> > > > > we can differentiate an algorithm. Now, since all algorithms
> > > > > we use are deterministic and have a period of some description
> > > > > this would seem to imply that there would also be a period to
> > > > > the differentiation series. Thus, we can define a Maclaurin
> > > > > expansion for the algorithm..
> > > > > I'm pretty sure extraction of a key could be performed from
> > > > > this expansion and would be a nice way to attack algebraic
> > > > > ciphers.
> > > > The problem with this is that 'differentiation' is an operator
> > > > which can only sensibly be applied to continuous functions. The
> > > > functions used in all the crypto I can think of are discrete.
> > > However the algebraic definition of differentiating could be
> > > given without regard for limits. Example: The derivative
> > > of x^n can be * defined* to be n*x^(n-1) with no thought
> > > to defining limits.
> > Yes but the proof comes from first principles. Which are based on
> > limits.
> > Therefore if first principles do not hold [and they don't] then the
> > limit is not defined and therefore the derivative isn't defined.
>
> Wrong (except for Kolker).
> It isn't the "algorithm" that should be considered, but rather the
> function implemented by the algorithm. For encipherment systems,
> this is normally a Boolean vector-valued function of several Boolean
> variables. Such functions can indeed be differentiated, merely by
> first embedding the Boolean algebra into the real-number field.
> This turns out to be quite useful, actually.
I thought this might be possible...
What i was thinking was you'd create an expansion that operates over the
reals but only when integers are passed to the expansion does the expansion
make sense..
Although the type of expansion is different, the one for computing a square
root of a real number is kind of similar to what i mean. Stick 9,16,25,36
etc.. into the expansion and you get integer solutions.
If i'm not mistaken ( that's a big assumption :) ) this expansion is also
based on calculus so my technique could work...
Simon.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
