Cryptography-Digest Digest #663, Volume #9 Sat, 5 Jun 99 09:13:01 EDT
Contents:
Re: Challenge to SCOTT19U.ZIP_GUY (Phillip Dawson)
Re: random numbers in ml ([EMAIL PROTECTED])
Re: CRC32 (D. J. Bernstein)
Re: OTP Problems (Frank Gifford)
Re: Is SSL CPU intensive? (Eric Young)
Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)
Re: Viability of encrypted flash cards? (Matthias Bruestle)
Re: New Computer & Printer for Dave Scott ([EMAIL PROTECTED])
Re: evolving round keys ([EMAIL PROTECTED])
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Paul
Onions)
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Paul
Onions)
Re: PGP probability of choosing primes? (Johnny Bravo)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Paul
Onions)
Re: evolving round keys ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Phillip Dawson)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 5 Jun 1999 01:28:50 -0400
Tim Redburn ([EMAIL PROTECTED]) wrote:
: On Fri, 04 Jun 1999 14:13:40 GMT, [EMAIL PROTECTED]
: (SCOTT19U.ZIP_GUY) wrote:
: > I have been a programmer for over 30 years. I could give a dam what
: >they say about style. Style is just a tem used so that programmers
: >who can' program waste a lot of paper and then management is under
: >the illusion that they porduces something. Style is used to force creative
: >programs in a mold that they don't need.
: Or in other cases, they clearly do need !
: - Tim.
Sorry folks, I just couldn't resist this one:
Scott, just because no one understands you(your code), doesn't mean you're
an artist.
-Phillip Dawson
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm,comp.sys.apple2.programmer
Subject: Re: random numbers in ml
Date: 5 Jun 1999 06:06:55 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
In a previous article, [EMAIL PROTECTED] ("Douglas A. Gwyn") says:
>However, in many cases, reasonable results can be obtained by using
>a wider type (so that the "carry" remains within the accessible
>representation) and suitable bit operations.
Then variables should be established in the first few lines that are 16
bits wide, instead of 8 bits wide? And then shave off the excess bits with
an AND operation? Certainly feasible, but how to go about doing that... ?
>I.e. the algorithm can be coded in C, but it may use methods that
>are different from those that you would use in assembly language.
Okay, and some 'C' implementations might produce very interesting
variations along the same line of reasoning that produced the first
algorithm...
--
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: CRC32
Date: 5 Jun 1999 06:19:05 GMT
> are there any ways to speed crc32 up a bit? or are there any
> faster (yet as "secure") algorithms as crc32?
http://pobox.com/~djb/hash127.html is almost as fast as an optimized
CRC-32, but produces a 127-bit hash, using a 128-bit key.
As explained in http://pobox.com/~djb/papers/hash127.dvi, if you feed
any set of N inputs to hash127, each at most 4L bytes long, then there
are at most N(N-1)(L+2) possible keys that will produce a collision.
---Dan
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: OTP Problems
Date: 4 Jun 1999 12:07:39 -0400
In article <1JG53.580$[EMAIL PROTECTED]>,
TTK Ciar <[EMAIL PROTECTED]> wrote:
> Something just occured to me while reading this thread -- could
>you "stretch" your OTP ...
>
> Clarification: say you have 1,001,024 bits of securely transported
>data (your "pad" -- no longer an OTP in this context) and you're
>using a symmetric 1024-bit block encryption algorithm to transmit
>your secret messages. The proposed method would use bits 0..1023
>to construct the first block, 1..1024 to construct the second,
>2..1025 to construct the third, etc. This would seem to allow you
>to transmit 1,000,000 blocks (1,024,000,000 bits' worth) of data
>before running out of pad data.
The drawback is that if any portion of the key is discovered, then the
blocks on either side of it only require 2 keys to be checked. The bit
stream can be extended on either side very quickly. So the security of
this is only as strong as the security of every block remaining unknown.
-Giff
--
Too busy for a .sig
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: Is SSL CPU intensive?
Date: Sat, 05 Jun 1999 17:51:16 +1000
Paul Rubin wrote:
> Thierry Moreau <[EMAIL PROTECTED]> wrote:
> >Establishing a session requires public key computations on the server,
> >at a bare minimum one full Diffie-Hellman exponentiation each time a new
> >client comes to the server. Your actual requirements might exceed this.
> >Fisrt approximation, a 20MHz 68030 may take in the order of 1 to 20
> >seconds to set up a brand new SSL connection.
> Diffie-Hellman is a relatively new feature of SSL and is only present
> in recent versions. SSL is in practice almost always done with RSA,
> which is faster than DH for the same modulus size. A really careful
> implementation on the 20 MHz 68030 should be able to do 1024 bit RSA
> in maybe one or two CPU seconds. (The bnlib implementation included
> with SSLEAY/OpenSSL is just about as good as can be done). Of course
> if you only have 30% of the cpu available, that increases the number of
> elapsed seconds it takes to get the needed CPU cycles.
The full picture is a bit complicated. Once a connection is
established,
assuming you are going to use
RC4, the limiting factor for 100 byte messages will actually be a
combination
of RC4 and the MAC algorithm. For SSLv3, the MAC will probably be MD5,
for TLS it would probably be HMAC(md5)
For messages around 100 bytes, RC4 and md5 will be about the same speed.
The HMAC construct causes an additional MD5 operation, so again, for
this
size message it is about half the speed of the MD5/RC4 operation.
So the MAC algorithm is the often the limiting factor.
As for the initial generation of the shared secret. If you use
RSA ciphers, with no client authentication (the 'normal' mode),
the cost to the client will be about 1/10 of the server cost.
If you use a Ephemeral DH cipher, the client will take a big CPU hit.
The only number I have currently for an old pentium-100 would let the
client do about 540 512 bit RSA public key operations a second or
158 1024 bit RSA public key operations. This is hand coded ASM, so
for C code on a 68030 20mhz, lets do a worst case /10. That would still
make the client side RSA cost about 1/50 (512) or 1/6 (1024) of a second
which is fine.
If you use ephemeral DH, or try doing the server side of the SSL
protocol,
you could be in trouble :-).
The thing to remember about SSL though is that you can save this 'shared
secret'
and reuse it later. If the client and server application are under you
control,
you can make sure the server accepts the 'reused' shared secret for
weeks if you
so desire.
The other thing that will probably bite you is TCP network delays. For
SSL3,
the sequential connection throughput can actually go down when 'reusing'
the
shared secret (not doing a public key operation) if the TCP protocol is
not
kept happy :-).
eric
--
[EMAIL PROTECTED](H)
[EMAIL PROTECTED](W)
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 5 Jun 1999 08:02:28 GMT
According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
> Only a few think the coding is poor.
No more than 6 billions people, indeed.
--Thomas Pornin
------------------------------
Crossposted-To: alt.security,talk.politics.crypto
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Viability of encrypted flash cards?
Date: Sat, 5 Jun 1999 08:16:07 GMT
Mahlzeit
Cor! ([EMAIL PROTECTED]) wrote:
> Matthias Bruestle wrote in message
> <[EMAIL PROTECTED]>...
> >Journalists, Human-rights groups
> Why would they use it? (You haven't suggested good, practical reasons.)
To prevent images containing incriminating evidence from being used
by the law or the overwhelming force of some military dictatorship
(or similar) which seized it. As even law enforcement agencys of
normal gouvernments want to surveillance journalists and human-rights
groups can get inconvenient for normal gouvernments above point is
not only valid for military dictorshops (or similar).
> Surely if their cameras were seized by some military dictatorship (or
> similar), they would get destroyed. End of story. (?)
> The point about encrypting the camera was to prevent images containing
> incriminating evidence from being *used* by the law or the overwhelming
> force which seized it.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Five inches from happyness.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New Computer & Printer for Dave Scott
Date: Sat, 05 Jun 1999 00:00:15 GMT
I feel touched that I was included.
Tom
> Would anyone in this newsgroup be willing to donate a Pentium-class
300Mhz
> computer and an inkjet printer to David A. Scott? I believe that if
he was
> not hampered by the primitive hardware he works on, he could perhaps
improve
> the legibility of his code. It would certainly inspire him to make
the next
> leap forward, and perhaps produce something that could be analyzed by
the
> likes of Schneier, Ritter, Onions, Redburn, Shen, Olson, Savard, and
even the
> 17 year old Tom St. Denis, etc...
> You know, he could be the next Ron Rivest. Six hundred dollars is
not too
> much to spend on the future of cryptography.
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: evolving round keys
Date: Sat, 05 Jun 1999 00:25:55 GMT
<snip>
Nothing like answering my own question....
David Wagner (he is a cool guy) helped me realized that this would not
hinder a differential or linear attack except to make it harder to
implement.
Here is further question:
What about s-boxes/tables that get swapped like in RC4? The swapping
is not public so the s-boxes are essentially partially new in each
block. The number of elements N in the sbox will limit the effective
key size to log2(N!) bits. This is because larger keys will have the
same table (sbox) and could theoretically be cracked faster. Even if
the entries were 32 bits each, and there were 256 elements the key size
is limited to 1683.996287 bits (not 8192). The swapping could use a
secondary table which has N elements (each one is log2(N) bits). It
could use the second table as in RC4. Another problem is that the
second and sbox (primary) have to be swapped at the same time. Perhaps
only performing a couple updates per block (at a ratio of (1/8)N or
something...)
Enough yacking... Any thoughts?
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Paul Onions <[EMAIL PROTECTED]>
Subject: Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing)
Date: Sat, 05 Jun 1999 12:23:51 +0000
Boris Kazak wrote:
>
> Try this, it reads a file, writes a file...
>
[...]
>
> Any comments would be appreciated.
If I understand your description correctly then your hash
is not collision-resistant.
If I have two files that differ in only the first 4 bytes
such that the XOR of these bytes is the same then they will
both hash to the same value.
e.g. given file A then construct file B to be the same as
file A but with the order of the first two bytes swapped.
BTW I tried to test this with your source but it unfortunately
core dumped with a segmentation fault when I tried to run it.
(I use Linux. FYI it crashed after it asked me for the input
filename but before it produced an output file).
Please correct me if my understanding is wrong.
Paul(o)
--
Paul Onions [EMAIL PROTECTED]
PGP 2.6.3 key available
D704688BEFBF2D5D 546BC1D603E2A8E0
------------------------------
From: Paul Onions <[EMAIL PROTECTED]>
Subject: Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing)
Date: Sat, 05 Jun 1999 12:37:26 +0000
Paul Onions wrote:
>
> If I understand your description correctly then your hash
> is not collision-resistant.
>
> If I have two files that differ in only the first 4 bytes
> such that the XOR of these bytes is the same then they will
> both hash to the same value.
Ooops! That is nonsense, sorry.
I really should learn to sit on my hands for 5 minutes
before hitting that send key!
Paul(o)
--
Paul Onions [EMAIL PROTECTED]
PGP 2.6.3 key available
D704688BEFBF2D5D 546BC1D603E2A8E0
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: PGP probability of choosing primes?
Date: Sat, 05 Jun 1999 08:38:48 GMT
On Thu, 03 Jun 1999 22:46:54 -0400, Geoff Thorpe <[EMAIL PROTECTED]> wrote:
>have "big gaps" in front of them. What I AM a little worried about is
>that primes that have extremely abnormal length blocks of non-primes in
>front of them, exhibit desirable (for the cryptanalyst) properties.
>Nobody has managed (as far as I know) to put a non-trivial upper-bound
>on the size of "gaps" for numbers of "x" bits, so it's possible that
>there's a large number (proportionally) of primes out there with REALLY
>BIG gaps in front of them. This makes them (a) likely to turn up in
>people's keys with a much higher probability than perhaps they should,
>and (b) dangerous if they exhibit special properties - that would imply
>that a large proportion of PGP2.6-generated RSA keys exhibit those
>special properties too.
Rather than trying to "prove" it, wouldn't a demonstration be enough. Use the
Monte Carlo method, just use the key generator and pop out a few million primes
and see if any of them show up a significant fraction of the time. This would
could easily be a distributed project as well, have a thousand PCs generate a
couple of thousand primes each and sort them. You could even use 1/10 of the
distributed computers to compile 1/10 of the lists each, then have one computer
compile the remaining 10 lists.
And if a few million generated keys won't show this bias, we don't really need
to worry about the problem. :)
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sat, 05 Jun 1999 12:54:59 GMT
On 5 Jun 1999 01:28:50 -0400, [EMAIL PROTECTED] (Phillip Dawson) wrote:
>
>Scott, just because no one understands you(your code), doesn't mean you're
>an artist.
>
He could be an impressionist.
- Tim.
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sat, 05 Jun 1999 12:54:59 GMT
On Sat, 05 Jun 1999 02:54:44 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
<snip> <snip> <snip>
=============================================
#define X David
X,
You say you have had 30yrs programming experience. During
that time you *must* have come across programs written in
the style that people are asking you to write scott19u.zip in.
Even if you have personal objections to that style, why wont
you put your objections to one side and keep everybody
happy by writing scott19u.zip in that style.
With 30years experience you *must* know what we mean.
Why wont you just emulate that style for once ?
During your 30yrs programming experience, you must
have come across designs written by other people, that
you are then expected to code. You *must* know the sort
of description that people want of your algorithm.
Why can't you supply such a description for scott19u.zip ?
Is it that deep down, you know that once people actually
know what your algorithm is, they will see it's many weaknesses ?
If not, prove us wrong. Take the challenge. Show people
that you really believe in your algorithm. Describe
you algorithm in a way people understand, and therefore
give them chance to analyse it.
Until you do, the doubters will persitst.
Any handwaving will be ignored.
Can we can safely assume that you have not accepted this simple
challenge ?
- Tim.
(or should that be Z ? long names ey? who needs 'em?)
------------------------------
From: Paul Onions <[EMAIL PROTECTED]>
Subject: Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing)
Date: Sat, 05 Jun 1999 13:14:31 +0000
Paul Onions wrote:
>
> Paul Onions wrote:
> >
> > If I understand your description correctly then your hash
> > is not collision-resistant.
> >
> > If I have two files that differ in only the first 4 bytes
> > such that the XOR of these bytes is the same then they will
> > both hash to the same value.
>
> Ooops! That is nonsense, sorry.
>
> I really should learn to sit on my hands for 5 minutes
> before hitting that send key!
On the other hand, maybe I was on the right track after all...
Given two messages that differ in only their first 4 bytes then
it seems possible that the result of the first multiplication could
be the same in both cases and so will result in the same hash.
Please feel free to point and laugh if I'm talking nonsense again!
(okay, 2 minutes on the hands, that should be enough... :-)
Paul(o)
--
Paul Onions [EMAIL PROTECTED]
PGP 2.6.3 key available
D704688BEFBF2D5D 546BC1D603E2A8E0
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: evolving round keys
Date: Sat, 05 Jun 1999 01:54:40 GMT
> Actually, that is quite beneficial in terms of security.
Not against a differential attack. It only makes it slightly harder to
explain. It would however make ECB modes somewhat more usefull (random
indexing). You can eliminate the arithematic series if you can predict
what the round key could have been. It does make it harder because two
adjacent will not exibit actually similar differential chars (outputs,
not the paterns).
> Why is that? Is that because the cryptographic community obstinately
> ignores a good way to make better ciphers? No, it's because if the
round
> keys change from block to block, you have a stream cipher ... it isn't
> called a block cipher anymore.
It's still a block cipher, the round keys can be forward/reverse
calculated whereas in a stream cipher it operates in one direction only
(this is a requirement, however SEAL for example provides random
indexing in one direction).
Adding a constant can make it slightly more secure, however it depends
on the algorithm. Also the update of the round keys must not commute
with the cipher, this would be very bad.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
