Cryptography-Digest Digest #373, Volume #14 Thu, 17 May 01 16:13:01 EDT
Contents:
Re: PGP details (Mark Wooding)
Re: PRNG question from newbie ("Roger Schlafly")
Re: Cryptanalysis Question: Determing The Algorithm? (Bo D�mstedt)
Re: Choosing algorithms (Mark Wooding)
Re: FYI: Results on EM attacks on smart cards (Mike Rosing)
Re: taking your PC in for repair? WARNING: What will they find? (P.Dulles)
Re: PGP details ("Harris Georgiou")
Re: PGP details (Doug Stell)
Re: What about SDD? (Mok-Kong Shen)
Re: Not a realistic thing to do......Why? (James Felling)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: PGP details
Date: 17 May 2001 16:28:15 GMT
Harris Georgiou <[EMAIL PROTECTED]> wrote:
> 1. Why does PGP continues to use CAST as default for encryption while
> it has support for AES? Furthermore, how does the preference list
> work, I mean when and why does PGP chooses to use encryption other
> than the default choice?
Because CAST has been around for ages, and the AES algorithm (Rijndael)
hadn't existed before 1998. Hence, there's been lots more time for
cryptanalysts to poke holes in CAST than in Rijndael.
I think the default cipher probably ought to be triple-DES, but there ye
go.
> 2. Perhaps this applies to signatures in general: using the private
> key for encrypting the SHA1 digest of a message, doesn't this
> increases the risk of key exposure? While public key is available to
> everyone, sending plaintexts (message + well-known digest method)
> along with their ciphertexts, doesn't this weaken the secrecy of the
> private key as well? After all, even 160-bit digests (SHA1) are much
> more easier target for (even brute force) plaintext attacks than the
> (private) key itself.
Yes, but only if the signature algorithm is bad. I read an interesting
paper in the latest Journal of Cryptology in which Don Coppersmith
showed how to break a signature algorithm given the public key and a few
signatures.
Part of your confusion, however, is that you're thinking about signing
in terms of `encryption' with a private key. While RSA and Rabin
systems work like this, most don't, e.g., DSA or ElGamal.
-- [mdw]
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: PRNG question from newbie
Date: Thu, 17 May 2001 15:04:22 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote
> > > Aarrgh. IMO, people should use different terminology if that is what
> > > they mean. The obvious meaning of "secure hash function" is that of
> > > a hash function such that usage as a hash function is secure from
known
> > > attacks. Behaving like a random oracle is a very different and
nebulous
> > > thing.
> > What would you call a primitive whose goal is to behave like a random
> > oracle?
> A pseudorandom oracle?
Ok with me.
> Actually, what's slightly more interesting would be the security
conditions
> such an object would attempt to meet. Here's a first cut: ...
That's a problem with random oracles. It is hard to define what would
be a good instantiation.
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 May 2001 15:42:33 GMT
It is interesting to see that almost any position can be argued,
for or against, and in sci.crypt it often is!
The key point was (B.D.)
> How much can we gain?
(If you cannot gain any, then there is no point.)
There are some equations that must hold for any working cipher.
It is interesting that each of these equations can be hold as an
argument against my proposal, even if no limitation results. Rather,
each limitation clarify the limits of the proposal. (For now,
my proposal is merely a proposal of a possibility.)
Q: (B.D.):
> Can we prevent the cryptanalyst from learning which
> cipher algorithm that we use?
Tom St Denis:
> Typically that's a bad way to look at crypto.
and then
> Obviously you haven't given this some thought.
Typical sci.crypt ... welcome to sci.crypt !!
:)
Tom St Denis:
> You're saying let's not use a fixed known algorithm X to encrypt data.
> Instead let's use algorithm Y that makes other algorithms then use those.
>
> The problem is now algorithm Y is X.
Here, Tom St Denis show us an important point. Even though we
may initially argue for a secret-cipher system X, the public may still
review the system Y. So contrary to the opinion of many readers,
the resulting system will in many ways behave like previous
published cipher algorithms. (But not in all ways.)
Tom St Denis:
> Another problem is that typically we will have a Y that can make bad
> ciphers.
The security issue cannot be clarified at this point, as we are merely
discussing a possibility.
Tom St Denis:
> The best (so far) approach is to put the security in the key and to design
> the cipher as tightly as possible.
In sci.crypt, sometimes we also agree. But note that the "Y" system
will have an ordinary cipher key, so clearly the note applies both to
ciphers of conventional type, and to ciphers of the other type,
that I proposed (that they may exist).
* * *
John Savard have a more constructive approach, and give
several results:
(B.D.)
> This is due to that most conventional block ciphers are iterated
> substitution/transposition ciphers, and what else can possibly exist??
John Savard:
> Even within that restricted domain, allowing the algorithm to be
> modified can increase the effective key immensely.
Normally we associate a security measure with a key or a key length,
it do not apply here. But we all understand his point.
(B.D.)
>Second we must prevent the cryptanalyst from learning which algorithm
>we are using.
John Savard:
> But then you yourself must design the algorithm, and you can only use
> it to send your own messages. So to get a secure algorithm, a very
> large investment of expertise is needed, with a small return.
Again, we note that we currently don't have the material to discuss
security issues. Security issues, and investment sizes, will come
later.
(B.D.)
>We may, however, annoy the cryptanalyst by using several cipher
>algorithms. We may even select cipher algorithms on the fly, possibly
>as a function of the IV (or similar arrangement...).
John Savard:
> Why limit yourself to making the algorithm key-agile in the algorithm?
> Why not _really_ get wild, and make the algorithm used data-dependent?
> (Naturally, you'll need to use the Feistel-round principle so that the
> resulting block cipher is invertible.)
John Savard show us an essential point, that may have been missed
by the causal Reader. In addition to that, there must also be some
equation, that enable decryption of messages. Would John Savard
agree with me, if I would suggest that the "Feistel-round principle"
is merely one way of attaining the equation, that enable decryption ?
(The "essential" part is left as an exercise for the Reader. Note
my clue above: "similar". Read also my previous post.)
* * *
Douglas A. Gwyn is also worried about the equation that
will enable decryption:
Douglas A. Gwyn
> But my point, to which there hasn't been a satisfactory
> response (perhaps because it's correct), is that not only
> the *encryptor* needs to select an algorithm, but also
> the (legitimate) *decryptor* needs to reliably select the
> *same* algorithm.
Very clear and very true.
Douglas A. Gwyn:
> That implies communication of the selection parameters, to be plugged
> into a fixed general system that must (per Kerckhoff) be assumed to be
> known to the enemy.
This is the same void point that Tom St Denis was arguing.
Quoting "(per Kerckhoff)" don't help much, because what was it
that A. Kerckhoffs wrote, really ?
Kerckhoffs, Auguste (1835-1903), Flemish professor,
"La cryptographie militaire", 1883 (ref 1):
> "Il faut qu'il puisse [le syst�me] sans inconv�nient tomber entre
> les mains de l'ennemi" [No inconvenience should occur if
> the system falls into the hands of the enemy.]
We note that this statement don't support the popular belief that
"The enemy knows the algorithm being used".
* * *
Finally we have notes by James Felling. Stubborn and conventional,
he nevertheless manage to give us the final clue on the most important
point, i.e. what the machinery would be good for.
He start like this (James Felling):
> The gain at best of having a set of 2^n possible cyphers to choose from is
> at best 2^n bits. The reasons behind this is that parallell searches can be
> done, each assuming that a given subalgorithim is in use.
We forgive the simple error. "2^n possible cyphers" => n bits.
But when John Savard had a clue, James Felling have none, because,
even if his "2^n" is correct, he have no idea of how large the "n"
will be. So he continues:
(B.D.)
> We may use physical protection means, and zero out
> the algorithm, when a physical attack is detected on a cipher machine.
James Felling:
> Agreed, but we can also assume the opostion can and will get hold of several
> such devices, and will eventually break it -- you cannot assume that it
> remains secure over time.
Here, the time parameter is critical. And manufacturers of FIPS 140-2
level 3-4 approved crypto equipment possibly wish to argue... ...
Anyway, what would the shortest "time" be that you can think of,
dear Reader ?
James Felling continue with:
> However, your recipient also needs to have all the information you
> used available to him, so a break vs. one system could in all probability be
> extended to weaken all other methods.
The above paragraph would be correct only if we assume that the
cipher is a conventional system (the same algorithm for everyone).
James Felling should forgive me for twisting his argument into the
following form:
> However, your recipient also needs to have all the information you
> used available to him, so a break vs. one system couldn't in all probability be
> extended to weaken any other method
... because these methods will be different.
Bo D�mstedt
Chief Cryptographer
Protego Information AB
Ideon Gamma Science Park
SE - 223 70 Lund
SWEDEN
http://www.protego.se/
May 17, 2001
Ref 1: Quote from page 196 in (the excellent)
Prof. Dr. Dr. h. c. mult. Friedrich L. Bauer
"Decrypted Secrets"
Springer Verlag Berlin Heidelberg New York 1997
ISBN 3-540-60418-9
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Choosing algorithms
Date: 17 May 2001 17:09:18 GMT
Panu H�m�l�inen <panuh[@]cs.tut.fi> wrote:
> 1. public-key encryption
I prefer authenticated ephemeral Diffie-Hellman. Failing that, I'd use
half-static Diffie-Hellman to agree symmetric keys.
> 2. secret-key encryption (and encryption mode)
Blowfish, in CBC or counter mode.
> 3. hash calculation
SHA-256.
> 4. digital signing
DSA, 2048-bit p, 256-bit q, with SHA-256 as a hash.
> 5. MAC calculation
HMAC with RIPEMD-160.
Actually, these questions raised an awkward problem. I don't actually
have a hash algorithm with a 256-bit output that I really trust. Sigh.
-- [mdw]
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: FYI: Results on EM attacks on smart cards
Date: Thu, 17 May 2001 12:30:14 -0500
"Josyula R. Rao" wrote:
>
> Mike,
>
> Thanks for your comments. We will label the graphs so that they are
> intelligible to people not working in the area.
>
> About your questions and suggestions: everything is fair game at this point.
> We do have other results but as you can appreciate, disclosure can only be
> done in a responsible manner.
I'm looking forward to future results. Good luck!
Patience, persistence, truth,
Dr. mike
------------------------------
From: P.Dulles <*@*.com>
Crossposted-To:
alt.privacy,alt.security.pgp,alt.security.scramdisk,alt.privacy.anon-server
Subject: Re: taking your PC in for repair? WARNING: What will they find?
Date: Thu, 17 May 2001 13:32:53 -0400
Reply-To: *@*.com
In article <9e0sdg$kn8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>:
>: "Ken D." <[EMAIL PROTECTED]> wrote in message
>: news:[EMAIL PROTECTED]...
>: > Omnivore wrote:
>: > >
>: > > They may find Evidence Eliminator and alert the authorities that one
>: bears
>: > > keeping an eye on.
>: >
>: > how's this for a delightful conspiricy:
>: >
>: > EE is being spammed around *by* the authorities.
>: > they know its so weak, they want folks to use it :)
>: >
>: > EE, the one most recommended by civil serpents!
>: > buy now!
>:
>: Hell - For all we know it could mail in incriminating stuff to whoever
>: one would least want to have it.
I really think both these ideas are borderline absurd. I suppose it's
possible, but my firewall NEVER tells me that EE is sending anything
out. My contacts in the computer crime lab tell me that except for me,
they have never even heard of the program.
I'd really prefer we keep the queries to EE as factual as possible,
instead of mere speculation. Otherwise, it provides them more
ammunition to use this group on their "dis-information" page - which I'd
really like to see contain my very direct questions and their responses;
but of course they refuse to respond.
Let's try to be fair. They aren't, this just further substantiates and
strengthens our argument.
--
Loki
"Joan of Arc heard voices too!"
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: PGP details
Date: Thu, 17 May 2001 20:38:59 +0300
� Mark Wooding <[EMAIL PROTECTED]> ������ ��� ������ ���������:
[EMAIL PROTECTED]
> Harris Georgiou <[EMAIL PROTECTED]> wrote:
>
> > 1. Why does PGP continues to use CAST as default for encryption while
> > ........
>
> Because CAST has been around for ages, and the AES algorithm (Rijndael)
> hadn't existed before 1998. Hence, there's been lots more time for
> cryptanalysts to poke holes in CAST than in Rijndael.
>
> I think the default cipher probably ought to be triple-DES, but there ye
> go.
In the key properties the "Cipher" field reports the algo that WAS default
when the key was created. Does this mean that this particular key works only
with this cipher (i.e. CAST), even if my current preference is TripleDES or
AES? And if so, can I modify this key setting in PGP?
>
> > 2. Perhaps this applies to signatures in general: using the private
> > ........
>
> Yes, but only if the signature algorithm is bad. I read an interesting
> paper in the latest Journal of Cryptology in which Don Coppersmith
> showed how to break a signature algorithm given the public key and a few
> signatures.
>
> Part of your confusion, however, is that you're thinking about signing
> in terms of `encryption' with a private key. While RSA and Rabin
> systems work like this, most don't, e.g., DSA or ElGamal.
>
That's true. I was referring to RSA signatures used by PGP. As I understand,
PGP uses SHA1 digest + encryption with private key for signatures, which is
the real problem in the first place. I cannot understand if and how the
private key is protected under this type of attack. Furthermore, what's the
relation/usage of subkeys with session keys used for normal message
encryption (totally useless for signatures right)?
--
Harris
- 'Malo e lelei ki he pongipongi!'
> -- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: PGP details
Date: Thu, 17 May 2001 19:15:12 GMT
On 17 May 2001 16:28:15 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote:
>Harris Georgiou <[EMAIL PROTECTED]> wrote:
>
>> 1. Why does PGP continues to use CAST as default for encryption while
>> it has support for AES? Furthermore, how does the preference list
>> work, I mean when and why does PGP chooses to use encryption other
>> than the default choice?
The preference list really has to do with the guy at the other end of
the pipe. If you both have algorithms that you are willing or
unwilling to use, it is clear that you must agree to use some mutually
acceptable algorithm. The default algorithm is the one you would
prefer to use.
You might want to look at some protocols that have developed this to a
high degree. These often work on the exchange of prioritized lists of
algorithms or algorithm-suites, with an algorithm that guarantees that
both ends pick the same algorithm or suite.
>Because CAST has been around for ages, and the AES algorithm (Rijndael)
>hadn't existed before 1998. Hence, there's been lots more time for
>cryptanalysts to poke holes in CAST than in Rijndael.
CAST is also free of patent issues and is based on good design
principles derived from respected algorithms, such as DES and IDEA.
The AES choice has only recently been made. In a few years, it will
likely be the default. It also takes time for an algorithm to become
trusted and to become widely deployed.
>I think the default cipher probably ought to be triple-DES, but there ye
>go.
There are people who believe that triple-DES has no real reason to
exist, unless you need to use existing hardware, as is the case in the
financial industry. Others trust DES as the foundation of triple-DES,
because it is familiar and has been proven trustworthy over its long
life. If you are not in either of those categorites, CAST is an
obvious good choice and AES would be a good future choice. BTW, there
is certainly nothing wrong with being in any of the above three
categories. I know of products that chose to use triple-DES only
because its familiarity would be better accepted by the potential
marketplace. The cryptographers and developers of the product would
have made a different choice.
The same concept of familarity is also true of the choice of RSA for
both signature and key transport, versus ElGamal for key transport and
DSA for signature. Actually, PGP calls ElGamal Diffie-Hellman, because
D-H is more familiar. I know people in academia that prefer the
familiar RSA, while cryptographers would prefer the other choice.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What about SDD?
Date: Thu, 17 May 2001 21:32:39 +0200
Harris Georgiou wrote:
>
> People use some encryption algo to prevent access to sensitive information.
> Some use stego to hide even the existance of the ciphertext. But encryption
> and steganography seem to have more differences than similarities.
> Encryption uses well-known methods for creating the ciphertext, the security
> of which is based directly on the difficulties accessing or guessing the
> key. On the other hand, steganography uses "simple" techniques for merging
> data into a carrier signal, but the security here is based more on the
> secrecy of the technique itself rather than a secret key.
>
> But how about sparse data distribution techniques? I mean why can't we use a
> method that dynamically spreads the data into a vast pool of white noise? If
> we choose the pool size correctly and use a good PRNG, statistical methods
> for detecting changes (T-test and F-test with maximum sensitivity) in
> distribution are useless, while using a RLE-like table as a user key (say
> 4096-bit => 512-byte RLE offsets) ensures that even if the method is
> well-known none will try to guess this key by chance. If my numbers are ok,
> using random values of size: 2^(k+2) times the size of the actual data, is
> sufficient for this even of all actual data are equal (say zeros). In a
> sense, the principle is the same as the broad-spectrum comms used by the
> military: the opponent knows the existance of the message but the retrieval
> is extremely difficult.
>
> Of course the SDD method is not for massive message exchange - my guess is
> that it could be used effectively in combination with encryption for secure
> key storage, to deny even the retrieval of the ciphertext (before any
> cryptanalysis is attempted).
> I think it's much more difficult to try and break a 1K ciphertext if it is
> burried into 650M of junk in a CD.
>
> PS: Are there any freeware programs like Steganos (Win98/Unix) using SDD
> techniques instead of stego?
"Dynamically spreads the data into a vast pool of
white noise" is not steganography but encryption, I
suppose (since the opponent sees meaningless stuffs
and knows that these are not innocent). If bandwidth
isn't a problem, one can in fact thus embed information
bits into a stream of dummy bits using a PRNG. (One of
my humble designs is based on this.)
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Not a realistic thing to do......Why?
Date: Thu, 17 May 2001 14:34:27 -0500
Whoops. I forgot a smiley on my post. Sorry.
John Savard wrote:
> On Wed, 16 May 2001 13:05:39 -0500, James Felling
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Might make a good hash though.
>
> From the description, however, it's a way to split a document into
> three pieces - so it probably isn't deterministic. (i.e., two pieces
> are random, the third piece is the other two pieces XOR the plaintext,
> then encrypted or something like that)
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
