Cryptography-Digest Digest #420, Volume #10 Sat, 16 Oct 99 17:13:03 EDT
Contents:
Re: PHT ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: looking for elliptic curve primer (DJohn37050)
Re: where to put the trust
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Re: Announcement: Easy DES Encryption for Windows (Cedomir Igaly)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Re: On Moduli that are Vulnerable to Factoring ("Stush")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Roger
Schlafly")
Re: Which encryption for jpeg compressed pictures? (David A Molnar)
Re: He is back...new "improved" code (Lincoln Yeoh)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
newbie - encrypted cookies ([EMAIL PROTECTED])
Re: How many prime numbers? (jerome)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (David A
Molnar)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (David A
Molnar)
Re: 3DES/PGP (Jerry Coffin)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Roger
Schlafly")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PHT
Date: Sat, 16 Oct 1999 10:50:17 GMT
In article <[EMAIL PROTECTED]>,
James Felling <[EMAIL PROTECTED]> wrote:
> Doesn't twofish use a PHT mixing step as well?
Yes. TwoFish uses the PHT to combine the outputs of each H function to
create the two outputs of the G function. I think I remember one other
cipher outside of TwoFish and the SAFER family that uses a PHT, but I
can't remember which one.
csybrandy
>
> John Savard wrote:
>
> > Wojciech Laskowski <[EMAIL PROTECTED]> wrote, in part:
> >
> > >Who tell me something about Pseudo-Hadamard Transform? I need know
basic
> > >of PHT. Maybe somebody knows any reference to this subject?
> >
> > It's not something complicated.
> >
> > Take x and y. The Pseudo-Hadamard Transform of (x,y) is (x+y, x+2y).
> > It's just meant to combine the two numbers in a way that looks a bit
> > like a real transform. It's only used in the block cipher SAFER as
far
> > as I know.
> >
> > John Savard ( teneerf<- )
> > http://www.ecn.ab.ca/~jsavard/crypto.htm
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 16 Oct 1999 07:49:22 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Roger Schlafly wrote:
> <[EMAIL PROTECTED]> wrote in message news:7u7fn4$l5o$[EMAIL PROTECTED]...
> > Much of this thread has been about cascading ciphers as a way to
> > increase security. What I find interesting is that only a few months
> > ago many in this newsgroup thought that this is a bad idea.
>
> Many still think it is a bad idea. If a cipher has shortcomings,
> it is better to fix the cipher than to pile other ciphers on top
> of it.
By this you mean ciphers with known shortcomings. How do you propose to handle
the ciphers that might have unknown shortcomings? BTW, that would be all of
them.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: looking for elliptic curve primer
Date: 16 Oct 1999 14:21:48 GMT
Another place is www.nist.gov/encryption go to section on NIST recommended
curves and also follow hotlink to paper on ECDSA, written by Alfred Menezes and
myself.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: where to put the trust
Date: 16 Oct 99 15:15:49 GMT
[EMAIL PROTECTED] wrote:
: A three-level cipher is a special case of a cipher.
: Three-level ciphers have no more provable security
: than single ciphers.
This is true, but it is not the point.
: The per-message change makes the problem worse. It
: leaves a lower chance of exposing everything, but
: a higher chance of exposing something. This is
: worse because of the diminishing returns to the
: attacker - the first one percent is much more
: valuable than the last few percent.
That is a correct objection to the use of multiple ciphers by itself. The
use of three-level multiple encipherment, with independent keys, can
essentially solve this problem, if done properly. The requirment for this
is that we must ensure:
- at least one of the three ciphers used is from a small set of ciphers
which, on the basis of *conventional* criteria of having been properly
studied and analyzed, could have been trusted with all one's messages, had
one not opted for multiciphering,
- the specific choice of ciphers used for a message must be itself
conveyed by highly secure encryption, and chosen by good random methods;
it must be considered an essential part of the session key.
If these points are stressed, I think that multiple encipherment can be
placed on a sound footing, with the choice of ciphers from a large pool
genuinely making analysis much more difficult without introducing other
weaknesses.
: I do agree we have too few ciphers and need more,
: specifically we need more _public_ key ciphers.
: We have scores of secret-key ciphers and new ones
: are easy to design. I suspect the sci.crypt
: obsession with symmetric ciphers is precisely
: because they are so easy to build.
Well, designing a new public-key cipher is essentially making a new
discovery in advanced mathematics. I'm not surprised it is hard to find
many people who can do this, or that this doesn't happen very often. I
don't think encouraging the participants in sci.crypt to think about
public-key cryptography is going to result in new public-key ciphers being
discovered any more quickly.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 99 15:19:12 GMT
Roger Schlafly ([EMAIL PROTECTED]) wrote:
: <[EMAIL PROTECTED]> wrote in message news:7u7fn4$l5o$[EMAIL PROTECTED]...
: > Much of this thread has been about cascading ciphers as a way to
: > increase security. What I find interesting is that only a few months
: > ago many in this newsgroup thought that this is a bad idea.
: Many still think it is a bad idea. If a cipher has shortcomings,
: it is better to fix the cipher than to pile other ciphers on top
: of it.
But the point - and it's a valid one - of the side other than yours on
this question is that sometimes we don't *know* all the shortcomings of a
cipher. So, if we pile up several _very different_ ciphers, we do have an
additional degree of reassurance.
I agree it is a lesser degree than the one we get from a long period of
study and analysis by the academic community, however. But I think it is a
valid point that we need all the reassurance we can get - because all we
can get still isn't enough.
John Savard
------------------------------
From: Cedomir Igaly <[EMAIL PROTECTED]>
Subject: Re: Announcement: Easy DES Encryption for Windows
Date: Sat, 16 Oct 1999 16:49:57 +0100
Steve Preston wrote:
> Easycrypt offers point and click encryption, utilising the trusted and
> robust DES algorithm. The product includes many optional features,
... and what is more important - your data will be protected with full 56
bits of secret key :-(
BTW, it will be good idea to bundle your product with some book like
"Cracking DES".
Regards, C.I.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 99 16:13:13 GMT
DJohn37050 ([EMAIL PROTECTED]) wrote:
: Roger, In fact there are multiple fax transmission protocols, each vendor came
: up with one and then cross licensed with others. But at first each fax would
: only talk to another from the same vendor (for example). Fax machines now do a
: negotiation.
Yes, but they don't negotiate which of the many incompatible digital fax
protocols that predated the Group III standard to use. Instead, they
follow the Group III standard, which specifies a single protocol, and
negotiate the resolution to use and the baud rate. There are proprietary
add-ons to the Group III standard on some modern fax machines, but they're
designed to fit within the Group III environment, and they're not old
protocols retained from earlier times.
John Savard
------------------------------
From: "Stush" <[EMAIL PROTECTED]>
Subject: Re: On Moduli that are Vulnerable to Factoring
Date: Sat, 16 Oct 1999 12:38:12 -0400
Ted Kaliszewski wrote in message ...
> 3. All of the cases considered will factor readily via the
>algorithm implementing the so-called false ufm theory ( false, since
>we use composite moduli rather than primes in the computations).
What is ufm theory?
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 09:07:02 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Triple DES standard doesn't burden those that use single DES,
> as far as I am aware.
Sure it does -- they don't interoperate.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,comp.graphics.algorithms,comp.compression
Subject: Re: Which encryption for jpeg compressed pictures?
Date: 16 Oct 1999 16:37:26 GMT
In sci.crypt John Savard <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Herbert Kleebauer) wrote,
> in part:
>>1. absolutely secure. If you have the original and the
>> encrypted file, it must be impossible to proof, if
>> one is the encrypted version of the other.
> I wonder why that particular criterion came to mind?
speculation :
It sounds a bit like the Goldwasser-Micali notion of security -- also
known as "polynomial indistinguishability." Unfortunately, this notion is
formed for public-key systems; I don't know of anyone who's tried to apply
it to symmetric ciphers.
Informally, it goes like this : a probabilistic polynomial time adversary
is given an encrypted message. He's told that it's the encryption of
either plaintext 1 or plaintext 2, where both plaintexts are known to him.
He also has the public key, so he can encrypt whichever messages he wants,
including those two plaintexts.
Challenge : which plaintext was encrypted?
A cryptosystem is said to be "GM-secure" iff the adversary can't tell
which plaintext corresponds to the given ciphertext with more than a
"negligible" probability. Guessing the secret key is something which
counts as a "negligible" probability -- although as Douglas Gwyn has
pointed out in this thread, it allows you to get theanswer almost all
the time.
Note that the encryption has to be probabilistic in this sense :
encrypting the same message twice *must* give two different ciphertexts.
Otherwise you just encrypt each of the given plaintexts and compare.
So _assuming the adversary doesn't get your secret key_, a GM-secure
system seems like it would work : given the original image, and given the
encrypted image, no poly-time limited person can prove that they
correspond.
Except that if we're talking about the FBI raiding your home and seizing
your HD, it's pretty likely that they'll get all or part of your secret
key. So you need a system where decryption is "ambiguous" in some
sense...and I don't know how to do that.
-David
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: He is back...new "improved" code
Date: Sat, 16 Oct 1999 17:21:09 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 15 Oct 1999 16:43:42 GMT, [EMAIL PROTECTED] (Dan Day) wrote:
>On Fri, 15 Oct 1999 06:48:36 -0500, "Dan Fogelberg" <[EMAIL PROTECTED]>
>wrote:
>
>>Well he won't give it to me, so I am stuck I guess.
>
>That's why I suggested that you show him how a real-world adversary
>would attack his system, and steal his program off of his computer
>when he's not looking...
>
>A *truly* professional, "unbreakable" encryption system would
>still be secure even after you stole the program, since you still
>wouldn't have the key he used to encrypt the challenge message.
But if you can steal his program off his computer, it is very likely that
you can also steal the key off his computer.
If that is possible I see little difference between using a crappy obscure
encryption system and a truly professional unbreakable encryption system.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 19:35:43 +0200
Roger Schlafly wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote
> > Triple DES standard doesn't burden those that use single DES,
> > as far as I am aware.
>
> Sure it does -- they don't interoperate.
People that use triple DES don't use single DES and vice versa.
So there is no need of inperoperability. I was answering your
point (if I understood correctly) that having an additional
standard like triple DES leads to disadvantages of those who
use DES. There aren't any such arising from the mere fact that a
separate standard exists. (In other follow-ups I employed the
analogy in the field of programming languages.)
I like to take this opportunity also to repeat (wrpt what is discussed
elsewhere in this thread) that on the day when AES is finalized
all top candidates are likely to have received the same degree/amount
of scrutiny by the best of professionals. So the chance of using
multiple encryption of these leading to weakness (relative to
single encryption with the winner of AES) is negligibly small or
practically zero. The single disadvantage may be in performance,
which could be tolerated in at least a part of the practical
applications. I personally consider it to be a naive idea to
consider one single cipher (one that doesn't yet have gone through
the test of time as DES has done) to be so extremely good that one
never needs to bother about its possible vulnerability. To those who
are SO SURE about modern (super) high technology being able to
absulutely guarantee all their needs (whether crypto or not) I like
to recall one single name: Titanic.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: newbie - encrypted cookies
Date: Sat, 16 Oct 1999 17:38:15 GMT
This is an applied cryptography question from someone who knows very
little about cryptography.
I'm a web programmer. I'm looking for a cipher I can use to encrypt
cookies that I will store on a web surfer's machine. My guess is that
I want to use the same key to encrypt and decrypt the messages. Any
advice on which algorithm I should use? I'd like to implement the code
in perl.
Thanks,
Tait
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: How many prime numbers?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Oct 1999 18:00:19 GMT
On Fri, 15 Oct 1999 22:27:50 GMT, jerome wrote:
>On Fri, 15 Oct 1999 19:57:38 GMT, Tim Tyler wrote:
>>
>>The log formula was long though to be an overestimate - but it was
>>subsequently discovered that it dipped beneath the actual frequency of the
>>primes at some large figure - I presume this point was the one being
>>referred to.
>>
>
>i think i have seen a reference explaining that it goes above
>and below the actual number an infinite number of time.
>in memory serves it has been prooved.
>
>i will check if i can find where i read that. just to be sure
>i don't "dream"
i didn't. In 1914, Littlewood prooved it. In 1955, Skewes (spelling?)
prooved that the first sign change of li(x)-pi(x) is for
x < 2^(10^(10^(10^3))) (the number is from memory. maybe i forgot a power
of 10 :)
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 1999 17:30:59 GMT
Peter Galbavy <[EMAIL PROTECTED]> wrote:
> chosen - but is there a mandatory surrender of those rights required
> to complete ? (Kudos to those who are entering non-IPR laden entries).
Not to compete, but the winner must be freely available to all in the same
fashion as DES and DSA are.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 1999 17:44:34 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> The use of *keys* limits interoperability -- to those who have the
> right keys. We now do arrange to transfer keys as needed. We could
> arrange to transfer the name of the cipher to be used, or even the
> cipher itself.
You (or anyone else reading) may want to look at this master's thesis on
"Self-Describing Cryptography" :
http://ben.adida.net/thesis/
which covers exactly the problem of transferring the description of a
cipher along with the message it's going to decrypt. Part of the thesis is
a sample implementation in Java. I can't find the actual code up on the
site, but presumably one could ask the author for more details.
thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: 3DES/PGP
Date: Sat, 16 Oct 1999 12:41:41 -0600
In article <7u9a57$fa5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Can someone tell me which is the stronger form of encryption - 128 bit PGP
> or 168 bit 3 key Triple des ?
I'm guessing that when you say "128 bit PGP" you mean IDEA. If that's
so, then I doubt anybody can really tell you for sure. 3DES, when
properly implemented, has an effective key-size of 112 bits. It's
entirely unreasonable to attempt an attack on either one without
finding some method of reducing the key-space that needs to be
searched by a fairly large margin. As is pretty well known, a number
of attacks on DES have been devised, but at the present time, none of
them is particularly practical.
A few parts of IDEA have been found that may be less than ideal as
well, but TTBOMK nobody's found a real attack based on any of them
yet.
IOW, if there's anything approaching a feasible attack on either one,
whoever knows about it is apparently keeping it a secret. Of course,
in the case of a complete cryptosystem (such as PGP) there may be
attacks that don't depend on weaknesses in the core algorithm. I
haven't examined the PGP source code in _extreme_ detail, but from
what I've seen, it looks like it's pretty carefully written to avoid
most problems. If you're comparing PGP to some other product that
uses algorithms of a similar caliber, things like key generation, key
management, etc., are more likely to cause problems than the
algorithms themselves (assuming the algorithms are correctly
implemented).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 16 Oct 1999 11:08:08 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Roger Schlafly wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote
> > > Triple DES standard doesn't burden those that use single DES,
> > > as far as I am aware.
> >
> > Sure it does -- they don't interoperate.
>
> People that use triple DES don't use single DES and vice versa.
Exactly. No interoperability.
> To those who
> are SO SURE about modern (super) high technology being able to
> absulutely guarantee all their needs (whether crypto or not) I like
> to recall one single name: Titanic.
Yes, that's what iterated ciphers are. Big, slow, clumsy, and
misplaced confidence in something just because it is big, slow,
and clumsy.
------------------------------
** 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
******************************
