Cryptography-Digest Digest #911, Volume #13 Fri, 16 Mar 01 04:13:00 EST
Contents:
Re: PGP "flaw" (Paul Crowley)
Re: SSL secured servers and TEMPEST (Mark Currie)
Re: SSL secured servers and TEMPEST (Paul Rubin)
Re: qrpff-New DVD decryption code (Matthias Bruestle)
Re: SSL secured servers and TEMPEST (Frank Gerlach)
Re: SSL secured servers and TEMPEST (Frank Gerlach)
Re: Computing power in the world (Paul Schlyter)
Re: primes for Blum Blum Shub generator (Risto Kuusela)
Re: What do we mean when we say a cipher is broken? (Was Art of Cryptography)
(John Savard)
Re: Super strong crypto (John Savard)
Re: The Art of Cryptography (was: Super strong crypto) (John Savard)
Re: What do we mean when we say a cipher is broken? (Was Art of (Mok-Kong Shen)
Re: Super strong crypto (Mok-Kong Shen)
Re: How to eliminate redondancy? (Mok-Kong Shen)
Re: What do we mean when we say a cipher is broken? (Was Art of (Mok-Kong Shen)
----------------------------------------------------------------------------
Subject: Re: PGP "flaw"
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2001 06:32:46 GMT
Here's an extract from an article by my CryptoLabs colleague Ruediger
Weis on the flaw, with some editing by me:
PGP Bugs and Features
On 23 August 2000, Ralf Senderek announced a serious security bug in
all newer versions of PGP (>= 5.5). It was the biggest security bug
ever to be found in this most trusted of encryption programs. This
disaster highlights the need to take a closer look at the
metamorphosis of PGP into a commercial product.
What is the ADK?
================
PGP uses a hybrid encryption scheme. The message is encrypted using a
symmetric cipher (IDEA appears in all versions; version 5.0 added
support for CAST and Triple-DES) with a pseudo-randomly generated
session key. Then this session key is encrypted using the public key
of the intended recipient.
Version 5.5 of PGP added the Additional Decryption Key (ADK)
capability. Your public key can now carry a tag indicating that when
a message is encrypted for you, the session key should also be
encrypted with another public key that accompanies yours, and both
encrypted session keys should accompany the encrypted message. This
means that when a message is encrypted for you, the other party that
you specify can also read these messages.
The usual excuse for this feature is that a company may need the
ability to decrypt messages intended for an employee if, say his
private key is eaten by a dog, or if the employee is squashed by a
truck. But cryptologist Bruce Schneier warned that the ADK feature
was "a stupid idea", adding "but that's the sort of thing key escrow
demands".
Bug or business feature?
========================
Ever since its introduction, cryptographers have warned that such
"backdoor" constructions will provide fertile ground for security
problems. It now seems that when implementing the feature, NAI made a
beginner's mistake. The original intention was that you would sign
the ADK field of your public key with your own private key, to certify
that you consented to these other individuals having the power to read
messages intended for you. However, Senderek discovered that PGP did
not properly check that the ADK field was in fact signed by the
appropriate public key. The upshot is that you can take Alice's
public key, add an ADK field which directs messages to you, and pass
it on to Bob; when Bob encrypts a message to Alice, you will be able
to read it too, and Bob will get no warning that Alice did not mean
you to be able to read her messages.
Recent versions of PGP fix this problem, and NAI have downplayed it.
The president of the PGP security unit claimed "This is a fairly
estoric attack". However, Stefan Lucks and Ruediger Weis noticed that
this "estoric" bug can also been seen as a business feature. A
company may want to add an ADK field to the public keys of any of
their employees. If ADK is implemented as specified, each employee
would have to sign the ADK field with their private keys, which could
be a considerable administrative and political overhead. But with the
bug Senderek discovered, the company can add the ADK to anyone's keys
without even discussing it.
Time for GnuPG
==============
At the moment, only new-style "Diffie-Hellman" (more exactly ElGamal)
keys have suffered the ADK problem. But it is rumoured that NAI will
add support for ADK on RSA keys in the fortcoming version 7.0.
It's worth remembering that NAI's goal in owning PGP is to make money
with it. To this end they may integrate all sorts of fancy features,
some interesting, some useless, some even dangerous. For example, PGP
now allows you to create Self-Decrypting archives; these are
.exe files which when executed, prompt the user for a passphrase
before unpacking the contents of the archive. Yet it's hard to
imagine the circumstances where unpacking such a self-decrypting
archive by executing it would be a good idea. Infuriatingly, other
features such as full compatibility with the new PGP standard,
OpenPGP, seem to be less important to NAI.
The solution to these problems is an alternative PGP implementation:
the GNU Privacy Guard (GPG; http://www.gnupg.org/), licensed under the
GPL. It supports the OpenPGP standard (RFC2440), and now offers full
support for RSA as well as ElGamal keys; this feature was added only
days after the patent expired. The IDEA algorithm used in older
versions of PGP is still patented; a plug-in exists to add IDEA
support to GPG.
Public keys specified using ElGamal ("Diffie-Hellman"), DSA and
Triple-DES are usable in both GPG and PGP5.0ff. Triple-DES is slow
and boring, but 48 rounds of the DES round function should be enough
for anyone.
And GPG will soon offer a security feature that PGP users will envy:
GPL software that allows you to store your encrypted private key on a
tamper-resistant Java-based smart card that you can carry with you
everywhere. Stay tuned!
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
Temporary address (due to email problems): [EMAIL PROTECTED]
------------------------------
Subject: Re: SSL secured servers and TEMPEST
From: [EMAIL PROTECTED] (Mark Currie)
Date: 16 Mar 2001 06:50:31 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
<snip>
>
>The one FIPS 140-1 level 4 module that I know anything about (IBM 4758)
>went to serious lengths to avoid leaking any data through EM emissions.
>
>> Where your coming from is - can you completely hide emmissions ? No
>> you can't, but for an outside attacker to exploit the emmissions
>> that you are talking about you would probably need to have the
>> resources that only government agencies may have. Commercial
>> security can only hope to follow government security due to
>> available resources and budget.
>
>I'd tend to think any emissions monitoring the government can do,
>anyone else can also do.
Weeelll, any idiot can sit in a van and switch the record button on, given
that the equipment is set up. Can anybody extract the key from the results ?
Depending on how many db's down we are talking about, I doubt it.
>
>> Commercial security vendors can only charge so much for their
>> products.
>
>But I know from experience that they can charge an awful lot ;-)
Compare the prices of some commercial software programs that took a few young
Java programmers a couple of months to put together to the IBM module you
mention above. I would imagine that the module not only took longer and
required highly skilled and experienced developers, it probably also contains
IP that has taken years to develop.
Mark
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: 15 Mar 2001 23:16:24 -0800
[EMAIL PROTECTED] (Mark Currie) writes:
> >But I know from experience that they can charge an awful lot ;-)
>
> Compare the prices of some commercial software programs that took a
> few young Java programmers a couple of months to put together to the
> IBM module you mention above. I would imagine that the module not
> only took longer and required highly skilled and experienced
> developers, it probably also contains IP that has taken years to
> develop.
Actually the IBM module is an amazing piece of hardware and quite a
bargain. Other, less sophisticated modules cost a lot more.
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: qrpff-New DVD decryption code
Date: Thu, 15 Mar 2001 23:36:57 GMT
Mahlzeit
Joe H. Acker ([EMAIL PROTECTED]) wrote:
> Matthias Bruestle <[EMAIL PROTECTED]> wrote:
> > Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> > > Matthias Bruestle wrote:
> > How do you define moral or ethics? If it is what most people do,
> > than copying of music is probably not theft.
> My God! It is *of course NOT* what most people do! As a German like you,
> I hate to bring this example, but do you believe that in the 3rd Reich
> in Nazi German what most people did was moral or ethical behavior?
> Certainly not! What the majority does or thinks can never be taken as an
> argument for or against moral judgements.
Probably most people in Nazi Germany thought is was ethical and probably
most people outside thought is was not ethical. Most people probably think
now, that sex before marriage is ethical, but this was certainly not
always so. Who is right and who is wrong and why?
> > If a minority is
> > enough to define morale/ethics, which minority will that be?
> Morale/ethics is not defined, it is found and explored.
By whom?
> Look, it's not a good base for laws or ethics, but in this case even
> your own moral judgement might help: If you invent something ingenious
> that would make you rich (say, an unbreakable cipher or the best
> pop-song ever), and if sombody takes it away from you. Wouldn't you
> think that this is theft?
"Intellectual Property" (which is a rather broad area to be named with
a single term) can not really be taken away. If you find a suitecase
on the street, you wonder "whos suitecase is this?" If you have an idea
while showering, you most certainly do not ask you "do I steal someones
intellectual property by using my idea?"
> I don't know what your profession is, but if you would work as a book
> author, journalist, photographer, artist or the like, you certainly
> would not claim that it's okay to steal your work and spread it for
> free.
If I get paid to write software or articles the person who paid me
can decide what to do with it and I'm happy, if he decides to spread it
for free. If I do not get paid for writing a piece if software or an
article it is free software/text and I allow other people to get rich
with it by placing it under BSD2 license.
> Nobody arrests a student who copies a book he has taken out of a
> library, because it is so expensive.
If he only copies parts of it, it is not even illegal.
> Digital copy protection does not work and just gets on the nerves of
> honest buyers, that's why its bad.
And because it makes impossible to do things people are allowed to do.
> Not because everybody should steal
> the work of artists and other creatives who most often have a hard
> enough time to make a living anyway.
And not every copying is stealing. If I buy an Audio CD-R¸ of which
I think about US$ 1 goes to the musics industry, and copy music of
this industry onto it, do you think this is stealing? If the musics
industry makes it impossible to copy music onto this CD-R, do you think
this is stealing?
> Okay, enough OT talk.
Ok. Last posting from me.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
'If you want a picture of the future, imagine a boot stamping on a human
face - forever. And remember that it is forever' (Orwell, 1984)
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: Fri, 16 Mar 2001 08:56:21 +0100
Paul Rubin wrote:
> The one FIPS 140-1 level 4 module that I know anything about (IBM 4758)
> went to serious lengths to avoid leaking any data through EM emissions.
Could you please explain how FIPS 140-1 level 4 does adress TEMPEST ? It
adresses EMI/EMC, which is of course a precondition for good shielding,
but it is in no way sufficient.
Maybe you can quote the 140-1 section on defending against
eavesdropping. From what I have read, it says absolutely nothing about
that.
The NSA lost their edge on crypto, do you seriously think they want to
loose their siginit advantage ?
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: Fri, 16 Mar 2001 09:12:20 +0100
Lyalc wrote:
>
> Look at the cryptome site, where copies of the released portions of the
> TEMPEST standards, NACSEM 5100 et al reside.
> Not much useful material.
>
> Minimum idea is that the signal needs to be above the noise floor in it's
> bandwdith required for detection.
As I tried to outline in previous postings, the "plaintext signal" can
be well below the noise floor, if it is transmitted multiple times. With
CRT signals and SSL private keys we have exactly this situation.
Being below the noise floor helps against amateurs, but not against the
determined organization willing to use a huge directional antenna and a
truck full of recorders to record everything 0..2GHz for a couple of
days. After recording everything, they will then spent some tera-flop
years doing signal processing on the recorded signals.
I bet you can increase the useful recording distance with this method
from a couple of meters to a mile or so.
I agree that this is a very sophisticated attack, but I consider it
important to be aware of what is possible at maximum effort.
Taking into account how much money Uncle Sam spent for ridiculous
operations like digging tunnels, pulling subs from deep sea levels and
so on, I would not rule out that they do some kind of recording similar
to what I described above against targets, which allow them to savely
place the "trucks" (e.g nato allies, embassies etc).
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Computing power in the world
Date: 16 Mar 2001 08:12:46 +0100
In article <[EMAIL PROTECTED]>, Darren New <[EMAIL PROTECTED]> wrote:
>> What is the up-to-date estimate of the total computing power in the world
>> in mips-years?
>
> mips-years would be mips * years, right? That doesn't sound like a useful
> measurement.
>
> MIPS by itself is the number of instructions you can execute in a given
> length of time. What does multiplying it by years get you?
1 MIP = 1 million instructions per second
1 MIP-year = numer of seconds in a year * 1 million instructions
Thus:
1 MIP-year = 31556952000000 instructions = ca 3.15E+13 instructions
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Risto Kuusela <[EMAIL PROTECTED]>
Subject: Re: primes for Blum Blum Shub generator
Date: Fri, 16 Mar 2001 08:30:01 GMT
Tom St Denis wrote:
> BBS is only (provably) secure when the primes are secret. Otherwise there
> is not much of a point.
Not quite so. It is only proven that ability to predict BBS will
imply ability to factor BBS modulus, but it is not known if the
converse is true. So according to present knowledge primes don't
have to secret, only "seed" value x (unless I have missed some
recent results).
Risto
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: What do we mean when we say a cipher is broken? (Was Art of
Cryptography)
Date: Fri, 16 Mar 2001 07:59:51 GMT
On Fri, 16 Mar 2001 02:03:13 GMT, William Hugh Murray
<[EMAIL PROTECTED]> wrote, in part:
>Because vengeance is hard to measure and crypto is cheap, I use it in such a way as
>to raise the cost of attack several orders of magnitude higher than the value of
>success.
Since some of us do not really have vengeance as an option, and since
crypto is cheap, it makes sense to use enough crypto so that one won't
be faced with the need to avenge a break.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Super strong crypto
Date: Fri, 16 Mar 2001 08:06:51 GMT
On 23 Feb 2001 04:18:34 GMT, [EMAIL PROTECTED] (David Wagner)
wrote, in part:
>After all, when Biham and Shamir wrote about differential cryptanalysis
>of DES, they also noted that even changing the key very frequently does
>not add much security against their attack. See ``Differential cryptanalysis
>of the full 16-round DES'', where they say that even if you change keys
>once every 2^14 blocks, the attacker can still recover his first key after
>2^47 chosen plaintexts (the same as if the key had never changed). This
>means that, if we instantiated Gwyn's proposal with DES and with key changes
>every 2^14 blocks, Gwyn's proposal wouldn't provide any improvement in
>security against differential cryptanalysis.
This certainly is an interesting and relevant result.
For changing keys once every 2^14 blocks, and yet being able to make
use of 2^47 chosen plaintexts, presumably (except for the unicity
distance) something like Gwyn's proposal was used, and so that means
it is possible, at least for DES, to couple useful information through
the key schedule.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Art of Cryptography (was: Super strong crypto)
Date: Fri, 16 Mar 2001 08:32:34 GMT
On 16 Mar 2001 02:10:25 GMT, [EMAIL PROTECTED] (David Wagner)
wrote, in part:
>John Savard wrote:
>>Thus, to design a cipher that is adequate where high security is
>>desired, it is *necessary* to extend one's reach into the realms where
>>cryptography ceases to be a science, and becomes an art.
>What was the matter with the GGR scheme I described? It gives a provably
>secure way for doing what you want, under precisely specified assumptions.
>Sounds like science to me, not art.
I finally found the post to which you referred.
Given the assumption that one's block cipher is secure against a known
plaintext attack, when one block of known plaintext is all the
attacker has, the function E(k,0) has the property of being an
essentially unbreakable PRNG.
I'm not trying to defend D. A. Gwyn's proposal too strongly in itself.
You've pointed out a good chosen-ciphertext attack. An unstated
assumption of his design is that no attacks other than ciphertext-only
are being worried about; this is common with amateur proposals.
I do think, though, that it is legitimate - in a cautious way - to
design for strength in ways that are beyond the current state of the
science of cryptography to fully evaluate. That is the point I'm
trying to make; since security, period, and not security subject to
rules and limitations is the object, limiting oneself to constructs
understood well enough to precisely quantify their contributions does
not seem to me to be reasonable; but there must be enough
understanding to know they at least do no harm.
Thus, on my site, at the bottom of the page
http://home.ecn.ab.ca/~jsavard/crypto/co041205.htm
under the heading "The Aryabharata Cipher, and Two-Timing Pads", I
have my own little contribution to the search for a 'super-strong'
enciphering mode.
Two parties that wish to communicate share a key that is more than
twice as large as any message block, and when they send a message,
they send, using a public-key cipher, a set of four session keys for
each block in the message.
Because of the way in which keys used in encipherment are derived from
the shared large secret key, it appears to me that it is very
difficult to recover that key, even if the public-key encryption used
to pass session keys is broken. Of course, for an improved form of
triple encryption, a method with speed on the order of that for
hextuple encryption might seem to be overreaching itself if it
attempts to claim the best security for the time required.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What do we mean when we say a cipher is broken? (Was Art of
Date: Fri, 16 Mar 2001 09:52:52 +0100
John Savard wrote:
>
> William Hugh Murray<[EMAIL PROTECTED]> wrote:
>
> >I am not at all sure what you mean by "broken." Do you mean that the cost
> >of recovering a message without benefit of the key suddenly falls to
> >zero?
>
> A cipher is broken when that cost is less than infinity. Or, given the
> existence of brute-force search for all but the OTP, when that cost
> becomes low enough that someone actually _could_ spend the money. A
> cipher is *not* broken when the messages sent in it actually _cannot_
> be read.
But the phrases above 'cost is less than infinity' and
'cost becomes low enough that someone actually could
spend the money' don't have the same meaning and could
eventually have the distance of heaven and earth between
them, I am afraid. If 'broken' is reserved for use in the
sense of the first phrase, then one badly needs another
term for the second phrase.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 16 Mar 2001 09:53:00 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > I like to mention in this connection another point. Your
> > scheme in the original post intends to reduce the amount of
> > materials encrypted by a given key of block ciphers. If one
> > changes session/message keys sufficiently frequently and the
> > message sizes are appropriately limited, then the problem
> > could be avoided, isn't it?
>
> Remember, the scenario I have in mind involves a one-way
> channel, so any new key has to be transmitted in the same
> direction (not "negotiated"). One could certainly set up a
> separate protocol for key distribution, encrypted using a
> "key distributing key", for example, as has been suggested
> in this thread, and multiplex that with the useful-data
> stream. That requires twice as much initial key as what I
> proposed in my straw man mode of operation. That's clearly
> a disadvantage, since the whole point is to stretch the
> (reusable) initial key as far as safely can be done.
I think that you exaggerated a bit. In your scenario,
the volume of new keys sent is large comparable to
the size of the initial key, if I don't err. The 'key
distribution key' simply means doubling the initial key.
So the comparison is 1+n vs. 2+n, n being the total number
of new keys. (For about your 12.5% increase of bandwidth, a
new key ca be sent after 8 normal blocks.) Note that with a
key distribution key the implementation is entirely flexible
with respect to the frequency of introducing new keys
and that (what may be significant) it blocks the domino
effect.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Fri, 16 Mar 2001 09:53:09 +0100
br wrote:
>
> It will reduce little bit a redundancy. So compression is better.
> Is there any other way other than compression. That's my question.
Depending on whether you allow it in the context of your
question, another means (than telegram style) of eventually
obtaining less redundancy is to translate it to another
language that has lower redundancy (if such a language exists).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What do we mean when we say a cipher is broken? (Was Art of
Date: Fri, 16 Mar 2001 09:53:05 +0100
Jim Gillogly wrote:
>
> My definition is that a cipher is broken when the cost of cryptanalyzing
> a set of messages is less than the cost of obtaining the information in
> them by some other means. The cost is measured in some appropriate unit --
> perhaps wall clock time, money, lives, person-hours, or whatever is useful
> for valuing that specific information.
I am afraid that there is a problem. If there does not
exist 'some other means' and the cost of cryptanalysing
is million times of what is affordable by the opponent
currently and in reasonable future, is the cipher 'broken'?
The difference between finite and infinite is certainly
very significant in math, yet an extremely huge number
could exceed the realm of significance for earthly people,
I suppose.
M. K. Shen
------------------------------
** 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
******************************
