Cryptography-Digest Digest #98, Volume #12 Sat, 24 Jun 00 05:13:00 EDT
Contents:
Re: security problem with Win 2000 Encryption File System (David Blackman)
Tiny hash? (Benjamin Goldberg)
Re: Compression and known plaintext in brute force analysis ("Douglas A. Gwyn")
Re: MD5 Expansion (David Hopwood)
Re: TEA-wmlscript question (David Hopwood)
Re: AES key lengths (Serpent and Twofish) (David Hopwood)
Re: AES key lengths (Rijndael) (David Hopwood)
Re: exponentiation (Yen-Choon Ching)
Re: MD5 Expansion (Simon Johnson)
Re: Tiny hash? (Simon Johnson)
Re: Compression & Encryption in FISHYLAND (SCOTT19U.ZIP_GUY)
E4M (Was: security problem with Win 2000 Encryption File System) (Troed)
Re: Compression & Encryption in FISHYLAND (Simon Johnson)
Re: Questions about RSA............. (Simon Johnson)
Re: Weight of Digital Signatures (Robert Stonehouse)
Algo's with no easy attacks? ("matt")
----------------------------------------------------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: security problem with Win 2000 Encryption File System
Date: Sat, 24 Jun 2000 15:14:47 +1000
Paul Rubin wrote:
>
> S�bastien SAUVAGE <[EMAIL PROTECTED]> wrote:
> >EVERYTHING on a E4M Disk is encrypted: boot sector, FATs, directories,
> >files and empty sectors.
>
> If the boot sector is encrypted, how can you boot?!
>From a Linux rescue CDROM?
Or, more generally, from another disc that has a non-encypted boot
sector and at least enough bootstrap code to understand the encrypted
disc. Maybe even the whole operating system, and the encrypted disc is
only used for data.
Just guessing ...
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Tiny hash?
Date: Sat, 24 Jun 2000 05:20:10 GMT
I'm looking for a keyed hash that produces a small [8-bit] output,
and is very fast/efficient. Anybody know of any?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Compression and known plaintext in brute force analysis
Date: Sat, 24 Jun 2000 05:36:41 GMT
zapzing wrote:
> And another problem: suppose a random (or already encrypted)
> file is encrypted. Then an amount of predictable
> information will be added to a file that was previously
> perfectly unpredicatble.
? That is false in general.
------------------------------
Date: Sat, 24 Jun 2000 00:35:39 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: MD5 Expansion
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> > Simon Johnson wrote:
> > > A much better way is to divide the message in two. Then hash
> > > each part individually and contatenate each hash.
> > >
> > > a = 1/2 of M
> > > b = other 1/2 of M
> > > Hash output = H(a) & H(B)
> >
[snip the obvious attack]
>
> Indeed. Some more complicated mixing needs to be done. Let H be a hash
> function, and let K be a cipher. Let M = (a, b) be a message split into
> two halves (it doesn't really matter how). Compute:
>
> a' = E_{H(b)}(a)
> b' = E_{H(a)}(b)
>
> Then let the extended hash be
>
> H'(M) = H(a', b') || H(b', a')
>
> Any analysis?
Let b = a, then we have
a' = b' = E_{H(a)}(a)
H'(M) = H(a', a') || H(a', a')
Let G(a) = E_{H(a)}(a).
In this case a collision in G leads to a collision in H'.
The difficulty of finding a collision in G depends on the block size of
E; if the block size is n bits and E behaves like a random cipher, then G
will behave like a random function, so we expect to find a collision with
about 2^(n/2) work. Unless n is unusually large, this is probably easier
than breaking H, although the attacker won't have any control over the
form of the colliding messages.
> (Yes, it's much slower than just hashing the data twice.)
That too :-)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVPzvjkCAxeYt5gVAQFf4Qf+MLW8YgGW3W5l8QQMlQVMrQ/pw5s60YtM
0lAiNuv964kGRO3Cj4kCfYHfq2ve461Vj746qA0y2LTLcPuCyto7P+sYaKqzwXZ9
ryk/gOCqmsmrdvCcrYvzpkN+FXSO6ZkjCkQqtuSiDvrUB0lSm3ylnS2MQQb3Wmsb
Lr/3sLFMLaxdS8ee6odTxld45BBU65kh9k6hOM6xR6xJFwnDg2+c6fXgWenddzun
pkoGaBomhV4sxdb8Isy5Njqksy4BGxNJqPQYrPE2rCkr9nWhBMM34Zix+x9sLSj6
fzU+oeEpUFHPRJ5Xk4YovPPG67e9AxHKD/61UUujWKQvoDnXRy/Ncw==
=pWc5
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 24 Jun 2000 04:19:08 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TEA-wmlscript question
=====BEGIN PGP SIGNED MESSAGE=====
dexMilano wrote:
> I've tried to implement TEA in wmlscript but I've found some problem to
> assign the Golden number delta (= 0x9e3779b9).
> In the wmlscript we have (signed) int a 32 bit so the range arrive to
> 7fffffff.
WMLScript specifies twos-complement arithmetic, so you can just use
signed variables as if they were unsigned. (Note that addition,
subtraction, multiplication and xor are the same for signed twos-
complement arithmetic as for unsigned arithmetic, when viewed as
operations on bit patterns. If you can find an implementation of
TEA in Java, it will probably use this technique.)
> The question is: Is there a way to create a golden number minor than
> 7fffffff?
Use 0x9E3779B9 - 0x100000000 = -0x61C88647 (but if you're not familiar
with twos-complement arithmetic, look it up and make sure you understand
why this works).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVQoVzkCAxeYt5gVAQGiOwgAvsTp+lYNE2LSfUchKheXdlWJM2fQu6uP
dazIe4mveJchjjT0g/svrR7CX1YDNL8/ttrQRDj0nk/MZwSiMjDqW75FG5Hvq3hT
nZmmZsODzgt2FGl1FNXfzpYxtADtPQt+Go+L9PZ7PWyKCHHXNPWXDAssvQoGt+Iq
5X49BX0wAEbLhAxvELAQFDDag0Uyoqljh9681VGn7x8Jhb/wN8C43BXHrZ8dVx0N
GDPkXKidaOPI3oM+AP7YZBofdN3c2vbohHoouwmy/jdJ9nXme9Ghedr7M429U//P
W5ZV0TlYqNd9aIcOkYtfON8/7TUXnajUeyU3+zQZ+0mOr+pS/b/dCA==
=kPfU
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 24 Jun 2000 04:34:26 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: AES key lengths (Serpent and Twofish)
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> > Key length (bits)
> > Algorithm Min Max Multiple
> [...]
>
> > Serpent 128 256 64
>
> Serpent keys can be any bit length. The paper is clear about how to
> handle keys shorter than 256 bits: you append a 1 bit and pad with
> zeros until you have 256 bits.
The Serpent spec says:
# The user key length is variable, but for the purposes of this submission
# we fix it at 128, 192 or 256 bits; ...
Granted, it is clear how other key lengths would be defined, at least for:
Serpent 0 256 8
(not for multiples of 1 bit, since the ordering of bits within a byte
isn't given, and there are problems with how you encode such keys).
> > Twofish 8 256 8
>
> Is there some problem I don't know about with zero-length Twofish keys?
> I thought you just padded with zero bytes until you had one of the three
> specified lengths.
That's what the spec says, but it isn't what the C and Java reference
implementations do. For keys of <= 64 bits, the reference implementations
pad to 64 bits, rather than 128 bits (i.e. they use k = 1, in the notation
of the spec). To be consistent with this for zero-length keys would involve
either using k = 0 (which doesn't work), or k = 1, which would make zero-
length keys a special case for which k != ceiling(N/64).
It's always possible that the behaviour of the reference code for key
lengths <= 64 bits is a bug, of course. However, since the C and Java
versions are consistent, I assumed that wasn't the case. The test vectors
don't help because they only cover 128, 192 and 256 bits.
I've cc:d Ross Anderson and Bruce Schneier, so we can get definitive
answers about what key lengths are specified for these algorithms.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVQsAzkCAxeYt5gVAQEz7wgAh+kQfVLw4ApRvb1TUozMIwBiip8IO54J
VDz9jULN/M0YJCFNzuXWMf70Qyz2GldRVtU6mQoOunNCnT6z1rip+e7Ht8iukKe9
ppdkusQuOv391X9cLE7i/RGvLLCJyz4e6LC8xx4SqhSp/kZL4bv7u2DhPENYIEz8
VXozFnUh2j4oS9tvp4BCrPVHAnUX4FfZ89c236eBBT27h4vciJLsXLzvUQk8gpU2
yS5H1U7ns1oYW8hPP1q6W4ohZOTCgiMj7fpv6hhipM135xk3okRsGWPhqXPndCGT
hOu5UQ1tRkdWR8dHbR6hoNidi3206PRk+VzNZK8l4clX9sE7Cgyq7A==
=Rfro
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 24 Jun 2000 04:39:52 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: AES key lengths (Rijndael)
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > It is a valuable information (and I personally consider it a good
> > news) that Rijndael's key can be adjusted at will.
>
> This is an improvement mentioned in the new version of the paper
> submitted in Round 2.
That explains it - I was working from the first round spec.
> It defines the number of rounds Nr as a function of the number of key
> words Nk and the block size (also in words) Nb:
>
> Nr = 6 + max(Nk, Nr)
You mean Nr = 6 + max(Nk, Nb).
> Perhaps Mr Hopwood would like to amend his table of key sizes in the
> light of this information?
Yes, certainly - that makes it min 128, max 256, multiple of 32 bits.
I'll repost the complete table when Serpent and Twofish have been
clarified.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVQW4jkCAxeYt5gVAQFkhgf+L3+76myE5mUfPjigpQLNnNU/1yWM+PPh
UrbWPGn118PmA9NP5zVK1TOycygmJel5SZ2NPwjWqZDFpVf5G81UZbNOTTdEDBV3
qKbaad1ZrRJr7p/fvPhfwgRPgTPh8g8MD6HU6FFI0InY6xms0tmJ+AKUgvm5q001
yMUKvfSpWChXoiKns9G0umSXHIAQH/j9Vnkdr/+vQQdp4VGrjhOvMFERV7xgmVmx
HJglQ5xFUlBl/mjB6QGpzTkwZCAheTMosCv289RRfpujZl9rpF6YJIeN1sGjOY6P
J+egz1hsCsop4WRwUSc4faqowByE9MV54VNEaUr9Owd+SPrgafRmSQ==
=6PC1
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 24 Jun 2000 14:02:33 +0800
From: Yen-Choon Ching <[EMAIL PROTECTED]>
Subject: Re: exponentiation
tomstd wrote:
>
> Yen-Choon Ching <[EMAIL PROTECTED]> wrote:
> >Hi,
> >
> >Can someone tell me how fast can we do an exponentiation on a 8-
> bit
> >smart card for the following parameter:
> >
> >p = 1024 bits, q = 160 bits
> >
> >Does it need a crypto processor?
>
> I assume this is in the field of integers modulo a prime? Then
> I would suggest a math-copro if speed is a requirement otherwise
> a compact multiply-square can get it done in a *resonable*
> amount of time without serious code-bloat.
What's reasonable without a crypto processor? Under 1 second?
------------------------------
Subject: Re: MD5 Expansion
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sat, 24 Jun 2000 00:31:07 -0700
The only quick fix i can think of, is the one that follows,
Request for comment:
1.) a=H(message)
2.) Do a pseudo-random permutation of the message.
3.) b = H(message & a)
4.) Output = a & b
This should cure some of the problems, i hope.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Tiny hash?
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sat, 24 Jun 2000 00:45:44 -0700
None exist because an 8-bit output is useless.....
Using the Birthday attack you need to search just 2^4 = 16
text's to find a collison.
Like i said, useless
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression & Encryption in FISHYLAND
Date: 24 Jun 2000 07:50:16 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Fri, 23 Jun 2000 22:28:10 GMT, "David S. Hansen"
><[EMAIL PROTECTED]> wrote, in part:
>
>>Where on earth did you get the impression that this Scott guy
>>is an "arrogant foolish mean person"? Is June 23rd National
>>Presumptuous Bastards Day or something?
>
>While I don't wish to justify people in being impolite, it should be
>noted that if someone wished to form an opinion of David A. Scott,
>they would have more information than this one post.
>
>Mr. Scott's claim to fame is scott19u, which essentially is a block
>cipher which uses an S-box having 2^19 key-dependent entries. This
>certainly is a valid way to increase security, but in his early
>postings about an earlier version of this cipher, he made what many
>view as exaggerated claims that well-respected block ciphers,
>particularly IDEA as used in PGP, were worthless and insecure.
>
>It is also distinguished by using a method of converting Huffman-coded
>compressed text into a whole number of bytes which, since it offers a
>bijective mapping of input random-bit-length symbol-terminating
>messages to integral-number-of-bytes arbitrary messages, is claimed to
>produce unbiased output bytes. I have disputed that claim; my take on
>the basic ideas involved can be found at
Glad to see yout still alive maybe someday you can learn to understand
what my huffman coding is all about. But I won't hold my breath becasue
it took you years to correct you errors in even understanding how PGP
did it chaining. I don't read tommys crap since he seems incapable of
thinking for himslef.
As far as the other cipher the AES included they could not be used
to run a contest like my scott19u contest because they are not secure
enough. If you call that an exageration so big fucking deal.
And yes Paul Onions did find an attack on Scott16 but that was only
becasie at that time I did not consider choosen plain texts attacks
as valid. I since have changed my views and can see where one could
consider that a measure. I have learned and expanded my views since than.
I see your still stuck in the mad and not learning much of anything.
>
<<SNIP>>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: E4M (Was: security problem with Win 2000 Encryption File System)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 24 Jun 2000 08:00:55 GMT
David Blackman <[EMAIL PROTECTED]> wrote:
>> >EVERYTHING on a E4M Disk is encrypted: boot sector, FATs, directories,
>> >files and empty sectors.
>>
>> If the boot sector is encrypted, how can you boot?!
>
>Or, more generally, from another disc that has a non-encypted boot
>sector and at least enough bootstrap code to understand the encrypted
>disc. Maybe even the whole operating system, and the encrypted disc is
>only used for data.
I've begun using E4M since reading about it here - most excellent
program I must say. Since the author distributes the sourcecode, has
anyone verified the implementation?
(I'm running it with SHA-1 hashes and IDEA encryption)
___/
_/
------------------------------
Subject: Re: Compression & Encryption in FISHYLAND
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sat, 24 Jun 2000 01:00:37 -0700
Then again, you could always put your differences behind you.
Rather than trying to slur each other.
I don't know, maybe i'm wrong.
S. Johnson
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: Questions about RSA.............
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Sat, 24 Jun 2000 01:06:44 -0700
Just a quick point,
VB is pants for RSA, i can never generate a public-private key
pair with a modulo greater than 32-bit.
Out of intrest, does anyone know a way of computing large
numbers in VB.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Robert Stonehouse)
Subject: Re: Weight of Digital Signatures
Date: Sat, 24 Jun 2000 08:33:48 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Robert Stonehouse wrote:
>> [EMAIL PROTECTED] (John Savard) wrote:
>> ...
>> >A law that makes a digital signature "just as binding as one in ink",
>> >when it is so much easier to break into someone's house and read their
>> >hard drive than forge their signature perfectly makes ordinary people
>> >much more vulnerable to forgery than before.
>> ...
>> The thing that makes an ink signature binding is the fact that it
>> was written by the right person. If your bank pays out on a forged
>> cheque, saying 'Well, it was a perfect forgery' won't help the bank
>> at all. The bank has to make it good to you.
>>
>> It is hard to imagine how any law authorising digital signatures can
>> preserve that protection for bank customers and others who sign
>> documents.
>
>But a cheque forgery has to be ascertained by experts who have to
>use judgements and, I believe, don't always have 'absolute' certainty.
>So I guess that some parallel mechanism could function.
Not necessarily. There can be other ways of showing you didn't sign
the document apart from an examination of the document. What matters
is whether you signed it or not.
The terms of electronic transactions mostly say that, if the bank
gets a transaction that satisfies the conditions, it can pay. That
is, the electronic details are final.
[EMAIL PROTECTED]
------------------------------
From: "matt" <[EMAIL PROTECTED]>
Subject: Algo's with no easy attacks?
Date: Sat, 24 Jun 2000 17:04:59 +0800
Hi all.
I've been lurking on this NG for a while, and often mention is made of
various attacks on algorithms such as known plaintext, repeated
messages etc.
I don't have much experience in matters such as this, so are there
any/many algorithms which are freely available, which don't suffer
from any known attacks such as this. Basically, i want something which
I don't have to worry about that the plaintext may be known, or a
repeated pattern of messages is sent, or other problems such as that.
Are IDEA, Twofish, 3DES etc OK in this regard, or are there problems
with these?
Thanks,
Matt Johnston.
------------------------------
** 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
******************************
