Cryptography-Digest Digest #945, Volume #12 Tue, 17 Oct 00 15:13:01 EDT
Contents:
Re: Works the md5 hash also for large datafiles (4GB) ? (Tom St Denis)
Re: Basic skills and equipment... (Tom St Denis)
Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java ("Kevin W. Wall")
Re: SALT + stream cipher (Tom St Denis)
Re: SALT + stream cipher (zapzing)
Re: "The code book" where (Beagle)
Re: Smartcard, Mathematical Proof? (Mykhailo Lyubich)
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: A new paper claiming P=NP (Eric Cordian)
Re: Pegwit group started to make a alternative to PGP based on ECC (Mike Rosing)
Re: SALT + stream cipher (John Myre)
Stolen Enigma Machine Recovered (Jim)
Re: Works the md5 hash also for large datafiles (4GB) ? ("Joseph Ashwood")
Re: SALT + stream cipher ("Joseph Ashwood")
Re: algo to generate permutations ([EMAIL PROTECTED])
A question about DES ("Massimo")
Looking for small implementation of an asymmetric encryption algorithm
([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Tue, 17 Oct 2000 16:00:57 GMT
In article <Pine.GSO.4.21.0010171040510.705-
[EMAIL PROTECTED]>,
Daniel Leonard <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Oct 2000, Tom St Denis wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > Runu Knips <[EMAIL PROTECTED]> wrote:
> > > [EMAIL PROTECTED] wrote:
> > > > I have to compare diskimages. To save diskspace I want to use
> > > > a hash (md5).
> > > >
> > > > Work md5 for such large files?
> > > > I know I would generate a 128bit signature, what I mean is, is
> > > > the probability that two different large files have the same
> > > > signature as low as for smaller files.
> > > >
> > > > In other words, is the algorthm of md5 only designed for "small"
> > > > files?
> > >
> > > AFAIK MD5, SHA-1, RIPE MD160 and Tiger/192 all work with 64 bit
> > > size counters. I guess SHA256 does, too.
> >=20
> > SHA-512/384/256 all use the exact same MD-Strengthing as MD5 so yes,
> > they are 64-bit counters.
> >=20
> > Tom
>
> SHA512 (and thus SHA384) have a _*128*_ bit counter. Read carefully
p.20
> of the draft:
>
> Pad the message in the usual way: Suppose the length of the message
M, in
> bits, is l. Append the bit ``1'' to the end of the message, and then k
> zero bits, where k is the smallest non-negative solution to the
equation l
> + 1 + k <=3D> 896 mod 1024. To this append the 128-bit block which
is equa=
> l
> to the number l written in binary.
Oops... sorry. At any rate who will use a 512-bit hash anyways?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Basic skills and equipment...
Date: Tue, 17 Oct 2000 16:02:50 GMT
In article <8shlls$j2u$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> "Sam Simpson" <[EMAIL PROTECTED]> wrote:
> > Tom St Denis <[EMAIL PROTECTED]> wrote in message
>
> > Tom, you're the most prolific poster in this forum and you sometimes
> > shoot from the hip - are you really surprised that some people will
> > disagree with you on occasion? I think you could quite correctly
> > call Bobs comments "a flame",
>
> Huh? I made it quite clear that I was NOT flaming in my original
reply!
> Or do you automatically assume the equation "any criticism = flame"???
>
> It was *HIS* subsequent reply that was insulting. Have you forgotten
> his slurs on Bruce Shneier (and other professionals in the thread
> a few months ago about why the "pros" never post)??
Oh yeah blame me now.
My point about the "pros" was a quite valid one though. How are we
suppose to trust them if they never speak?
Anyways, that's OT now.
> > but he has problems being civil to most
> > people here,
>
> I never respond to "most people" here. The vast majority of my posts
> amount to "pouring water on nonsense". It is not surprising that
> this comes across as uncivil. But then, many people are quick to
> take offense when none was intended.....
Because everything you do is perfect?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 17 Oct 2000 12:38:20 -0400
From: "Kevin W. Wall" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,comp.lang.java.security,comp.lang.java.programmer
Subject: Re: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java
Bjorn Luser wrote:
>
> Nice idea. Too bad you applied for a software patent for it.
>
> Software patents are inherently evil. Use copyright protection
> instead.
I'm a bit confused here as to whom the "you" refers to. Are you
referring to Christian Collberg and Clark Thomborson or to
Gregg Townsend and Christian Collberg. Also, are you referring
to a US patent or an international patent? A search of the USPTO
turned up 187 patents since 1996 containing the terms "software"
and "watermark", but none of these include any of the 3 authors
as inventors.
Also, since Townsend and Collberg implemented SandMark under an
NSF grant (which is funded by US federal taxpayer dollars), I
don't think that (implementation) work would be patentable.
(It used to be that software done under NSF grants was considered
"public domain", but I'm not sure that is still the case.)
Finally, while I'm posting, I'd like to pose the following question:
Assuming that the intended application is targeted for preventing
software piracy, just whom is such a software watermarking process
intended to prevent from copying? Casual users or "professional
pirates"?
If it is only intended to copying by clueless casual users
sharing a CD or whatever, I'm sure it's workable. (And maybe
overkill.) But if it only prevents casual users from copying, is
that really where the big $$ are lost with respect to software piracy?
I concur with Bruce Schneier that NO copy protection--especially
one that is based on software alone--will prevent well equiped,
determined software pirates (i.e., those who are in it for the
money) from reverse engineering a software product and removing
any copy protection. Such people are willing to break the law
to accomplish their goals. And once they break the copy protection
mechanism and remove it, the resulting pirated software can then
be freely copied by anyone. Sure, it will make the theives' job
more difficult, but since it must be possible to find the watermark
in the first place, it can't be impossible to remove it completely.
And, it only takes one person to crack it.
Schneier goes into this in detail in his recent book
"Secrets and Lies: Digital Security in a Networked World"
(ISBN 0-471-25311-1). (See for example, pages 248-253.)
No doubt history is also on the side of Schneier's prediction.
Witness all the broken copy protection schemes from the 1980's
and the more recent ones with the DVD, etc.
Also, allowing illegally pirated copies isn't always a bad
strategy. You just write really buggy software like M$ and
then sell SUPPORT and updates instead! ;-)
--
Kevin W. Wall Sr. SW Architect / Staff SW Eng.
Qwest Communications International, Inc. Java / UNIX / Security
Business Object Development Center Business phone: 614-932-5542
Dublin, OH. 43017 E-mail: [EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SALT + stream cipher
Date: Tue, 17 Oct 2000 16:46:47 GMT
In article <[EMAIL PROTECTED]>,
"William A. McKee" <[EMAIL PROTECTED]> wrote:
> When you encrypt a file with a stream cipher, you choose a password
and salt
> (random number) to seed the pseudo random number generator. Then you
xor
> the file with the output from the PRNG. My question is how do you
remember
> the salt? Do have to keep it secret or can you save it as the first
few
> bytes of the encrypted file?
Generally don't use the word "a prng" with stream cipher. While it's
true RC4/Seal are prngs, the term "prng" has a bad connatation.
Also the salt (usually 64+ bits) is concatenated to the password and
hashed to make the key for the cipher. The salt can be stored along
with the ciphertext in the open.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: SALT + stream cipher
Date: Tue, 17 Oct 2000 16:50:31 GMT
In article <[EMAIL PROTECTED]>,
"William A. McKee" <[EMAIL PROTECTED]> wrote:
> When you encrypt a file with a stream cipher, you choose a password
and salt
> (random number) to seed the pseudo random number generator. Then you
xor
> the file with the output from the PRNG. My question is how do you
remember
> the salt? Do have to keep it secret or can you save it as the first
few
> bytes of the encrypted file?
I believe in applications like these the "salt"
is more often called an "initialization vector".
You can choose one randomly or use something
like the date, time, and your initials catenated
together. Yes, it is usually appended to the
beginning of the message. It is only there so
the output from the "PRNG", as you call it, will
be different each time. Otherwise the cryptanalyst
can learn what the xor of two messages are if they
have the same "salt".
--
Void where prohibited by law.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Beagle <[EMAIL PROTECTED]>
Subject: Re: "The code book" where
Date: Tue, 17 Oct 2000 17:06:59 GMT
The codes have been cracked. see www.simonsingh.com
In article <8shkn7$i47$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hey
>
> I have just ordered "The code book" but I have to wait 3-4weeks before
> I can get it. Do somebody know where I can download an PFD of it,
> becouse I will like to spend some time whit breaking the codes?
>
> Best reg.
> Nenad
> [EMAIL PROTECTED]
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mykhailo Lyubich <[EMAIL PROTECTED]>
Subject: Re: Smartcard, Mathematical Proof?
Date: Tue, 17 Oct 2000 19:27:33 +0200
Reply-To: [EMAIL PROTECTED]
Sundial Services wrote:
>
> Assuming that this is not part of your homework ... ;-) ... if the two
> systems implement the same protocol, and behave identically, then for
> all external intents and purposes they -are- the same.
This is not my homework: This is a real task from real world.
You have two implementation of the protocol.
There are two programs which operates on the client behalf.
One of the programs uses a chipcard for some operations.
The protocol is secure electronic transaction protocol (SET) for example.
So, you are sure it's not possible to implement client part on the chipcard
completely.
You know also which part of the message construction is placed inside the chip.
You should decide which program you will propose to your customers.
The money is not important. You are interested in security only.
You need a method to estimate the level of security in both cases or at least
compare these two systems.
--
Mykhailo Lyubich
Dept.of Computer Science office phone +49-381-4983407
University of Rostock office fax +49-381-4983440
Albert Einstein Strasse 21 http://wwwtec.informatik.uni-rostock.de/~ljubich/
D-18051 Rostock, Germany mailto:[EMAIL PROTECTED]
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Tue, 17 Oct 2000 17:24:32 GMT
Mok-Kong Shen wrote:
> I like to ask your favour to explain (excuse me, once again)
> but in a radically simplified case, namely on a four round
> DES (two cycles) with a single assumed random permutation
> (not used as known information) and with (u,u) as the single
> type of chosen plaintext.
Why the special form (u, u)?
If you want to do the specific exercise, you'll need to
understand the attack, and then study the DES round function
in excruciating detail. I'd suggest you look at linear
cryptanalysis to decide how many sample texts to work with
versus how much to guess-and-check.
> Could you give the procedure in
> such concrete details, in particular the choice of u (if
> anything special) and the determination of the locations of
> the siblings desired for processing and the method of
> solutions of the equations involving these, so that one can
> actually write a computer program to perform exactly the
> attack and be able to deduce the key bits?
I think my description is sufficiently precise to support the
attack up to the point where it would DES specific in your
example. At that point it will be up to you. Can you tell me
the first step that is not clear to you?
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Eric Cordian <[EMAIL PROTECTED]>
Subject: Re: A new paper claiming P=NP
Crossposted-To: comp.theory,sci.math,sci.op-research
Date: Tue, 17 Oct 2000 17:37:23 GMT
In comp.theory Dima Pasechnik <[EMAIL PROTECTED]> wrote:
> Have you ever written a referee report on a paper submitted to a
> journal? It can be a lot of work, and not very rewarding one.
> As far as the preprint in question is concerned, it appears not to meet
> the normal journal standards, as the consensus on sci.op-research seems
> to be. A (mild) reply from a good journal, should the preprint be
> submitted there, would be - "hardly readable, such and such things
> claimed are not proved. a substantial rewrite is necessary..."
Yes, it's barely a preprint. Yes, it's very hard to read.
However, if it does contain a working algorithm for solving an NP-Complete
problem in polynomial time, I would rather have it now, as opposed to two
years from now. I think the author's idea of debugging it on the
Internet, as opposed to spending another year or two polishing it to
publication standards, is a good one.
Some things are just so important that getting them out has to take
precedence over making them neat.
I'm halfway through the thing, and am prototyping the algorithms in APL
as I go. So far I haven't seen anything wrong that can't be fixed. When
I hit the end, I will either have a refutation or working code, and I will
post my results.
--
Eric Michael Cordian 0+
O:.T:.O:. Mathematical Munitions Division
"Do What Thou Wilt Shall Be The Whole Of The Law"
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Pegwit group started to make a alternative to PGP based on ECC
Date: Tue, 17 Oct 2000 12:56:10 -0500
Paul Rubin wrote:
> Actually, nothing stops you from generating El Gamal (or these days
> even RSA) private keys from a passphrase. What's nice about ECC is
> that it's reasonably practical to type *public* keys into a program
> (example: AF646-BEJTR-BTGAP-7MFPW-GRVYX-RRGQW = 150 bits of info).
> This is a central feature of the program I've been wanting to write.
>
> It'll be cool if Pegwit can do stuff like this.
that's the goal. Creating a DLL from it so it's a portable
package is also a goal. We'll get there one step at a time,
but the more people, the more steps we can take at once :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: SALT + stream cipher
Date: Tue, 17 Oct 2000 12:00:11 -0600
"William A. McKee" wrote:
>
> When you encrypt a file with a stream cipher, you choose a password and salt
> (random number) to seed the pseudo random number generator. Then you xor
> the file with the output from the PRNG. My question is how do you remember
> the salt? Do have to keep it secret or can you save it as the first few
> bytes of the encrypted file?
See http://ciphersaber.gurus.com/ for a setup like that. The salt
(called IV in CipherSaber) is selected randomly by the system (not
typed in by the user) and is included in the clear with the encrypted
output. (Decrypting removes this, of course.)
If you have to keep the salt secret, there's no point in not calling
it part of the (ever changing) password.
The idea is to prevent reusing PRNG output without having to change
the key each time. But actually, you are changing the real key,
which combines password and salt. Then you keep the password secret,
and it doesn't change so you can remember it; and you don't keep the
salt secret and so you don't have to remember it, and it changes
every time.
Whether this is secure or not depends on the details of how the
password and salt are combined and how the PRNG works. Paranoids
do things like hash the password and salt together to get the PRNG
key, and make sure the salt is a strong random number (not predictable
by the enemy) as well. Ciphersaber takes a much simpler view:
essentially the real key is simply the concatenation of the salt
and password, and we rely on RC4 to mix things up enough.
JM
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Stolen Enigma Machine Recovered
Date: Tue, 17 Oct 2000 18:13:24 GMT
Reply-To: Jim
The Enigma cipher machine which was stolen from the museum
at Bletchley Park has turned up.
It was sent by post to the television 'personality'
Jeremy Paxman.
--
______________________________
Posted by Jim Dunnett
dynastic at cwcom.net
nordland at lineone.net
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Tue, 17 Oct 2000 10:57:36 -0700
> Oops... sorry. At any rate who will use a 512-bit hash anyways?
It all depends on your requirements. For some things the added security
over-shadows the added space of SHA-512.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: SALT + stream cipher
Date: Tue, 17 Oct 2000 11:05:33 -0700
"William A. McKee" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> When you encrypt a file with a stream cipher, you choose a password and
salt
> (random number) to seed the pseudo random number generator. Then you xor
> the file with the output from the PRNG. My question is how do you
remember
> the salt? Do have to keep it secret or can you save it as the first few
> bytes of the encrypted file?
Just to answer the question, you could broadcast the Salt (initialization
vector) on the local news, spray paint it on the side of a building, and put
it at the front of the encrypted file.
Now about Toms comment to use a hash, that's up to you, there are certainly
at least two sides the argument. First, the hash cannot increase the entropy
of the salt+passphrase, and since it can decrease it, it shouldn't be used.
The second side, and the (IMNSHO) more reasonable side is, even if the
stream cipher is broken, if you used a hash the attacker cannot recover your
passphrase, besides the likelihood of loss of entropy in a hash like SHA-1
is trivial until you reach at least 80 characters, it's safe to disregard
it, with SHA-256 it's around 128 characters.
Joe
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: algo to generate permutations
Date: Tue, 17 Oct 2000 18:20:29 GMT
In article ?[EMAIL PROTECTED]?,
Richard Heathfield ?[EMAIL PROTECTED]? wrote:
? [EMAIL PROTECTED] wrote:
? ?
? ? And another, 15x faster than the last (minus the printf()s). Still
not
? ? lexicographic order. Generating permutations comes up in attacking
rc4.
?
? Nice. In fact, very nice.
?
? Now, one nit and one question...
?
? The nit: you should really #include ?stdio.h? and ?string.h? (for
printf
? and strlen) - C headers are not just there for decoration! :-)
?
? The question: for the input aaa, I get six outputs - i.e. the first
'a'
? is considered to be different from the second 'a' and the third 'a'.
? Now, I don't mean to seem ungrateful, but it strikes me that you could
? have had any of three reasons for writing the program this way:
?
? (1) you couldn't be bothered to filter out duplicates - after all,
perm
? aaa | sort | uniq would do the Right Thing anyway. (Yes, I know, for
? this particular input, the sort step is optional...)
?
? (2) you couldn't work out how to do this filtering in C.
?
? (3) you have some deep cryptanalytic reason for retaining the
? duplicates.
?
? I'm betting on (1). Am I right? :-)
?
? --
? Richard Heathfield
? ?Usenet is a strange place.? - Dennis M Ritchie, 29 July 1999.
? C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
? K?R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
?
Nits: you are right. I also should have copied argv[1] into a private
buffer before munging it, in case some caller expected it not to change.
Question: Mostly (3). They asked for a permuter, I gave them a
permuter. (2), you mean aba would produce just aab aba baa? Hm, I
haven't thought about it. It could be done by sorting the letters
first, numbering duplicates, then having the permuter skip any prefix
with duplicates that are out of order. I'll not do that now, citing
(1).
- Bob Jenkins
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Massimo" <[EMAIL PROTECTED]>
Subject: A question about DES
Date: Mon, 16 Oct 2000 23:24:58 +0200
I'm an italian computer science student and I'm a beginner in cryptography.
I've the following question: what's the reason 'cause, in last DES step,
they applied the inverse of the initial permutation to the 64 bit block
instead of a different kind of permutation ?
Thanks a lot for your replies.
Massimo Ancillai.
------------------------------
From: [EMAIL PROTECTED]
Subject: Looking for small implementation of an asymmetric encryption algorithm
Date: Tue, 17 Oct 2000 18:52:32 GMT
Hello,
I'm looking for a small implementation of an asymmetric encryption
algorithm suitable for a low-memory embedded system. I need to encrypt
short (<64 bits) fixed-length messages. Decryption will take place on a
much more capable system. Most of the source code I've found is very big
and includes generic libraries for doing things like bignum math. Before
I try to whittle those down to just the pieces I need I thought I'd ask
here first.
Thanks in advance,
Emery
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
