Cryptography-Digest Digest #795, Volume #8 Thu, 24 Dec 98 08:13:03 EST
Contents:
Re: Stego in jpeg files ("R H Braddam")
Re: What is Randomness? (Dr. Yongge Wang)
Re: AES candidate performance on the Alpha 21164 processor (version 1) (Bruce
Schneier)
Re: On living with the 56-bit key length restriction ("Michael A. Greenly")
public-key signing/encryption & rng ("denis bider")
Re: Enhancement of EBC mode? (Kenneth Almquist)
Re: Enhancement of EBC mode? (Terry Ritter)
Re: Enhancement of EBC mode? (Terry Ritter)
Re: Stego in jpeg files (fungus)
Encrypt 98 ("LP")
Guessing leaves on self-similar Huffman trees ([EMAIL PROTECTED])
Thanks (was: RC4 questions (8bit/16bit) and CipherSaber-1) (Anonymous)
Re: biometrics (Withheld)
Re: AES candidate performance on the Alpha 21164 processor (version 1) (Robert
Harley)
Re: md5 sample implementation (Gurripato (x=nospam))
Re: On living with the 56-bit key length restriction (Gurripato (x=nospam))
----------------------------------------------------------------------------
From: "R H Braddam" <[EMAIL PROTECTED]>
Subject: Re: Stego in jpeg files
Date: Wed, 23 Dec 1998 20:55:25 -0600
I found http://pweb.uunet.de/flexsys.mtk/jphd01.zip
instead of
>>http:\\pweb.uunet.de/flexsys.mtk/jphs01.zip
the jphs files were jphs-0.3.tgz and jphs-0.3.tgz.sig.
Try visiting http://pweb.uunet.de/flexsys.mtk for a
list of files.
--
Rick [EMAIL PROTECTED]
R. Knauer wrote in message
<[EMAIL PROTECTED]>...
>On Wed, 23 Dec 1998 00:48:26 +0100, Allan Latham
<[EMAIL PROTECTED]>
>wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>
>>The first public version of a DOS program to hide a
file in a jpeg
>>file using techniques that obscure the hidden file
from statistical
>>analysis is available for anyone who wants to try it.
>>
>>http:\\pweb.uunet.de/flexsys.mtk/jphs01.zip
>>
>>please try and let me have your comments.
>
>Apparently the program istelf is hidden too.
>
>Bob Knauer
>
>"Laws to suppress tend to strengthen what they would
prohibit.
>This is the fine point on which all the legal
professions of
>history have based their job security."
>--Frank Herbert
>
------------------------------
From: [EMAIL PROTECTED] (Dr. Yongge Wang)
Subject: Re: What is Randomness?
Date: 24 Dec 1998 03:33:01 GMT
R. Knauer ([EMAIL PROTECTED]) wrote:
: On 24 Dec 1998 00:52:55 GMT, [EMAIL PROTECTED] (Dr. Yongge Wang) wrote:
: >http://www.cs.uwm.edu/~wang/
: >then go to thesis.
: I already did that, and got this:
: "Randomness and Complexity. 1996. (postscript, 218K)"
: Not PDF.
I am sorry, I have just generted the PDF file and it may
just after you visited it, you are too fast:)
now it should be threre de.
also please note that the thesis is written in a complete
different style of Chaitin's method. But the purpose is
the same and the result should be "equivalent".
: Bob Knauer
: "The police of a state should never be stronger or better armed than the citizenry.
: An armed citizenry, willing to fight, is the foundation of civil freedom."
: --Robert Heinlein
--
======================================================.
Yongge Wang | |
Dept. of EE & CS | |
Univ. of Wisconsin--Milwaukee | |
P.O.Box 784 |Yongge Wang |
Milwaukee, WI 53201 |2545 N.Frederick Ave. |
|Apt. 104 |
Tel: (414)229-5731 |Milwaukee, WI 53211 |
Fax: (414)229-2769 | |
[EMAIL PROTECTED] |Tel: (414)3324794 |
http://www.cs.uwm.edu/~wang |Fax: (414)3324794 |
======================================================'
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: AES candidate performance on the Alpha 21164 processor (version 1)
Date: Thu, 24 Dec 1998 03:35:54 GMT
Very nice work. Congratulations. I hope you write this up as a
formal NIST comment.
In any case, I would like to include some of this information in the
next version of my AES Performance Comparison paper.
Thanks,
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: "Michael A. Greenly" <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Wed, 23 Dec 1998 22:36:50 -0600
> One of the missions of NSA is to do industrial espionage - and other
> agencies may not be different.
>
Unless I've missed something individuals and criminal organizations
will be able to protect there privacy with freeware applications like
PGP. This means that the real target of the Wassenaar agreement must be
industry. If not industry who everyone else gets to use stong crypto?
--
Mike Greenly
------------------------------
From: "denis bider" <[EMAIL PROTECTED]>
Subject: public-key signing/encryption & rng
Date: Wed, 23 Dec 1998 23:06:45 GMT
Hello everybody - a question about RNGs:
I realise that, in public-key cryptography, a strong cryptographic PRNG is
required for key generation in order to create a truly non-predictable
private key. However, as I examined the Crypto++ sources, I found that an
RNG is required for signatures and encryption as well. Now since, in this
case, the RNG is used only for padding, does it matter whether a strong RNG
is used or just, for instance, a linear-congruential one?
Does using a less powerful RNG for padding make the encryption weaker, or
the signing more susceptible to forgery?
The problem is that if I want to use the same RNG for signing and encryption
that I use for key generation, that adds a significant amount of overhead to
the whole application.
--
denis bider ([EMAIL PROTECTED] / [EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: Enhancement of EBC mode?
Date: 23 Dec 1998 23:15:54 GMT
> I'm planning to write an application where encryption of files
> is needed but random access to the content of these files is
> necessary.
>
> !- From chapter nine of the book "Applied Cryptography" by
> Bruce Schneier (1996) I concluded that the only thing I can
> do is to use a block cipher with ECB mode.
If you only want to read the data in a random order, you can use
CBC mode. (To decrypt a block, you have to read the preceding
block as well, which should not be a major problem.) So I assume
you need to write random locations as well as read them.
You seem to be assuming that the only alternative to CBC mode is
ECB mode. To understand the other alternatives, it may be helpful
to review the rationale for CBC mode. The basic weakness of ECB
mode is that a pair of identical plaintext blocks will produce
identical ciphertext blocks. To avoid this, we need to come up
with an encryption function which encrypts each block differently.
Specificly, we want to come up with a block encryption function
C = E'(P, K, BN, IV, Prev)
where
C is the ciphertext block produced by the function.
P is the plaintext block to encrypt.
K is the encrytion key.
BN is the block number of the block to encrypt.
IV is a random value.
Prev is a vector consisting of all plaintext blocks which precede P.
The first two arguments are the arguments standardly passed to a block
encryption algorithm. The next argument is BN. It is used to cause
the encryption function to be different for each block in the file.
The IV argument is needed to prevent block BN of two different files
from being encrypted the same way. From a security point of view, it
does not matter whether E' uses its last argument.
The latter arguments to E' act like additional key data. In fact, the
most conceptually simple way to define E' is to define
E'(P, K, BN, IV, Prev) = E(P, K || BN || IV)
where || is the concatenation operator. The defintion of E' used with
CBC mode is
E'(P, K, BN, IV, Prev) = E(P xor H(BN, IV, Prev), K)
H is a hash function. It is defined as follows:
function H(BN, IV, Prev) is
result := IV
for i := 1 to BN - 1 do
result := result xor Prev[i]
result := E(result, K)
return result
This hash function produces uniformly distributed random numbers if
the block encryption function E is any good. But the real cleverness
in this choice of hash function is the fact that it is equal to the
result of encrypting the previous block. Thus there is no need to
actually compute this hash function.
Once you understand the theory behind CBC mode, coming up with an
alternative which allows random access is straightforward. For example,
you can stick with the hash function approach, but use a hash function
which doesn't depend upon the value of Prev. One such hash function
is E(BN, IV), giving us:
E'(P, K, BN, IV, Prev) = E(P xor E(BN, IV), K)
The coresponding decryption function is
D'(C, K, BN, IV, Prev) = D(C, K) xor E(BN, IV)
Kenneth Almquist
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Enhancement of EBC mode?
Date: Thu, 24 Dec 1998 06:31:54 GMT
On Wed, 23 Dec 1998 16:18:50 +0100, in <[EMAIL PROTECTED]>, in
sci.crypt Marco Stolpe <[EMAIL PROTECTED]> wrote:
>[...]
>Then I would fill up the upper half of the two bytes with
>random bits (under the assumption of course that it IS possible
>to create random bits, perhaps by using special hardware
>events or devices).
>
>This means that the 4 bits of valuable information in one byte
>of plaintext are randomized by the upper 4 bits and that now
>one block of valuable(!) plaintext together with the 4 random
>bits encrypts to many different blocks of ciphertext.
This technique is disclosed in one of the Feistel patents; oddly, we
do not find it in the crypto texts.
I have been describing it on sci.crypt for the past few years as the
"homophonic" block cipher construction. It is "homophonic" in that
each different random value selects a different ciphertext for exactly
the same data field. The "random" field also can be used to validate
the block against possible changes in transit, even if blocks are
delivered out of sequence.
The technique is obviously most efficient when we have large blocks;
Feistel mentions it in the context of 128-bit blocks (Lucifer), but
even that would be expensive. We need enough "random" bits per block
to make a cryptographic difference.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Enhancement of EBC mode?
Date: Thu, 24 Dec 1998 06:32:24 GMT
On 23 Dec 1998 23:15:54 GMT, in <75rtja$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Kenneth Almquist) wrote:
>> I'm planning to write an application where encryption of files
>> is needed but random access to the content of these files is
>> necessary.
>[...]
>The basic weakness of ECB
>mode is that a pair of identical plaintext blocks will produce
>identical ciphertext blocks. To avoid this, we need to come up
>with an encryption function which encrypts each block differently.
>Specificly, we want to come up with a block encryption function
>
> C = E'(P, K, BN, IV, Prev)
>where
> C is the ciphertext block produced by the function.
> P is the plaintext block to encrypt.
> K is the encrytion key.
> BN is the block number of the block to encrypt.
> IV is a random value.
> Prev is a vector consisting of all plaintext blocks which precede P.
Let me point out that it can be a serious mistake to build a system
which uses a file position in encryption. For example, if the file is
any form of database, it could not then be re-organized, nor could new
blocks be "inserted" in the middle. So while this solution may be
fine for reading static files or ciphering absolute storage, that same
approach may be inappropriate in a dynamic database.
One alternative is to store a "block number" value along with each
block so that it travels with the block. But it would be easier to
just save an IV for each block.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Stego in jpeg files
Date: Wed, 23 Dec 1998 23:30:19 -0100
Steve Sampson wrote:
>
> Why are you using two backslashes in the URL?
>
Surely you mean a "forward slash"....
> >> http:\\pweb.uunet.de/flexsys.mtk/jphs01.zip
> >>
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "LP" <[EMAIL PROTECTED]>
Crossposted-To: alt.computer.security,comp.security.misc,de.org.ccc
Subject: Encrypt 98
Date: Wed, 23 Dec 1998 22:02:03 +0100
Hey!
Have someone a statement to this encryption program?
------------------------------
From: [EMAIL PROTECTED]
Subject: Guessing leaves on self-similar Huffman trees
Date: Thu, 24 Dec 1998 07:51:45 GMT
Hello,
A while ago I posted counterexamples to the assertion that in an optimal
key-guessing attack, you will typically come across the key within the
first 2^H guesses, H being the entropy of the key distribution.
The counterexamples arise from self-similar Huffman trees, which
are interesting to look at, if not for their mathematical properties.
I have generated figures and HTML-ized the topic for those who
are curious:
http://www.ima.umn.edu/~pliam/doc/huff
John Pliam
[EMAIL PROTECTED]
http://www.ima.umn.edu/~pliam
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Thanks (was: RC4 questions (8bit/16bit) and CipherSaber-1)
Date: 24 Dec 1998 12:03:44 +0100
Thanks for the thoughtful comments WRT doing RC4 in 16-bit instead of
8-bit. It certainly would make the state table change rate essentially
zero (static) for small messages, and then there's always the original key
size as a weak point.
Also, thanks to Mr Schneier for comments found on his web site that
prompted me to put lots of memset(key,0,256); statements throughout my
CipherSaber-1 program, such that upon termination I don't leave little
bits of the key lying around in memory. I would highly recommend this to
anybody else writing their own CipherSaber-1.
Next I shall try to do something (probably only obfuscation-based) to
thwart what might get left in memory or in the OS swapfile if I press
Alt-Tab while running my CipherSaber. Infinite circles of snakes eating
their own tails, don't you know...
K
------------------------------
From: Withheld <[EMAIL PROTECTED]>
Subject: Re: biometrics
Date: Wed, 23 Dec 1998 23:21:21 +0000
Reply-To: Withheld <[EMAIL PROTECTED]>
In article <75kv35$jhd$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> writes
>Myself <[EMAIL PROTECTED]> wrote:
>> Handy, and the menu system could even track eye movements, instead of
>> requiring keypresses, to make selections. No more busted keys at the
>> ATM (just spraypainted iris-cams). and a messy sneeze would be
>> disastrous. How physically reliable and vandal-resistant are
>> fingerprint readers?
>
>am I the only one who would worry about pranksters putting something nasty
>n the eyepieces ?
>
>On a different note, what prevents me from setting up a fake ATM and
>capturing your biometric data the same way I capture PIN numbers, then
>using it elsewhere? Perhaps it won't be of much use with an ATM's iris
>scanner, but what if I pop the lid off the ATM , cut the wire from the
>scanner, and then hook it to my "handy bank of people" ? or if biometrics
>are widespread, used as passphrases and such, and so I can go look for
>easier targets ?
>
>It is a neat idea, and it's no work to remember, but it sounds
>fundamentally like a very long and complicated passphrase that can't ever
>be changed.
>
>-David
Retinal scanners overcome a lot of the "info grabbing" approach as they
look for a pulse in the retina as well. If the pulse is missing it knows
it is looking at either a fake eye or a corpse.
My main concern is the potential for long term harm, caused by
repeatedly having lasers shone directly into my eyes.
--
Return address removed for anti-spam purposes.
Email replies to news at maelstrom dot demon dot co dot uk
Email replies to this address may be copied to relevant newsgroups
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: AES candidate performance on the Alpha 21164 processor (version 1)
Date: 24 Dec 1998 12:54:36 +0100
There is a comparison by Louis Granboulan, including speed on several
processors, at:
http://www.dmi.ens.fr/~granboul/recherche/AES.html
Rob.
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: md5 sample implementation
Date: Thu, 24 Dec 1998 10:55:15 GMT
On Wed, 23 Dec 1998 06:34:30 -0600, "Steve Sampson"
<[EMAIL PROTECTED]> wrote:
>I notice that in the latest PGP, that MD5 is deprecated.
>In the manual it explains that the MD5 hash was all but
>broken in 1996 by a German cryptographer Hans Dobbertin.
>
>Given that assertion, what is the continuing interest in it?
>
>Steve
>
First, there�s still lots of RSA/MD5 keys being used. The
reasons are several: NAI�s systematically making freeware copies of
their products without RSA support; habit; application to other
anonymity software (Private Idaho, for example), die-hards who still use
DOS, people who want to keep PGP portable (2.6.3 fits inside a floppy),
people who do not trust Windows� unsecure environment....
Second, the expression "all but broken" can be misleading.
True, Dobbertin succesfully attacked MD5�s compression algorithm, but
MD5 as a whole still stands. He proved that MD5 can then be susceptible
to a birthday attack, which means two messages can be found that yield
the same hash value. But it doesn�t mean you can find a message with
the same hash as a given message. That is, maybe "kkeghenndmn" and "ll
jje nnanao982" both hash to the same message, but there�s no way you can
find a message with the same hash as "hello, merry Christmas"
MD5 is partially vulnerable. It is like a faulty floppy: if it
falied now, it can also fail tomorrow. But it doesn�t mean you cannot
use it with some guarantees.
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: On living with the 56-bit key length restriction
Date: Thu, 24 Dec 1998 11:17:58 GMT
=====BEGIN PGP SIGNED MESSAGE=====
>> In the present context we are discussing export of
hardware/software.
>> It is these that are handled by the Wassenaar agreement. The
officials
>> evidently suppose that the other countries are technically so weak
>> that they are unable to develop hardware/software from description
>> of cryptos.
>
I don�t think even they are that dumb. They know very well what
-and
why- they are doing. The Romans did it with outstanding results:
divide and conquer. The "deny crypto to the bad guys" approach is
just an excuse, and we know it. If they want crypto, they will get
crypto. Period.
But by bullying people Waseenaar-style, they get several goals
achieved. First, they prevent (or impede, at the very least)
interoperability among the many crypto programs. If every country has
to develop its own crypto, it will be very hard to use it for
transmissions between one country and another...l which will keep
strongly encrypted messages inside one country, thereby splitting
encrypted net traffic within national borders (we thought the Internet
had no borders? Well, they�re triyng to prove us wrong)
Second, they will scare the ordinary Joe Sixpack out of crypto.
If
they tell you "crypto is used by criminals, we have to control it for
your own good" you might happen to send them to hell or, if you belong
to the 6000 billion+ guys outside these newsgroups, just want nothing
to do with it. The choice is yours, but don�t feel free to choose.
It is like an 8-years-old: you can physically grab the cookie jar, but
will think it twice if you know the consequences of your mom finding
out.
Thrid, it will make adoption of strong crypto standards more
difficult for the industries. Large or small, business want to legal
troubles. If they feel that the use of 128bit encryption will put
them under the eye of Big Government (be it Custom Export, tax, or
whatever), they might also be scared out of it. If the US feels
capable of punishing the EU for trading with Cuba (Helms-Burton law),
do you think they will hesitateto enforce anticrypto laws? They will
have to put up stamina if they find themselves alone against the
world, but if it is made a standard practice, nobody will notice.
If this goes on like this, we might end up with a multinational
Big
Brother telling us how to encrypt (strong enough to keep the average
hacker out of the game, but certainly not the NSA or the FBI). Yes,
we do have PGP/fortiffy/.. (your favorite 128bit crypto goes here),
and we use it ... but we risk becoming a species on the way to
extinction. There�s no middle point: either we defeat Wassenaar, or
strong crypto will eventually vanish for us ordinaty netizens.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQEVAwUBNoIUykbuhOe6IyotAQERLwgAqcYmQJs8bYWU89LEZhKZ74ila28FAwV1
5D1zvVXAmSPJjviR65AOpXgfvYdocJKcXmA7zLOvq4K/JaEv42TN/bhRTkb/QrSQ
Jd0To8+Im7UWMpTZyMNzhslvAlukcHi3BqNwHqwErnm8HaPShkz9i0aqTeMEGz6t
ddGjSgPyWd7vtFs2/zcaRb7c1bjhcN4GoSCT6NlRJUlkBLbxwnfuQ/oYuX5b7FOi
DxHpSO7LVYqWwsAtYXXJ6wn3LQax6LUISWc6vvpc9kELk8jANQiS9MqE1oKvjVsd
ShegRz+ywja5+Cyuh/zEdeHGE413cnuduRipVeeBayeu0rDu7B4YGg==
=0dJ5
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
