Cryptography-Digest Digest #903, Volume #12 Thu, 12 Oct 00 11:13:01 EDT
Contents:
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: The science of secrecy: Simple Substition cipher ("Martin Porter")
Re: Error-correcting code ? (Marc)
Re: Is it trivial for NSA to crack these ciphers? (John Savard)
Re: Is it trivial for NSA to crack these ciphers? (Mok-Kong Shen)
Re: EKE, RSA, and Compression? (Mok-Kong Shen)
Re: What is meant by non-Linear... ("Scott Fluhrer")
Re: What is meant by non-Linear... (Sundial Services)
Re: FTL Computation (ca314159)
Re: Dense feedback polynomials for LFSR (David A Molnar)
Re: Want Free Encryption? (Tim Tyler)
Re: xor algorithm ("Scott Fluhrer")
Re: Rijndael implementations (Tim Tyler)
Re: AES Runner ups (Tim Tyler)
Re: CRC vs. HASH functions (Tim Tyler)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Thu, 12 Oct 2000 11:23:43 +0200
David Hopwood wrote:
>
> Mok-Kong Shen wrote:
> > John Myre wrote:
> > > Mok-Kong Shen wrote:
> > > <snip>
> > > > If I prove a theorem and there is a weakness, say, it depends
> > > > on the existence of a quantity p being prime and someone
> > > > points out that in a degenerate case p can be 1 and hence
> > > > the proof is invalid and I do a little modification such
> > > > that this case can be avoided and a prime p still can be
> > > > chosen, then my purpose of establishing the theorem is
> > > > achieved, isn't it?
> > > <snip>
> > >
> > > Of course not.
> > >
> > > There is no reason to suppose that the weakness pointed out
> > > is the only weakness. Do you also presume, when you fix a
> > > bug in a program, that you have now proven it correct?
> >
> > I was asking in my orignal post for comments for the
> > very purpose of enabling me to know the weakness(es).
> > Now Bryan Olson claimed to have found an attack and
> > subsequently he said that under a certain condition
> > his attack doesn't work. So I modified my scheme to
> > make it immune to his attack.
>
> No you didn't. It's clear that the attack still applies, although
> it is more difficult because the attacker would have to break twice
> as many rounds of the cipher as in the original case. Under
> reasonable assumptions, it would still be easier than breaking the
> cipher in a standard mode such as CBC, though.
>
> The point is that you should be trying to extend the attack
> yourself, not making a minor change and relying on others to
> cryptanalyse it. You won't learn anything that way.
Can I assume that you have the intention to discuss with
me on an attack very similar to that of Bryan Olson?
I should certainly very much appreciate that, since I
learned form the past that your style of argumetation
isn't like that of his and so there is hence a good
foundation from the beginning for discussion (cf. the
last part of my previous post). If yes, please let me
know with one word. I'll then propose to first describe
the problem setting once again as I see it a bit formally
and then we could begin discussions. (The trouble I had
previously with Bryan Olson was partly due to the fact
that quite a lot was in words that were not clear enough
to avoid misunderstanding due to natural ambiguities in
laguages.)
Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Thu, 12 Oct 2000 11:26:57 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > If I prove a theorem and there is a weakness, say, it depends
> > on the existence of a quantity p being prime and someone
> > points out that in a degenerate case p can be 1 and hence
> > the proof is invalid and I do a little modification such
> > that this case can be avoided and a prime p still can be
> > chosen, then my purpose of establishing the theorem is
> > achieved, isn't it?
>
> Only if that was the one and only flaw in the proof. In this
> case your argument for security was nonsense. Both myself
> and David Hopwood explained why the argument was wrong. The
> attack was just one counterexample, and changing the scheme
> in this way accomplishes nothing significant.
David Hopwood has a second post and I have just responded
to that. Maybe I'll able to discuss with him further
quite near to the line of your attack in the next time.
M. K. Shen
------------------------------
From: "Martin Porter" <[EMAIL PROTECTED]>
Subject: Re: The science of secrecy: Simple Substition cipher
Date: Thu, 12 Oct 2000 10:38:44 +0100
"David Hopwood" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> [EMAIL PROTECTED] wrote:
> > I couldn't agree more. The code took me at most 3 minutes to crack
and
> > the answer was way too obvious. After all, how many five letter
> > composers are there with an 'L' in their name?
>
> The other one is Liszt :-)
Well to be honest I did spend some considerable time researching all the
works of Gustav Holst before my brain finally kicked into gear. It made
me laugh when I read the paragraph: "This might seem a rather convoluted
challenge, and it will require some effort, but everything should become
clear as you decipher each stage."
--
Mart
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: Error-correcting code ?
Date: 12 Oct 2000 10:10:42 GMT
>Yes, it's exaggerated.
>Most likely a transpositions of e.g. "O","0", "1","l" would be handled
>first. I would be happy to recover from 1, maybe 2 wrong digits or 1
>missing digit (probably the first or last).
The easiest to understand is this: Put your message (eg
11110000 00110100 01001000 00101101) into a square diagram
11110000
00110100
01001000
00101101
Now calc the parity for each row and each colomn:
11110000 -> 0
00110100 -> 1
01001000 -> 0
00101101 -> 0
||||||||
10100001
Transmit these parity bits with the message.
The receiver creates the same diagram and calculates the
parity bits. Then the calculated parities are compare to
the received parities. When 1 data bit is wrong, the
corresponding 2 parity bits will show up differently
11110000 -> 0
00111100 -> 0---(instead of 1)
01001000 -> 0
00101101 -> 0
||||||||
10101001
^-----------(instead of 0)
The position of the wrong bit is 2, 5.
For a given message size you can minimize the number of
parity bits by carefully selecting the x/y dimensions
of the diagram.
more than 1 bit errors in 1 message can not be corrected.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Thu, 12 Oct 2000 10:14:04 GMT
On 12 Oct 2000 05:56:13 -0000, Anonymous <[EMAIL PROTECTED]> wrote,
in part:
>The Russians don't want the NSA reading their message traffic. What the hell do they
>use?
a) They probably don't let people know. It would give the NSA
something to work on.
b) And if the NSA can't find out, how would we know?
What they certainly _don't_ use for high-level military communications
is GOST.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Thu, 12 Oct 2000 13:13:33 +0200
Anonymous wrote:
>
> I'm not really interested in opinions of the relative strengths/weakness of various
>ciphers.
>
> I'm more interested to know what people think about NSA's ability to break messages
>encrypted with these ciphers.
What people 'think' need to have nothing to do with what
the above ability really 'is'. Wise people never 'demonstrate'
their strength (or depth of knowledge) unless absolutely
necessary. In allday life physical sizes of persons rarely
correspond to their relative 'strength'. Recently a newspaper
photo showed that a young Japanese school boy succeeded to
put Mr. Putin onto the ground with Judo.
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: EKE, RSA, and Compression?
Date: Thu, 12 Oct 2000 13:19:17 +0200
John Savard schrieb:
>
> On Thu, 12 Oct 2000 01:39:46 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote, in part:
>
> >But on the general assumption that the opponent knows
> >the algorithm and hence in particular also this trick,
> >I don't think that we could claim that this really
> >functions.
>
> Certainly it still functions. Because if you have N messages that are
> 200 letters long, there are 200^N possible ways to put them together
> if this trick is used, to try to compare them for cryptanalysis.
I misunderstood you to mean that the whole file (containing
the N messages) were separated into two parts and these
get exchanged. Otherwise, I think taking some appropriate
size of units and do a pseudo-random permutation is much
better, though a bit more computationally costly.
M. K. Shen
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: What is meant by non-Linear...
Date: Thu, 12 Oct 2000 06:00:40 -0700
Rob Marston <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> So to put it in a nutshell, if I had two S-Box's {the first is an Xor
> and the Second is an And} then...
>
> SBox Out Out
> In Xor And
> 00 0 0
> 01 1 0
> 10 1 0
> 11 0 1
>
> I could reverse the Xor S-Box by knowing the output bit and
> either input bit, but I could not reverse the And operation?
>
> Is that it?
No. A function y = f(x) is linear if, as Mr Savard stated, it can be
expressed y = a*x + b [1], for some reasonable definition of * and + [2].
Linear functions are interesting for several reasons, among which:
- If y = f(x) and z = g(y) are both linear (and use the same ring
operations), then z = g(f(x)) is as well. That is, composing linear
functions do not make the result any less linear.
- Given an unknown linear function, it is easy to reconstruct it using
relatively few known plaintext/ciphertext pairs using Gaussian Elimination.
In the case you gave, xor is linear if you take * to mean matrix
multiplication mod 2, and + to mean addition mod 2. Then,
y = (1 1) * x + (0)
there x is the vector of your two input bits. This definition of * and +
is, in fact, the most often used in cryptography.
For the "And" operation, there is no such definition of * and + which works.
[1] To be pedantic, this relationship is refered to as affine -- it's linear
if it can be expressed y = a*x. In cryptography, the distinction usually
isn't important.
[2] The mathematical definition of reasonable here means that * and + must
be ring operations, for example, a*(b+c) = a*b + a*c must be an identity.
--
poncho
------------------------------
Date: Thu, 12 Oct 2000 06:40:28 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What is meant by non-Linear...
This gives an interesting insight to one of my
historically-favorite-for-some-reason ciphers, PKZIP. This is a
stream-cipher composed of linear operations, although it does use a
couple of calls to CRC32 (which can be expressed as XOR and
table-lookup). And one of the things you can count on, where PKZIP has
been used, is that you probably have several dozen entries in the
archive, all of which were enciphered using the same key.
I succeeded in "sometimes breaking" the cipher using the
very-predictable frequency characteristics of a compressed output
(although the fact that it is a bit stream, rather than a byte stream,
clouds the issue when you look only at "bytes"). The fact that "you can
start anywhere, and work forward or backward" was also helpful.
But I wonder if there were other, statistical methods that I simply
don't know enough about.
>Scott Fluhrer wrote:
> A function y = f(x) is linear if, as Mr Savard stated, it can be
> expressed y = a*x + b [1], for some reasonable definition of * and + [2].
> Linear functions are interesting for several reasons, among which:
>
> - If y = f(x) and z = g(y) are both linear (and use the same ring
> operations), then z = g(f(x)) is as well. That is, composing linear
> functions do not make the result any less linear.
>
> - Given an unknown linear function, it is easy to reconstruct it using
> relatively few known plaintext/ciphertext pairs using Gaussian Elimination.
==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R): "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Thu, 12 Oct 2000 13:41:02 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> ca314159 wrote:
> > Definitely. Velocities/speeds are considered relative
> > to _inertial_ reference frames. One cannot do FTL this
> > way. Non-inertial reference frames must be used; to cheat.
>
> Nonsense. Speed is the magnitude of velocity, and
> velocity is the rate of change of the spatial coordinates
> of some well-defined physical "thing" with respect to the
> time coordinate. This is true in noninertial frames as
> well as in inertial frames. The speed of light is the
> (local) conversion factor between the units used for
> spatial vs. time coordinates. Its role as an upper bound
> for propagation of physical effects is no more surprising
> than that the sine of a real number cannot exceed 1.
Special relativistically, the family of curves represented
by a magnetic field can be transformed into an electric
field via point-line duality; except that the points in
this case are charged, and the result is a vector field.
The mathematical notion of a point as representing merely
a position, is replaced by a more dynamic definition of a
point, and this requires some notion of 'Time' and 'Velocity',
which is in mathematics is in the form of differntial calculus.
At the speed of light the magnetic and electric field can
be said to be undifferentiable (their forces balance) and
all that is left is the constant of that differentiation:
which is the speed of light; and its value is unit dependant
as you say.
That's a nice way of looking at the speed limit and shows
an isomorphism between mathematics and physics very nicely.
That is a good interpretation of Special Relativity in physics,
and the mathematics of more extraordinary points
(ones which can no longer be considered as simply coordinate
points in space, they must be dynamic: even if their velocity
is zero, they are still vectors and not scalars.
Physical relativity theory becomes expressable strictly mathematically
as the idea that all such vectors can be expressed as resultants,
and resultants are relative to their coordinate systems)
This interpretation fits nicely into its box for presentation,
just as Newtonian mechanics fits nicely into its box.
But, the more general relativity of non-inertial reference frames
and the use of more general mathematical entities, involves a
recompilation of the above interpretations to include the ideas
of bent space-times. There, the simple differential relation
between the E-M fields in SR is no longer reduceable to simple
statements such as "the speed of light is a physical absolute"
(it never really was a purely physical constant, since it was shown
to exist in an abstract mathematical sense as a unitless constant).
In the flat space of SR it all seems rather easy to say that one
can't poke their head through the plane like a piece of paper and
pop it up somewhere else. Yet some people seem to think otherwise,
like magicians, and NASA:
NASAs breakthrough propulsion:
http://www.grc.nasa.gov/WWW/bpp/
Relativitistic holes in calendar mathematics:
http://www.math.nus.edu.sg/aslaksen/calendar/chinese.shtml
quantum leap years, etc.
Debunking magicians is alot like peaking into the box at
Schrodinger's cat. It spoils the effect. You get to see
the reality. But it spoils the effect. But you get to
see the reality...
"Hello. Farewell. Hello. Farewell."
- Tralfamadore
It's hard these days to imagine an economy which is based
solely on tangible bartering, without some form of credit
based on intangibles: like trust, faith, or probabilistic
wavefunctions.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Date: 12 Oct 2000 13:33:09 GMT
Joaquim Southby <[EMAIL PROTECTED]> wrote:
> Many of the attacks mentioned in this newsgroup are actually quite labor
> intensive, yet they are mentioned as if they are available through
> pull-down menus. I believe that's because the contributors want to err
> on the side of caution should they err at all. Not knowing exactly what
> the questioner is after, they give the safest answer.
yes. it's hard to analyse exactly what the requirements for a cipher are
with reference to a specific context. to use your example: suppose the
race is in 10 minutes, but it's delayed by 2 minutes (jockey late to the
gate, official asleep, whatever).
suddenly your question "what good would an 11-minute crack be?" takes
on new meaning.
I am cautious about algorithms because of problems like this one.
So I will pick the one (or ones) with the fewest known weaknesses,
even if the weaknesses aren't immediately relevant.
> The B-M algorithm requires at least 2n bits of output from an n-bit
> register for the attack. IIRC, that's 2n bits of the *register* output,
> not what has been produced by the XOR of the register output and the
> plaintext. Some assumptions can be made as to the plaintext content and
> the attack can be made based on those assumptions. This, however, will
> take some time and I refer you to the point I made in my first paragraph.
that's a known plaintext attack. stereotyped headers will kill you.
even without that, this seems to me to be exactly the kind of expertise an
organization with time, energy, and an institutional memory could
build. it's also not the kind of thing which attracts much attention in
public academic cryptography. so your adversary could be very very good at
this and you wouldn't know.
-David
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Want Free Encryption?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 12 Oct 2000 13:59:18 GMT
George Peters <[EMAIL PROTECTED]> wrote:
: You can download an entire suite of encryption products with two file
: systems, email/ftp/point to point comunications, source code and a key
: management at www.endecs.com/uenigma.exe . These are really great
: professional products and well worth the download.
I think you still need to be a really big and well-trusted comany before
you can get away with shipping cryptographic products as binary executable
files.
To make things plain, I would not dream of downloading and executing
your ".exe", without at the very least first hearing testimony from other
users I trusted; simply through fear of viruses and trojan horses.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Chaste makes waste.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: xor algorithm
Date: Thu, 12 Oct 2000 06:50:56 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8rv09f$sdn$[EMAIL PROTECTED]...
> In article <wWwE5.11560$[EMAIL PROTECTED]>,
> "Paul Pires" <[EMAIL PROTECTED]> wrote:
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > news:8rtqkq$u4$[EMAIL PROTECTED]...
> > > In article <oqrE5.173$[EMAIL PROTECTED]>,
> > > "Paul Pires" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > William A. McKee <[EMAIL PROTECTED]> wrote in message
> > > > news:[EMAIL PROTECTED]...
> > > > > Antonio Merlo <[EMAIL PROTECTED]> wrote in message
> > > > > news:8rs4sr$mm7$[EMAIL PROTECTED]...
> > > > > > How strong will be an encryption method based on a xor
> operation
> > > with a
> > > > > pass
> > > > > > phrase (or password) an a buffer to encrypt? (suppossed a very
> > > strong
> > > > > > password of, let's say 16 letters, combining uppercase,
> > > lowercases and
> > > > > > digits)
> > > > > > How will you cryptoanalise that algoritm?
> > > > > >
> > > > > >
> > > > >
> > > > > If you use your password to seed a pseudo random number
> generator
> > > (PRNG)
> > > > > like ISAAC, WAKE, etc. and xor the buffer with the PRNG output,
> I
> > > think it
> > > > > can be quite secure. I may be wrong. I'm such a newbie :)
> > > >
> > > > I'm a newbie too but I think you should point out that not all
> PRNG's
> > > > are equal. There are PRNG's and then there are Cryptographically
> > > > secure PRNG's. I am not sure about ISAAC. Regardless, this is a
> > > > stream cipher and has use limitations. A blanket statement that it
> > > > can be "Quite secure" could be misleading.You cannot re-use a
> keyed
> > > stream.
> > > > If the same key is used for two different messages and a
> > > > plaintext is known for one, it is trivial to slove for the other
> > > plaintext.
> > > > There are ways of dealing with this but it's not like falling off
> a
> > > log.
> > > > Stream ciphers and Block ciphers are not two different, but
> > > equivalent,
> > > > methods
> > >
> > > Technically any effective PRNG is cryptographically secure by
> > > definition. But I will agree that some PRNG's are weak
> and "allowed"
> > > to be weak for logistical purposes.
> >
> > Don't mean to argue but.... A PRNG for crypto needs to be irreversible
> > and unpredictable. Just because it makes output that statistically
> checks
> > out doesn't mean that you can't predict future behavior from past
> output
> > or back track and derive the key.
>
> Ah, but in the strictest sense a very good PRNG is unpredictable and
> statistically unbiased (over oo outputs). This means it's
> cryptographically secure.
>
> The problem arises when people say "this is good ..enough.." and use a
> LCG or LFG etc...
>
> > Don't burn me up here. I think I'm amplifying what you said, not
> > necessarily contradicting it.
>
> Hehehehe no prob.
>
> > Agreed. Just don't use the same key over again from the start without
> an IV
> > or salt and don't use it for something that needs tamper
> protection/detection.
>
> Well if you have the ciphertext from RC4 (random key) when I decrypt it
> I can tell if you tampered with it. Stream ciphers are time dependent
> which means the order of the bytes are very crucial.
> Consider "deletion mutations" on DNA before it's read :-)
Errr, no. If you flip a bit in the cipher text, then the corresponding bit
in the plaintext is flipped on decryption. For a simplistic example of such
an attack:
- Suppose I deposit into my account a legitimate check for $2.00 from Bill
Gates. The local bank sends a message to the head office that I deposited
such a check, and the plaintext of the message includes:
... 00 00 00 00 00 00 00 00 00 02 00 00 ...
to indicate that precisely two dollars are being transferred. They RC4
encrypt the message, and so what's actually sent is:
... 58 2A 39 06 41 F9 31 BA 22 94 5C 95 ...
Now, I know (or guess) the format of the plaintext, and so I intercept the
message, and change it to:
... 59 2A 39 06 41 F9 31 BA 22 94 5C 95 ...
Then, when the head office receives my altered message, it'll decrypt it
into:
... 01 00 00 00 00 00 00 00 00 02 00 00 ...
and one billion and two dollars are transfered into my account. I buy a
small country and vanish before anyone notices what happened.
(Yes, I know this attack wouldn't work in real life for several reasons;
banks don't use RC4, Bill Gates doesn't actually keep one billion dollars in
a checking account, etc. This is an illustration...)
You are quite correct in that it's difficult to add/delete material to an
RC4 encrypted ciphertext(however, you can't depend on that, especially if
the message is to a computer program which won't reject obvious nonsense),
however, as I hope I have demonstrated, there are interesting things an
attacker can do without changing the length.
The moral of this story: if you are using an additive stream cipher, and an
active attacker is even a vague possibility, you *really* need to use some
sort of authentication method to detect changes (such as a MAC).
--
poncho
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Reply-To: [EMAIL PROTECTED]
Date: Thu, 12 Oct 2000 14:10:17 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Jim Gillogly wrote:
:> [...] storage is usually measured in bytes.
: In the latter case, they always assume 8-bit bytes, known in the
: networking world as "octets" to avoid ambiguity.
This is what "byte" *should* mean in the first place. Having "byte"
defined as "set of bits that represent a single character" seems like a
really dumb idea to me.
"Byte" should mean "octet" - and the term "octet" should be reassigned to
the terminology scrapheap.
Meanings change. Presumably this is what will happen eventually.
For example, 8-bit types in Java are called "byte"s (and not "octets") -
despite the fact that all characters are 16-bit internally.
--
__________ 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: AES Runner ups
Reply-To: [EMAIL PROTECTED]
Date: Thu, 12 Oct 2000 14:18:59 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Greggy wrote:
:> Let me rephrase - has the government stated any one of the other five
:> finalists would be their backup deployment strategy if a problem was
:> uncovered with Rijndael on some type of official level?
: No, that would be pretty stupid, since if the process
: resulted in a flawed algorithm for #1 choice why would
: one think that the #2 choice would fare any better?
No reason. However all that is required for such a backup to be of
potential utility is for there to be some small finite chance of an
undetected flaw in the selected algorithm.
There would be much the same small undetected chance in the backup
algorithm, of course, but the chances of both algorithms having flaws
would be the square of this probability.
If the idea is stupid, it is probably for other reasons.
Most likely, any such reasons are political:
For example, to do it would be to recognise that the committee process
was fallible, and might have made a mistake. It might also be seen as
casting doubt on the security of the chosen algorithm.
As things stand, in the unlikely event that Rijndael completely collapses
under its newfound attention, presumably there would be an AES retrial,
focussing on the other four final round candidates.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Florist: Petal pusher.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Reply-To: [EMAIL PROTECTED]
Date: Thu, 12 Oct 2000 14:34:11 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
: Mack <[EMAIL PROTECTED]> 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. [...]
: However, if you are willing to use a MAC rather than a HASH (which may be
: appropriate depending on why you are summarizing the file in the first
: place), there are MACs which can be even faster than CRC. Examples of this
: would include UMAC (http://www.cs.ucdavis.edu/~rogaway/umac/) and hash127
: (http://cr.yp.to/hash127.html)
Excuse my ignorance - but isn't a MAC a keyed hash?
How can a MAC be faster than a hash - if you can build a hash out of a MAC
by using it with a fixed key?
I presume you are considering the security requirements for a MAC to be
different from (and less than) those of a hash.
So... where lies the difference?
Why are security properties desirable in a hash not relevant in a MAC?
Isn't it more the other way around?
MACs should conceal the MAC key in use from attackers who can look at any
number of hashed messages. Such security requirements appear to be "in
addition" to those required of a more conventional hash function.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
** 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
******************************
