Cryptography-Digest Digest #296, Volume #9 Mon, 29 Mar 99 08:13:03 EST
Contents:
Re: Decorrelated Fast Cipher (plus other block ciphers) (Terje Mathisen)
Re: Live from the Second AES Conference (Eric Smith)
Re: client authentication (denis bider)
Re: Extending a hash? (Casey Sybrandy)
Methods of exchanging Secret Keys ... ("John")
Re: What did Gilbert Vernam look like? (David Hamer)
Re: AES Cndidate - Alpha (Christopher Jobmann)
Re: client authentication (Vin McLellan)
Re: Live from the Second AES Conference (Fabrice Noilhan)
Is initial permutation in DES necessary? ([EMAIL PROTECTED])
My factorising algorithm (Martin Sykes)
Re: GOOD PRIME GENERATOR (GPG) ([EMAIL PROTECTED])
Re: Live from the Second AES Conference ("Lassi Hippeläinen")
Re: Is initial permutation in DES necessary? (Christoph Haenle)
Re: Is initial permutation in DES necessary? (Richard Outerbridge)
Re: How do I determine if an encryption algorithm is good enough? ("hapticz")
----------------------------------------------------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Decorrelated Fast Cipher (plus other block ciphers)
Date: Sun, 28 Mar 1999 22:05:34 +0200
Daniele Finocchiaro wrote:
> - it is designed mainly for 64bit platforms, where its performance is very good.
> However, it fits also in smaller processors and smart cards (but it becomes
> quite slow in comparison to other algorithms).
Actually, DFC has just one really speed-critical operation, a 64x64->128
(bits) multiplication. If you have an Alpha or some other cpu which
supports this operation directly, then DFC is very fast, but a 32-bit
cpu like a PII can also be quite efficient, even though it has to use
four 32x32->64 multiplications to synthesize the big mul.
The asm code we wrote for DFC improved it from being one of the slowest
AES candidate algorithms (on a PentiumPro) to one of the 3-4 fastest.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: Re: Live from the Second AES Conference
Date: 28 Mar 1999 13:20:44 -0800
[EMAIL PROTECTED] (Terry Ritter) writes:
> The 6805 was specifically intended to be the smallest (lowest cost)
> 6800-like processor that we wanted to build.
Presumably this was only true before it was decided to design the 6804?
------------------------------
From: [EMAIL PROTECTED] (denis bider)
Subject: Re: client authentication
Date: Mon, 29 Mar 1999 00:16:49 +0200
In article <7dl35n$ifh$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> : 1. The client sends the server its name, C, and its certificate, A<<C>>:
> : 2. The server checks the validity of the client's certificate, then
> : 3. The client generates some random data, rC. The client then computes a
> : 4. The server computes the hash of rS and rC, decrypts the hash it
> Oh, why not use the optional client authentication in SSL?
I'd love to, but Uncle Sam says no-no.
I intend to use Microsoft's SSL because it's better documented and much
simpler to use than, say, SSLeay. However, we can only get an export
license for 1024-bit RSA keys for the server, but not for the (many and
uncontrolled) clients. Therefore I have to do the client authentication
part myself, at least if I use Microsoft's SSL.
> I'd suggest the server should encrypt a symmetric key using the
> client's public key, and require the client to MAC subsequent
> messages with that key. The problem with the current protocol
> is that the challenge/response is only bound to the meaningful
> messages by the fact that they go over the same channel.
So if I get you right then what you're saying is that the individual
messages aren't coupled together well enough?
Hm... but there are only three messages exchanged:
Cli-->Srv: C, A<<C>>
<-- rS
--> rC, Cs[h(rS, rC)]
I don't see how any of these messages could later be maliciously reused.
How would coupling the messages with MACs improve the security of the
protocol?
denis
------------------------------
From: Casey Sybrandy <[EMAIL PROTECTED]>
Subject: Re: Extending a hash?
Date: Sun, 28 Mar 1999 21:00:24 -0500
One other thing, how does one test the security of a hash function?
Casey Sybrandy wrote:
> There is a GOST hash function that generates a 256 bit hash. It uses the
> GOST encryption algorithm. I don't know where to get any details on it. If
> you happen to find some literature on this algorithm, I'd like to see it
> too.
>
> Casey
>
> Peter Gunn wrote:
>
> > Hi there,
> >
> > Im looking for a good 256bit hash algorithm for passphrase hashing
> > for input to an encryption routine, and although Ive done a fair amount
> > of searching the only algorithm which seems to cover 256bits is HAVAL.
> >
> > Now, Ive heard tell of 'extending' hash algorithms like doubling up
> > RIPEMD128, or the 240bit 'double barrelled' SHA-1 approach taken
> > by the Pegwit program, but Im guessing these offer nowehere near as
> > good an output as a true 256bit hash??
> >
> > So, two questions for the crypto gurus (and anyone else :-)...
> >
> > 1) What 256bit hash algoriths are there out there?? (esp. those suitable
> >
> > for passphase hashing.. and that can be implemented reasonably fast
> > (both time & code :-))
> >
> > 2) Are there any general purpose algorithms for 'extending' a hash
> > function that can be used with predictable results??
> >
> > Ive got Schneider's doc on low entropy keys and key stretching... what
> > else can I read??
> >
> > ttfn
> >
> > PG.
------------------------------
From: "John" <[EMAIL PROTECTED]>
Subject: Methods of exchanging Secret Keys ...
Date: Mon, 29 Mar 1999 15:41:20 +1200
Hi
Besides the obvious method in exchanging secret keys i.e. A tells B password
or Public Key methodology for secret key exchange, are there any other ways
that secret keys can be exchanged.
Thanks in advance.
John
------------------------------
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: What did Gilbert Vernam look like?
Date: Sun, 28 Mar 1999 10:26:15 -0500
Reply-To: [EMAIL PROTECTED]
Couldn't find Vernam...but there's a photograph of Mauborgne
in: Cryptologia, Vol.XII(2), April 1988, P84.
DHH
monterey wrote:
>
> I am trying to find an image file of Gilbert Vernam and/or Joseph
> Mauborgne without any success. Has anyone ever run across a picture of
> Vernam? If so could you refer me to the book/website?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Hamer The Crypto Simulations Group
[EMAIL PROTECTED] or [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Christopher Jobmann <[EMAIL PROTECTED]>
Subject: Re: AES Cndidate - Alpha
Date: Tue, 23 Mar 1999 10:40:55 +0100
Wojciech Laskowski wrote:
>
> Can you give me any information, where can I get K. Almquist's paper
> "AES Candidate Performance on the Alpha 21164 Processor"?
> Thanks,
> Wojciech Laskowski
Yes, at http://home.cyber.ee/helger/aes/kenneth.txt !
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: client authentication
Date: Mon, 29 Mar 1999 01:17:14 -0400
Bryan G. Olson <[EMAIL PROTECTED]> graciously suggested the obvious to
Denis Bider <denis(at)zaslon.si>:
> > Oh, why not use the optional client authentication in SSL?
Mr. Bider replied:
> I'd love to, but Uncle Sam says no-no.
>
> I intend to use Microsoft's SSL because it's better documented and much
> simpler to use than, say, SSLeay. However, we can only get an export
> license for 1024-bit RSA keys for the server, but not for the (many and
> uncontrolled) clients. Therefore I have to do the client authentication
> part myself, at least if I use Microsoft's SSL.
Others with this problem (including a large number of US-based
firms), are buying BSAFE SSL-C from RSA-Australia. See:
http://www.aus.rsa.com/
BSAFE SSL-C has un-American strong crypto in SSL/TLS-savvy code
written in Australia by Eric Young, the author of SSLeay.
Eric <[EMAIL PROTECTED]> is now Chief Technical Officer for RSA-AU.
BSAFE SSL-C offers the fulsome documentation that is typical of RSA
commercial products. SSLeay documentation is/was admittedly sparse.
The Brisbane-based RSA-AU Lab also offers tech support for its code,
where direct support from RSA-US may be forbidden by the US export
censors.
Suerte,
_Vin
PS. Obligatory fair warning: I'm a consultant to SDTI, RSA's parent
firm.
------------------------------
From: [EMAIL PROTECTED] (Fabrice Noilhan)
Subject: Re: Live from the Second AES Conference
Date: 29 Mar 1999 09:27:05 GMT
According to Bruce Schneier <[EMAIL PROTECTED]>:
> DFC, for example, is very slow on 32-bit CPUs and very fast on the
> 64-bit Dec Alpha, and much less fast on the 64-bit Merced and McKinley
> (the next-generation Intel chips).
DFC has been optimized on 32-bit CPUs; C code is still slow, for sure
but asm code is fast. Not as fast as Twofish, of course! ;-) The problem
is that the 64 bit design requires some work to become fast on 32 bit
CPUs.
On the Intel Pentium Pro, for instance, encryption of a 128 bits block
takes 393 cycles. To compare that to the best known implementations of
Pentium Pro:
RC6 232
Twofish 258
Rijndael 283
Mars 320
Crypton 345
DFC 393
E2 415
Most of the timings of AES2 were done using NIST API (which is quite
slow but strict ANSI for DFC). I think that timings of inner code using
asm (as you have done) are more relevant.
Fabrice
------------------------------
From: [EMAIL PROTECTED]
Subject: Is initial permutation in DES necessary?
Date: Mon, 29 Mar 1999 06:42:23 GMT
Hello cryptographers,
It seems to me that initial permutation in DES is unnecessary since everyone
knows exactly what the permutation is. Does anybody know the reason why DES
specify a known permutation? Is the initial permutation there to permute a
certain bit pattern that can cause DES to reveal the key?
Thanks a lot,
-galaknight.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Martin Sykes)
Subject: My factorising algorithm
Date: Mon, 29 Mar 1999 08:23:05 GMT
Hmm, looks like my algorithm isn't as fast as others for finding
factors. I've got a load of numbers to test with now but does anyone
have numbers which have been factorised with the quickest
factorisation times for them so that I know what I need to aim for?
Is my algorithm any good for proving that numbers are prime? If my
algorithm says the number is prime, it has proven it to be so by
exhausting the search space.
Also, can anyone recommend a good sirte which explains what the basic
problems people are trying to crack are. Factorising large numbers is
one but I'm guessing there are others.
The other method I though of which I haven't got round to yet is to
sort of reverse engineer the answer. Each bit in the final number has
been contributed to by many bits from the factors. Maybe it's possible
to work out from the position of the bits in the product where *some*
of the bits should be in the factors. This would massively improve my
algorithm.
Comments?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: GOOD PRIME GENERATOR (GPG)
Date: Mon, 29 Mar 1999 07:12:40 GMT
bobs
I have been looking at many of the sources you pointed me to. I have been
exchanging email with other readers of this newsgroup. You are half-right
about one issue, and completely wrong about another. I have already seen
your knowledge and understanding of this topic, and others (from reading your
posts in other newsgroups). It pains me to keep reading from someone at your
level being so way off.
Issue 1) You claim that I discovered nothing. Nothing is a strong word.
I'll grant you that I came up with nothing *mathematically* new, but I did
come up with a new way of doing something old. You don't have to like it.
It doesn't even have to be better in any way. It just has to be
algorithmically *different*, which it is, unless you can point to someone's
work performing the same steps. If you can't produce such past work, and
continue to claim I discovered nothing, you are then just as guilty of that
which you claim cranks are guilty of.
Issue 2) You claim that much of what I came up with did not find primes. You
are plain wrong. My original Sieve, given time, produces all and only prime
numbers, in order. When you claim that it doesn't you must still be
referring to a different method for generating large numbers of
better-than-random likelihood of being prime, which I also posted at that
time. This latter method did not produce all nor only prime numbers. You
yourself once stated something to the effect that my original Sieve was just
a lousy way of performing the Sieve of Eratosthenes. If you made that claim,
you must have thought the Sieve accomplished the same thing. Stop confusing
the two methods. Instead of gaining respect, you lose some every time. If
you need to review the claims you made, to see how inconsistent you've been,
I've compiled them at:
http://mycomm.excite.com/mycomm/browse.asp?cid=.bYUix4qPgMO.
torres
In article <7ddjt5$h82$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7dda0p$8fv$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Note: I posted this at sci.math yesterday. Today I found out that someone
> > named 'torres' has discovered this algorithm before me, last year --
>
> No. Torres discovered nothing. His exposition was gibberish and much of
> what he 'invented' did not find primes at all.
>
> Sieve algorithms are over 2000 years old. They are hardly new.
>
> Why don't people READ THE LITERATURE?
>
> Two minutes with any decent book on primes (e.g. Ribenboim's) would
> let you know that sieve methods are not new.
>
> You method calls for calculating the product of all primes up to some bound.
> This product will be quite large. In fact, it will not be polynomially
> bounded. Sieve algorithms are polynomially bounded. Your method will be
> hopeless slow compared to them.
>
> > actually, I suspect none of us came first then. I didn't know, so I had
named
> > the algorithm independently.
>
> Did you bother to check?
> It seems that people today have forgotten how to use a library. Or a Web
> search engine.
>
> The very first thing one should do before trying to invent a new computer
> algorithm is to SEE WHAT HAS ALREADY BEEN DONE.
>
> > Below my prime generator. Actually it's a prime candidate generator. It
> > generates PHI(G) candidates btw. 0 and G-1 in practically linear time,
> > if G = product of first n primes. There can't be any other candidates in
> > the interval examined.
>
> Note that G ~ e^n and Phi(G) ~ e^(-gamma) * e^n
>
> >
> > Before ditching my algorithm completely, please take the time to try it
> > out. For instance, find all twin primes up to 2310 using only pen and
> > paper. It works quite well; you find 135 candidates in no time, and then
> > you have to check those manually, for instance using a table of primes
> > (yes, you have to cheat).
>
> In other words, your algorithm only tosses out some of the composites
> and then one must test the remaining elements for primality.
>
> This isn't terribly useful. Especially since Pritchard's variation of the
> Sieve of Eratosthenes finds all the primes and nothing but the primes up to
> n (for given n) in sub-linear time (in n).
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Lassi Hippeläinen" <[EMAIL PROTECTED]>
Subject: Re: Live from the Second AES Conference
Date: Mon, 29 Mar 1999 13:32:58 +0300
Bruce Schneier wrote:
> <...>
> While it cannot be proven that a cascade of A B is no more secure than
> A, and could possibly be weaker than A, in realilty that just won't
> happen. <...>
I have a pragmatic proof (i.e. good enough for an engineer):
Assumption: A and B are secure ciphers.
Claim: Chained A & B is at least as safe as A or B alone.
Proof: If not, A is a crack of B or vice versa, which violates the
assumption.
-- Lassi
------------------------------
From: Christoph Haenle <[EMAIL PROTECTED]>
Subject: Re: Is initial permutation in DES necessary?
Date: Mon, 29 Mar 99 12:25:59
[EMAIL PROTECTED] wrote:
: Hello cryptographers,
: It seems to me that initial permutation in DES is unnecessary since everyone
: knows exactly what the permutation is. Does anybody know the reason why DES
: specify a known permutation? Is the initial permutation there to permute a
: certain bit pattern that can cause DES to reveal the key?
: Thanks a lot,
: -galaknight.
: -----------== Posted via Deja News, The Discussion Network ==----------
: http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
The permutation is not done for security reasons. Rather, it is
supposed to make DES implementation slower in software. However, when
using 3DES, it could make a difference (in security) whether EDE or
EEE is used, even when using three different keys (when using EDE, the
permutations between E and D and between D and E won't disappear as
opposed to the EEE scheme). As far as I know, nobody has ever proven
whether of not the permutations strenghens 3DES.
-Chris.
------------------------------
From: [EMAIL PROTECTED] (Richard Outerbridge)
Subject: Re: Is initial permutation in DES necessary?
Date: Mon, 29 Mar 1999 06:54:36 -0500
In article <7dnkfn$[EMAIL PROTECTED]>, Christoph Haenle <[EMAIL PROTECTED]> wrote:
>The permutation is not done for security reasons. Rather, it is
>supposed to make DES implementation slower in software.
Well, it does make things slower in software, but it was probably
only intended to make things faster in hardware. DES is only
true, real DES when implmented in hardware (as opposed to the
ANSI standard DEA - same algorithm, no implementation specified).
>However, when
>using 3DES, it could make a difference (in security) whether EDE or
>EEE is used, even when using three different keys (when using EDE, the
>permutations between E and D and between D and E won't disappear as
>opposed to the EEE scheme).
They can be completely dispensed with. All that changes between
E and D is the key schedule. IP-1((IP(x)) = IP(IP-1(x)) = x.
>As far as I know, nobody has ever proven
>whether of not the permutations strenghens 3DES.
I think, in fact, it can be proved that at most they add nothing.
outer
--
"Just an eccentric soul with a curiosity for the bizarre."
PGPpubkey 1024/0EEAAF21 1994/07/23 <[EMAIL PROTECTED]>
Fingerprint = 6A89 D49F D3DA 12E4 040A 273B F383 0127
------------------------------
From: "hapticz" <[EMAIL PROTECTED]>
Subject: Re: How do I determine if an encryption algorithm is good enough?
Date: Mon, 29 Mar 1999 07:07:15 -0500
have you done any of the basic examinations on it yet?
--
best regards
[EMAIL PROTECTED]
------------------------------
** 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
******************************
