Cryptography-Digest Digest #920, Volume #10 Mon, 17 Jan 00 22:13:01 EST
Contents:
Re: Password example encrypt/dycrypt! (Pelle Evensen)
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? (Richard A. Schulman)
how to encipher (Christopher)
Re: Cracking an ADFGVX cipher ("Douglas A. Gwyn")
Re: New Crypto Regulations ("Douglas A. Gwyn")
Re: New Crypto Regulations ("Douglas A. Gwyn")
Re: If enough is good, why is more better ? Re: Triple-DES and NSA??? (John Savard)
Re: New Crypto Regulations (John Savard)
Re: New Crypto Regulations (Johnny Bravo)
Re: Suitable hash for this application - in the public domain? (drickel)
Re: Forward secrecy for public key encryption (lcs Mixmaster Remailer)
Re: Questions about message digest functions ([EMAIL PROTECTED])
Re: crypt() (Bill Unruh)
Re: Cracking an ADFGVX cipher (GJJ)
Announce: Puffer 3.10 (Kent Briggs)
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? (James Redfern)
----------------------------------------------------------------------------
From: Pelle Evensen <[EMAIL PROTECTED]>
Subject: Re: Password example encrypt/dycrypt!
Date: Mon, 17 Jan 2000 22:30:02 +0100
[EMAIL PROTECTED] wrote:
> > You can find the MDx, SHA-1 and others at
> > ftp://ftp.funet.fi/pub/crypt/hash/
>
> You've missed one - the Message Authenticator Algorithm is, as far as I'm
> aware, the first Cryptographic Hash Function or Message Digest to gain
> widespread acceptance. It has become a part of ISO standard 8731-2:
> Approved Algorithms for Message Authentication. Even Applied Cryptography
> fails to acknowledge its historical importance.
>
> As it seems to be unavailable in electronic form, I've put HTML and PDF
> versions on my web site.
> http://www.cix.co.uk/~klockstone
The point was to show something that is reasonable to use in practice,
not to provide a good historical account of hash functions. :-)
>From section 2 in the paper;
"When a well designed authenticator is used, giving a 32 bit result,
the probability that a message alteration will not be detected is 2^-32,
which is small enough for most purposes."
Even if MAA is cryptographically strong, which we for the sake argument
can assume, 32 bits is much too small to be useful for anything but
perhaps ordinary hash table lookups. For hashing passwords, 32 bits is
close to as bad as not doing any hashing at all.
Regarding widespread acceptance, RFC1321 (MD5) has probably been just as
widely "accepted" for usage as a one way hash function. :-)
/Pell
======
Pelle Evensen [EMAIL PROTECTED] Telenordia AB/Algonet
http://www.evensen.org for public key. KeyID: 0xDCACD9A1
Public key fingerprint 22DC 520D 7E00 F79C 8BEB F055 1E8C 715E
------------------------------
From: Richard A. Schulman <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Mon, 17 Jan 2000 18:01:29 -0500
Reply-To: [EMAIL PROTECTED]
On Tue, 18 Jan 2000 04:32:43, [EMAIL PROTECTED] (Padgett
0sirius) wrote:
>Electronic Data Interchange or communications with people you know is =
being=20
>subhumed into Electronic Commerce.=20
EDI comprises batch data exchange between companies. The information
exchanged need not (and often does not) consist of a purchase or sale.
E-commerce consists of individual transactions between purchasers
(usually consumers) and sellers (usually retailers).
---
Richard Schulman
To email me, remove the "XYZ"
------------------------------
From: [EMAIL PROTECTED] (Christopher)
Subject: how to encipher
Date: Mon, 17 Jan 2000 23:12:54 GMT
Hi,
I am a beginner. I use p=20507,q=55889, e=67.
So if I only obtain n=pq=1146115723 and e=67. I have find the private
key from the public key, private key is d=85525323.
Pls tell me how to decipher a text use d,
since M^d mod n, M and d is too large handle is my computer.
Thanks
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cracking an ADFGVX cipher
Date: Mon, 17 Jan 2000 23:05:52 GMT
John Savard wrote:
> The account of how the original ADFGX cipher was broken in David
> Kahn's book "The Codebreakers" is the only one I'm familiar with,
I vaguely recall that Friedman's monograph on the subject had been
declassified and released to the National Archives. But I could be
mistaken..
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Mon, 17 Jan 2000 23:12:09 GMT
John Savard wrote:
> Democracy in the United States may have a bad cold, but it isn't
> terminal.
To the extent that people think a democracy is desirable,
the US ideal of government that promotes individual rights
has already died.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Mon, 17 Jan 2000 23:16:48 GMT
John Savard wrote:
> With export controls on encryption, the U.S. is at least doing what
> it can to prevent the world - a world that uses U.S.-made operating
> systems on its computers - from changing over to unbreakable ciphers.
But terrorists and other criminals can readily get around these
controls. As usual, it is the innocent who are adversely impacted
when they attempt to obey the controls.
One would think that it would be evident by now from the so-called
"War on Drugs" that the aim of the controllers is more to restrict
freedom of non-criminals than it is to apprehend true wrong-doers.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.privacy,alt.security
Subject: Re: If enough is good, why is more better ? Re: Triple-DES and NSA???
Date: Mon, 17 Jan 2000 16:18:14 GMT
[EMAIL PROTECTED] (Padgett 0sirius) wrote, in part:
>There is another factor here, quantum economics or "good enough". If 112 or
>128 bits is currently strong enough that the only practical attack is to buy
>someone who has access to the key or steal it some other way, what is the
>purpose of a longer key ?
>Can see some people wanting to protect for "life plus" but with increased
>lengths, attacks against the algorithm become more efficient than brute
>force. For 3-Des, this is why 112 bits (two keys) are used rather than 3 (
>168 bits), there is no increase in strength so why add the computer cycles ?
Actually, that point of view is the mainstream view. The impressive
strength of today's ciphers is so far ahead of other factors governing
security in computer systems, that devoting all one's attention to
cryptography to the exclusion of other considerations is seen as a
harmful waste of time.
But there is another side to this question.
For one thing, computers have been getting bigger and faster at quite
an impressive rate. Already, the 56-bit key of DES has become quite
badly inadequate. Thus, a little extra margin of safety, against the
unnown extent of future advances in computers, seems prudent.
And there is an inherent problem in proving that any mathematical
problem really is hard. It isn't really possible to do that; all we
can do is prove that a problem is easy, because we already have the
easy solution in our hands.
Applications of encryption vary, however. In some cases, like
real-time satellite TV, or smartcards, very few cycles are available.
For E-mail sent from a desktop Pentium, that is not the case. Some
messages only need to remain secure until credit cards are routinely
replaced every three years; others, like medical records, ought to be
kept private for 100 years, if possible.
The real problem with using a symmetric-key cipher with a key of, say,
512 bits, is that in general nowadays (when used for E-mail, but not
for local file storage), any such cipher would be used with a
public-key method, like RSA or Diffie-Hellman, and the computer time
required to carry out _those_ methods to a comparable level of
security, not the cycles needed for the symmetric-key cipher itself,
is enough to become a nuisance. Hence, secret keys are highly
desirable, if one has the opportunity to prearrange them.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New Crypto Regulations
Date: Mon, 17 Jan 2000 16:54:37 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>John Savard wrote:
>> With export controls on encryption, the U.S. is at least doing what
>> it can to prevent the world - a world that uses U.S.-made operating
>> systems on its computers - from changing over to unbreakable ciphers.
>But terrorists and other criminals can readily get around these
>controls. As usual, it is the innocent who are adversely impacted
>when they attempt to obey the controls.
>One would think that it would be evident by now from the so-called
>"War on Drugs" that the aim of the controllers is more to restrict
>freedom of non-criminals than it is to apprehend true wrong-doers.
Oh, I agree. My point is only that those arguing for export controls
_would_ have a case, since they point to serious threats, if there
weren't good reasons for believing that the threat cited is
fundamentally bogus. What I do feel is that this is a side of the
argument that needs to be addressed; the fight can't be won on
principle alone.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Mon, 17 Jan 2000 19:09:47 +0000
On Mon, 17 Jan 2000 12:45:38 GMT, [EMAIL PROTECTED] (John Savard)
wrote:
>With export controls on encryption, the U.S. is at least doing what it
>can to prevent the world - a world that uses U.S.-made operating
>systems on its computers - from changing over to unbreakable ciphers.
This is based on the assumption that no one else in the world is
capable of designing a cipher as secure. Rather silly since at least
one of the ciphers in the finals for becoming the de facto standard
for American business encryption was submitted by a foreigner who is
in no way, shape or form affected by American export controls and has
already submitted his cipher to the world for them to do with as they
wish.
No matter how hard you try, you can't just ignore the genie back
into the bottle.
>That is almost a persuasive argument. Wars of aggression and terrorist
>bombs do kill people. The freedom to publish cryptographic source code
>on the Internet would, I think, quite reasonably seem to most people
>to be a rather small matter beside that.
This is dangerous thinking. It can seem reasonable, but it can also
seem reasonable to eliminate every single freedom you might posses in
the same manner.
i.e. "Terrorist bombs do kill people. The freedom of privacy, I
think, quite reasonably seem to most people to be a rather small
matter beside that. The police should be allowed to search anything,
anywhere and anytime they please in order to prevent terrorists from
building bombs."
Freedom is not to be limited because someone, somewhere might be
abusing it. That is the cost of being free. If someone is doing so,
you punish them for the action. You don't punish the other 99.999999%
of the law abiding citizens for the actions of a few.
Best Wishes,
Johnny Bravo
------------------------------
From: drickel <[EMAIL PROTECTED]>
Subject: Re: Suitable hash for this application - in the public domain?
Date: Mon, 17 Jan 2000 16:16:48 -0800
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Troed) wrote:
> Hi,
> I need a good hash algorithm for storing user passwords. The hash
> will
> later be used in encryption routines. At the moment 32 bytes are
> used
> to store the hash, which far exceeds MD5 (not secure enough?) and
> SHA-1. I've also looked at RIPE-MD, which I heard has a 256 bit
> variant (no more secure than the 160 bit version though)
> Are the various C-implementations of RIPE-MD 160 free for private
> and
> commercial use? Any pointers to a 256 bit implementation?
> If RIPE-MD isn't free, what other options do I have?
> thanks for any help,
> ___/
> _/
Are the bytes printable (are you using all 8 bits)? Anyway, you could
take 128 bits of the MD5 hash and concatenate them with 128 bits of the
SHA-1 hash. Maybe a bit of overkill.
david rickel
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: 18 Jan 2000 01:00:10 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Forward secrecy for public key encryption
Keep in mind that Maurer has patented his identity based PKC. See
http://www.patents.ibm.com/details?pn=US05150411__. This appears to
cover both the multiple-smallish-prime variant (e.g. 256 bit primes)
as well as the two-prime Pohlig Hellman variant.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Questions about message digest functions
Date: Tue, 18 Jan 2000 01:14:28 GMT
Tim Tyler wrote
> [EMAIL PROTECTED] wrote:
> : If we sort
> : the domain so that the higher frequencies are closer to the
> : center, then the shape we get is something like a set
> : bracket, '{', turned 90 degrees clockwise. The slope is
> : steep at the both ends and also steep very near the center,
> : but shallow elsewhere. The curve height is near the medium
> : value for the vast majority of the area covered.
>
> : The bell-curve is the opposite. The slope is shallow at the
> : ends and middle, and most of the area is under the curve
> : when the curve height is near its maximum.
>
> : This is not a minor issue. A bell-curve would imply a
> : strong tendency for the digests to group together.
>
> Both curves may be made arbitrarily close to a flat function.
>
> I was expecting a magnified view of the /center/ of
> a bell-shaped curve - which I'd hardly describe as
> exhibiting a strong tendency of the digests
> to group together.
You are only going to mislead people by describing such
curves as bell-shaped.
> : In theory we have to resist collisions of all sizes, in
> : which case a random function is perfect.
>
> This appears to be questionable.
In the sense that you can write yet another post questioning
it, yes.
> I've already raised
> the issue that for a hash that needs to exhibit
> collision-resistance (e.g. a hash used for signing
> messages) a PRF is likely to fail to exhibit a
> distribution that makes brute-force searching as
> hard as possible, under what seem to me to be
> plausible assumptions.
Actually the even distribution makes brute-force search for
a second preimage *easier*. Suppose we have a hash that
produces 160-bit digests that is a permutation (for messages
that are also 160-bits), and we need to find a collision
with a given message of any size larger than the digest. If
we search the space of 160-bit messages, we will find a
match in an average of 2^159 + 0.5 tries. That's almost
exactly a factor of two faster than against a random
function.
> Also, as I've said, this is mathematical never-never-land stuff, with
> "most" such messages exceeding the size of the visible universe.
I've been trying to pull you back to the real world. The
collision resistance of a hash function is defined by
tractability of the easiest collision location. The
advantage the perfectly even distribution yields against
exhaustive search is indistinguishable from zero.
[...]
> While for smaller messages, it can become interesting
> - particularly when getting a beter distribution
> completely eliminates the has collisions that would
> otherwise occur.
As David Hopwood pointed out in hist post (worth re-reading)
of 12/30/1999, all that shows is that some applications call
for something other than a hash. It does nothing to redeem
your claim that the random function model is "dead wrong"
for cryptographic hash functions.
> IIRC, I said from the start my argument was only of any real practical
> interest when dealing with messages that were typically small.
>From the start, myself and other have been explaining how
hashes really are, and really should be modeled.
You have yet to state your model. Obviously you want the
preimages to map evenly to the digests, but from what
probability space of functions do you think a hash should
model a random choice? A function limited to message sizes
that are the same as digest size does not meet the
requirements of cryptographic hash.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: crypt()
Date: 18 Jan 2000 02:20:06 GMT
In <[EMAIL PROTECTED]> fishead <[EMAIL PROTECTED]> writes:
>I am trying to take a password and encrypt it on Linux (Slackware 7). I
>have tried using the crypt() function. However, this function generates
>a 13 character string. In my Linux shadow file, the password field is 34
>characters. Is there a function similar to crypt() that I can use to
>encrypt my passwords? I am trying to incorporate this into a C program.
You are almost certainly using the MD5 option that most Linux machines
have. I do not know if there is an equivalent to the crypt(3) library
routine to do the hashine for you, but since Linux includes source code,
it should not be too difficult to whip up a routine.
------------------------------
From: GJJ <[EMAIL PROTECTED]>
Subject: Re: Cracking an ADFGVX cipher
Date: Mon, 17 Jan 2000 18:24:52 -0800
According to Aegean Park Press, Friedman's book "Military Cryptanalysis
Part IV" has the complete solution to ADFGVX ciphers.
Check out: http://www.aegeanparkpress.com/desc.html#C-61
GJJ
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Announce: Puffer 3.10
Date: Tue, 18 Jan 2000 02:33:00 GMT
Due to the relaxation of export restrictions on January 14 by the U.S.
Government, my Puffer program is now available to non-U.S. residents in
its full strength version.
Puffer is a public key, data file and e-mail encryption utility
featuring 128-bit CAST and 160-bit Blowfish block ciphers with 1536-bit
Diffie-Hellman key exchange. File and disk wiping features are also
available.
The shareware version of Puffer is available here:
http://www.briggsoft.com/puffer.htm
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: James Redfern <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Tue, 18 Jan 2000 02:21:48 +0000
Reply-To: James Redfern <redfern[AT]privacyx[DOT]com>
On Tue, 18 Jan 2000 04:32:43, [EMAIL PROTECTED] (Padgett 0sirius)
wrote:
| Electronic Data Interchange or communications with people you know is being
| subhumed into Electronic Commerce. S/Mime v3 is "safe", S/Mime v2 is not.
| Who's on first.
I am deeply grateful for your Cybernetic Psychophysicist take on things. It
all seems much clearer now.
JR.
--
James Redfern <redfern AT privacyx DOT com> The Redfern Organization
PGP key ID 0x8244C43A from <mailto:[EMAIL PROTECTED]?subject=0x8244C43A>
...ActiveNames delivers my undeliverable mail at <www.ActiveNames.com>
------------------------------
** 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
******************************
