Cryptography-Digest Digest #631, Volume #9 Tue, 1 Jun 99 14:13:05 EDT
Contents:
Re: The BRUCE SCHNEIER Tirade (Nathan Kennedy)
Re: Using symmetric encryption for hashing (SCOTT19U.ZIP_GUY)
Re: Viability of encrypted flash cards? (fungus)
Re: Oriental Language Based Enryption (Mok-Kong Shen)
Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1) (Michael J.
Fromberger)
Re: The BRUCE SCHNEIER Tirade (Daniel Hartmeier)
Re: SHA-1 output random? (Lincoln Yeoh)
Re: Please recommend freeware encryption SDK (Greg Bartels)
Re: 8Bit encryption code. Just try and break it. (Sundial Services)
Re: The paradox of secure key distribution channel (Lincoln Yeoh)
Re: Viability of encrypted flash cards? (Phil Hunt)
Paper on Making Usenet "unerasable"? (Elf Sternberg)
576-bit blowfish?! ("Matthew Bennett")
P3 and OTP (Greg Bartels)
----------------------------------------------------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Tue, 01 Jun 1999 20:50:52 +0800
[EMAIL PROTECTED] wrote:
> > Contrary what you seem to imply, you COULD NOT just use a key as large as
> > the device... You couldn't rewrite a sector encrypted with the same key
> > sector that the previous version was... you could use the two encrypted
> > versions to easily derive both.
>
> Here you are making a false assumption, and, natuarally, reaching a
> false conclusion. The threat model is not an adversary watching
> everything that passes over the IO channel to the device. The threat
> model is someone who obtains an image of the device, probably by theft
> or seizure of the physical storage mechanism.
All right, I read you now. But I think if anyone is making false
assumptions, it's not me. You did say "ignore the rewrite issue", and
naturally my response was "you can't." You did not limit the threat model.
Naturally, with the threat model thus limited, you can ignore the rewrite
issue. There's still the issue of having a OTP device the size of your
working device, and hiding it, which would be a major pain for real-world
scenarios. If you could keep 2 gig of data hidden, what good does keeping
2 gig of OTP secret do?
The fact is, in the real world, you can't pick your threat model. Would
users of Scramdisk or ppdd find your threat model acceptable? I don't
think so.
> An intermediate threat model might include an adversary obtaining
> multiple instances of an image backup or equivalent. But this is a
> pretty remote scenario.
Intermediate? Remote? If they can grab it once, how come not twice,
without even being noticed? If they are allowed to physically come and
remove it, why can't they come in and duplicate it a few times covertly?
And the if they could, cracking any modified text would be trivial. I
don't like your threat model.
> In order to protect against this threat you'd have to use something
> other than 1:1 XOR as your fundamental operation. BFD.
And if you introduced some other system which involved, say, a one-way
function, you no longer have OTP. Sorry. But you knew that... OTP's
fundamental operation must be provably a keyed reversible one-to-one
mapping of possible plaintexts to possible ciphertexts with an effective
keyspace equal to the number of possible mappings, which is why XOR, being
the simplest, is used. A change of OTP's fundamental operation makes no
difference.
> OF COURSE it won't be as convenient PGP, PGPdisk, Scramdisk, et al. OF
> COURSE it is more hassle than a small-key cipher. But we don't know how
> secure small-key ciphers are. We _do_ know how secure an OTP system is
> if it is properly implemented. That may be valuable enough in some
> circumstances to put up with the hassle.
OTP is only provably secure when you can provably secure your OTP. When
there is no issue of secret channel bandwidth, say, between two agents with
a secure channel that closes, OTP makes sense. When you are dealing with a
situation where you can only keep a much smaller secret, it doesn't.
The fact is, for data storage involving one party, simple logic proves that
OTP is inappropriate and doesn't work. If the person can securely stow X
bits from disclosure (by memorizing, hiding, carrying...), he does not need
to encrypt X bits. If he wants to store greater than X bits from
disclosure, than he needs to obfuscate those bits according to a secret
with less than or equal to X bits, hence, symmetric keyed encryption.
> > OTP could work for write once, read once/many mediums or archived data,
> > albeit much worse and more inconveniently than traditional symmetric,
And you note that I repudiated even that small concession made without
thinking...
> > but
> > couldn't possibly be practical for random-access FS encryption.
>
> Here we disagree. Futher comment on your part appears to be pointless.
Okay. Show me. Otherwise I agree, further comment on my part is
pointless. I do not believe your threat model is realistic in the real
world, especially if you're going to all that trouble for provable security
to begin with, and I still do not think OTP makes sense for archive or FS
encryption.
Nate
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Using symmetric encryption for hashing
Date: Tue, 01 Jun 1999 14:20:23 GMT
In article <[EMAIL PROTECTED]>, Paul Onions
<[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> Actaully I think scott19u or scott16 don't suffer from the problems
i menat scott16u nit scott16
>> you have mentioned when using most block ciphers in CBC mode.
>> Since any change anywhere in input file affects the whole output file
>> you could use the last (or even first) few bytes as a "hash" if your
>> looking for an encryption method where you are only using a certain
>> amount of the output as a hash.
>
>No. Thinking about this I've just realized that there is a rather obvious
>and general argument as to why you cannot use a few bytes of output from a
>message encryption with a known fixed key as a cryptographic hash of that
>message.
>
>It's not one-way: given a hash output, simply "invent" the other ciphertext
>bits and decrypt. This gives a preimage of the output.
I am not sure what you mean by invent here since I don't think the
other bits are that easy to find with out the original input text. If you
think about it my scott19u contest is based on this being hard since in the
contest the "key" is given only a few bytes of the encrypted output file
need to be found.
>
>It's not collision-resistant: as above, but "invent" two lots of ciphertext
>bits and decrypt each. This gives two preimages with the same output.
This is true but it is highly unlike that either preimage would be ascii
or anything meaningful. Also take some file 100 bytes in length and hash
down to 64 bits. Just becuase of the size difference there would be many
collisions. True it is easier to find streches of 100 bytes that collide with
my method but that does not mean that there are more such collisions.
All it means is that you have a way to calculate what the collisons are
and as a matter of fact the collsions are the minimun number possible.
since again going back to the 100 bytes of input hashing down to 64 bits
(8 bytes). there are exactly 2**(92*8) ciphers that can be "invented" that
decrypt back to files that have the exact same hash. And with this method
every possible hash output has exactly the same number of possible input
sequences. This should besides the fact every bit new changes the hash
should be a requirement for a good hash.
For those whohave trouble following this is scott19u in the non lenght
changing mode.
>
>So using any kind of invertible message transformation in this way is no
>good for constructing a cryptographic hash.
>
>Paul(o)
>
I value your judgement and realize a hash should not be invertable but
this is not actuallt invertable since only a subset of bits out go to the
hash.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: fungus <[EMAIL PROTECTED]>
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Date: Tue, 01 Jun 1999 15:06:19 +0200
[EMAIL PROTECTED] wrote:
>
> On Mon, 31 May 99 20:45:50 GMT, [EMAIL PROTECTED] (Phil Hunt)
> wrote:
>
> >Couldn't the authorities just threaten to lock up this person until
> >he hands over the key?
>
> "Oops I forgot the passphrase."
>
Better to say "I never knew the passphrase, it was randomly generated
by the computer and changed once per week. I just copied it from the
piece of paper when I needed to access the data, I never memorized
the 16 random letters - too difficult for me, I think it began with
a G though. The paper??? Oh, I ate the paper when I was arrested...."
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Oriental Language Based Enryption
Date: Tue, 01 Jun 1999 15:48:45 +0200
Jerry Coffin wrote:
>
> There's another effect to take into account here though: what would
> start out as, say, 5 to 10 characters in English will often translate
> to only 1 or 2 characters in Chinese. IOW, you get a compression of
> something like (at a guess) 5:1 characters in translating from English
> to Chinese. Since each character is (roughly) twice as large in
> Chinese, you're getting something like 2.5:1 compression in terms of
> bytes.
Though on the one hand I intuitively believe the existence of
certain 'compression', I am afraid that a numerical calculation of
that may be subject to debate. A Chinese character with an area of
font double of that of an English capital letter is more difficult
to read than the captital letter (i.e. in terms of human information
processing), I believe. Further one can argue about the equivalence
of expressions. This is compounded by the fact that in any language
one can express an idea tersely or not, according to some popular
styles or otherwise, etc. (This, however, could probably be neglected
in issues concerning encryption if one makes the assumption that
messages are always formulated rather terse and without regard to fine
styles.)
I like to add here something to a point which I only touched upon
previously, namely the opponent's resources of language expertise.
Especially in speech communiction, a comparatively seldom language
spoken in a special (minority) dialect could in some sense compete
well with the services rendered by encryption in written communication,
particularly if the messages need only be unavailabe to the opponent
for a relatively short time. I remember that Kahn's book has an
example of that from WWII. Is this being praticed in modern times?
If yes, how effective are actually the efforts of tapping civilian
communications by certain institutions with the claimed goal of
suppressing criminal activities? (In this respect quite a large number
of languages spoken by few people are in the Orient, I believe
in particular in Indien, but certainly there are plenty of such
languages in other continents too.)
M. K. Shen
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1)
Date: 1 Jun 1999 13:43:20 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Nogami) writes:
>If the software can't stand up to in-depth analysis by professionals,
>it's completely worthless as an encryption scheme.
>This is why all of the commonly recognized encryption software
>packages, such as PGP, Bestcrypt, scramdisk, etc. use public
>encryption algorithms. While you certainly don't have to release ALL
>of your code, you should be releasing the part of the code that
>actually does the encryption.
Actually, I'd argue that ALL the code for any serious encryption
package should be released. Most failed cryptosystems fall not to
esoteric cryptanalytic attacks on the ciphers themselves, but to
protocol and implementation failures in how the ciphers are used.
Certainly, it is important that your implementation of the cipher
itself should be correct -- but that is hardly the entire picture.
Just as ciphers themselves need to be reviewed and attacked openly in
order to test their strength, so too should the software that uses
these ciphers in a particular context. After all, in a real security
situation, the first thing your opponents are going to try is to
exploit weaknesses in the way you use your encryption tools.
If you're going up against a government, that probably includes
attacking the ciphers you use ... but why should anyone waste time and
money trying to crack a strong published cipher, if they can recover
your cryptographic keys out of a preference file, or take advantage of
a weakness in your encryption mode, or any number of other common
attacks. Thus, being able to review the rest of the code is at least
as important -- if not more so -- than reviewing the ciphers
themselves.
Cryptography is no place for secrecy ... an ironic axiom, to be sure,
but true.
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
Mp/8iFe3es7ycyzY8saI8mJI+TMcPxaY+4JFcOf+ximcYBCdQ87W0Sla7NDY9JGVWRe5dz8/
Remove clothing if you wish to reply to this message via e-mail.
------------------------------
From: [EMAIL PROTECTED] (Daniel Hartmeier)
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Tue, 01 Jun 1999 14:03:20 GMT
On Fri, 28 May 1999 19:34:54 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
> In cryptography it is irrational and dangerous to assume strength
> simply because no weakness has been shown.
"Absence of evidence is not evidence of absence" - Carl Sagan
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: SHA-1 output random?
Date: Tue, 01 Jun 1999 14:38:18 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 31 May 1999 08:00:51 +0200, [EMAIL PROTECTED] (Francois Grieu)
wrote:
>At least, the output of SHA-1 is asymptotically equidistributed when
>message size grows, as a simple consequence that the round function,
>for a given message appendice, is a bijection on the set of states.
What is the minimum amount of input should I supply SHA-1 for it to work
well enough? e.g. stuff is reasonably mixed enough.
Right now for a program running on Linux, I'm supplying it about 31
variably random bytes from /dev/urandom, and trying to use SHA-1 to
concentrate stuff a bit. I'm not sure if the trade off is worth it - coz
reading off 31 bytes will deplete the entropy faster than reading fewer
bytes. But I don't know how random is /dev/urandom- maybe I should just
read off fewer bytes, use them directly and not hash them.
Any thoughts?
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Subject: Re: Please recommend freeware encryption SDK
Date: Tue, 01 Jun 1999 10:45:10 -0400
FYI (and slightly off-topic)
just read a book called "Open Sources" by O'Reilly this weekend
(highly recommended reading for anyone in computers)
freeware is generally considered an out-of-date term, with no copyright
backing. it is used to refer to several different types of copyrights,
which have some pretty big differences, such as public domain,
gnu public licence, and open-source
public domain, as a legal term, means that the software has
no copyright, and someone can take public domain software, put their
proprietary copyright on it, and remove it from the public domain.
gnu public license, guarntees that the software will be available
as source code, that works derived from GPL must itself be GPL'ed
(the copyright is viral).
open source definition, defines what terms must be met by a copyright
or licence to qualify as open source. it requires that source code
be available. it does not require that derived works be open source as
well.
none of these require that the code be available for no money.
interesting book.
Greg
Squitter Shivwits wrote:
>
> Dan Koppel wrote:
> >
> > Hello all,
> > I was wondering if anybody out there could recommend a freeware
> > encryption SDK that could be used for commercial purposes. I would like to
> > integrate it with some software that I wrote. I understand that PGP is
> > freeware if used non-commercially, so I guess I'm looking for something
> > else. Please let me know if I've got my facts right.
> > Thanks and I appreciate any input on this,
> > Dan Koppel
> > [EMAIL PROTECTED]
>
> Use scott19u.zip for the finest in free security:
>
> http://members.xoom.com/ecil/index.htm
>
> I have used it and nobody reads my files.
------------------------------
Date: Tue, 01 Jun 1999 09:28:54 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: 8Bit encryption code. Just try and break it.
Roger Carbol wrote:
>
> Phoenix <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>:
>
> >I'll tell you right now I know nothing of encryption as a
> >(science?). I only know that my VB prog changed text or files into
> >unintelligable garbage and then ressurects them. Other than that
> >I haven't even read the entire algorithm. I only program the GUI
> >and other features.
>
> That implies that a known-text attack is feasible; that is, anyone
> with a copy of the program can feed it whatever input they like,
> and then analyze the output.
>
> There *might* be some interest if you provided a URL (as opposed
> to posting) where you make available, say, a couple thousand
> plaintext-encryptedtext pairs. And then post a piece of
> encrypted text for the purpose of solving for the plaintext.
>
> Then again, it's quite likely no one would bother.
>
> .. Roger Carbol .. [EMAIL PROTECTED]
Phoenix:
Anyone(!) can create a program to transform text into something that
looks unintelligible... and is. But it would be false security indeed
to assume that no one can defeat it.
One of the under-rated truths of encryption is that one encrypted file
looks very much like any other encrypted file -- regardless of the true
strength or weakness of the algorithm used to create it -- and every one
who builds an encryption algorithm assumes that theirs must be
unbreakable.
It is unlikely that serious cryptologists will spend much time, if any,
looking at your work simply because there are hundreds of algorithms out
there that HAVE been inspected, closely, by seasoned cryptologists.
Anyone can snap them into their application and know with some certainty
exactly how difficult it will be for an attacker to break a particular
message. In a world that lives and dies by probabilities ... the
probability that your algorithm will be better is "near zero."
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The paradox of secure key distribution channel
Date: Tue, 01 Jun 1999 14:49:33 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 31 May 1999 19:42:04 +0800, Nathan Kennedy <[EMAIL PROTECTED]>
wrote:
>Certainly OTP has been a traditional spy code, used universally. That was
>back when spies couldn't carry around computers and OTP was the simplest,
>securest, most sensible paper-and-pencil code there was for a spy. I doubt
I'm sure that there are very many situations where spies can't carry
computers or electronic equipment. And in many situations paper and pencil
code has got to do - coz the usual commercial ciphers aren't brain
friendly.
Old fashioned codes will still have to do in some unfortunate cases.
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (Phil Hunt)
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Date: Tue, 01 Jun 99 14:42:02 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
> On Mon, 31 May 99 20:45:50 GMT, [EMAIL PROTECTED] (Phil Hunt)
> wrote:
>
> >Couldn't the authorities just threaten to lock up this person until
> >he hands over the key?
>
> "Oops I forgot the passphrase."
If the judge doesn't beleive him, he might be doing a long stretch.
Another idea would be to have an encrypted file which can be decrypted
to form different plaintexts, depending on the cypher key. So one
key to decrypt to innoculous pictures, and another key could decrypt
to stuff the authorities were after.
--
Phil [EMAIL PROTECTED]
------------------------------
From: Elf Sternberg <[EMAIL PROTECTED]>
Subject: Paper on Making Usenet "unerasable"?
Date: Tue, 1 Jun 1999 10:15:17 -0700
A year or so ago I stumbled on a paper with a number of
interesting suggestings for making documents difficult, if not impossible,
to erase. There were a number of proposals in the paper, the most
interesting (to me at any rate) of which was the idea of serializing
documents in a special file system such that the removal of any one
document would result in the destruction of all other documents in the
filesystem. In this way, a legal argument could be constructed such that
a court ordering the removal of a document would be stymied by the
overriding legal need to do as little damage as possible to other
documents not related to the suit in question.
Part of the paper concentrated on turning Usenet into such a
system, with parts of documents being distributed into multiple stores,
thus making the process of destroying any one document (perhaps by
requesting each article serially except the one that needed to be
destroyed and storing them in another filesystem) impossibly complex.
Does anyone remember this paper? I had a hardcopy but it seems to
have vanished in a move. Thanks in advance.
Elf
Elf M. Sternberg, rational romantic mystic cynical idealist
If you're so smart, why aren't you naked?
A.A 1493 http://www.halcyon.com/elf/
------------------------------
From: "Matthew Bennett" <[EMAIL PROTECTED]>
Subject: 576-bit blowfish?!
Date: Tue, 1 Jun 1999 18:38:53 +0100
Just to test, I tried using a key longer than 56 characters in my blowfish
implementation written C (my key is stored as an unsigned char). After
increasing the defined maximum key length in the blowfish header file, I
found I could get a different cipher-text output from changing any one of up
to ~72~ characters in my key. For example, using a 100-byte key, changing
only any of the last 27 characters of this key had no effect on the cipher
output.
So it seemed a maximum of 72 characters were being "used" - unlike the 56 it
is supposed to be? This effect was seen in two separate blowfish source
codes.
Could someone point out to me where I've gone wrong :)
/\/\/\//
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Subject: P3 and OTP
Date: Tue, 01 Jun 1999 11:12:08 -0400
wow, I take some time off, and come back to a few
hundred messages all about one time pads, and
a whole lot of flames.
two thousand dollars will get you a
1) pentium III with random bit generator
2) a DVD burner, and a lot of spare disks.
if someone would do an analysis of the numbers
that come out of the P3, and show that they
dont contain some sort of hidden pattern, then
what you have is a briefcase with a laptop
and a bunch of disks will get you terabytes
of secure data transmission.
key syncronization and retransmission problems
are just a matter of good software.
if you're a bank or telecomm that is sending
terabytes of data every second, then OTP's
are not for you, but if you just want to
keep secret the email that you send to a friend
of yours, then OTP is the way to go.
Greg
------------------------------
** 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
******************************
