Cryptography-Digest Digest #903, Volume #13      Thu, 15 Mar 01 06:13:01 EST

Contents:
  Modes of operation effort ("kihdip")
  Re: SSL secured servers and TEMPEST (Frank Gerlach)
  Re: Super strong crypto ("Bryan Olson")
  Re: Super strong crypto ("Bryan Olson")
  Re: SSL secured servers and TEMPEST (Paul Rubin)
  Re: qrpff-New DVD decryption code (Joe H. Acker)
  Re: SSL secured servers and TEMPEST (Frank Gerlach)
  Re: One-time Pad really unbreakable? (Tim Tyler)
  Re: SSL secured servers and TEMPEST ("Lyalc")

----------------------------------------------------------------------------

From: "kihdip" <[EMAIL PROTECTED]>
Subject: Modes of operation effort
Date: Thu, 15 Mar 2001 08:34:29 +0100

NIST's second public workshop for the analysis of symmetric key block
cipher modes of operation:

The workshop will be held from 9:00 a.m. to 5:00 p.m.
on Friday, August 24, 2001 (the day after Crypto 2001),
at the Holiday Inn Santa Barbara (located in Goleta, CA).
Registration information will be available soon at the
modes home page:  http://nist.gov/modes.

Comments and papers are requested by August 3; new
proposals of modes are requested by April 1, so that
time remains for them to be analyzed.




------------------------------

From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: Thu, 15 Mar 2001 09:19:12 +0100

Mark Currie wrote:
> 
> Hi,
> 
> A TEMPEST-hardened security module can be used which only allows the clear-text
> private key to exist during a signature operation. At all other times, the
> private key is encrypted with a long-term key that is protected with in
> the security module's tamper-proof memory. This way the clear-text signatures
It seems that you did  not understand me. I was referring to the
emanations generated by the cryptographic processor (which is embedded
in the "tamper proof"/"TEMPEST hardened" module). It is not possible to
create an airtight faraday cage (because you need to transfer a lot of
bits) - only an approximation of that. This means that electromagnetic
emanations will be created on every RSA operation.
And by the way, the secret key *cannot* ly idle in memory, it must be
transferred to the crypto processor's RSA arithmetic processor every
time a symmetric SSL key is to be exchanged. Which happens hundreds of
times a second on busy sites. 
The problem is that even very faint signals might be recovered, if they
are transmitted millions of times, although I think it is on one hand
more difficult than with CRT signals, as the RSA operations are not
occuring in strictly synchronous intervals.

------------------------------

From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Super strong crypto
Date: Thu, 15 Mar 2001 08:20:08 GMT

Douglas A. Gwyn wrote:
>Bryan Olson wrote:
>> And so far you've produced a more awkward system still
>> sitting at that starting place.
>
>It's hardly "awkward"; implementation is easy and fast,
>without any impact on the user interface.

It's awkward.  It requires a source of true random numbers, 
bloats the ciphertext and has to execute the key scheduler 
repeatedly.

>And my actual
>claims for what it accomplishes, as opposed to spurious
>claims that some of you have assumed, have not been
>refuted.  Come on, show why entropy cannot be securely
>added to the stream, or that the scheme adds little work
>to an attack based on flush depth.  That would be worth
>hearing.

Wasn't that you who said the topic seemed to be provable 
security?  I grant that you could specify a few things to 
overcome Dave Wagner's attacks, and then you'd have 
not-yet-disproven security.  I think Ciphile Software has 
that too.


--Bryan

------------------------------

From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Super strong crypto
Date: Thu, 15 Mar 2001 08:20:40 GMT

Douglas A. Gwyn wrote:
>Bryan Olson wrote:
>> You start with a system not proven to be secure against all
>> possible cryptanalysis and end up with one in which you can
>> have vaguely stated confidence.
>
>It wasn't vaguely stated: certain whole classes of C/A, which
>I identified and which the base function is *not* known to
>preclude, are clearly made infeasible by the scheme.

Nonsense.  Several of us have been repeatedly asking you 
just to define your assumptions and goals in precise terms. 
To this day you have not.  Quoting Wagner, "In the absence 
of a precise statement of assumptions, claims of security 
for this mode are `not even wrong'; no sensible truth value 
can be assigned to them."

>> ... if you start with a modern cipher (Rijndael, Twofish,
>> Serpent, others) then we can already have confidence.
>
>Really?  On what grounds?

The scientific method: form a definite hypothesis, then 
actively - even zealously - seek the evidence that would 
show that hypothesis wrong.  

I'd certainly rather have mathematical methods that 
guarantee the correctness of the conclusion, but they are 
not (yet) available.  I cannot look down on the crypto 
literature for lacking such methods, since I am one of the 
people who has not developed them.


--Bryan

------------------------------

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: 15 Mar 2001 01:05:54 -0800

Frank Gerlach <[EMAIL PROTECTED]> writes:
> It seems that you did  not understand me. I was referring to the
> emanations generated by the cryptographic processor (which is embedded
> in the "tamper proof"/"TEMPEST hardened" module). It is not possible to
> create an airtight faraday cage (because you need to transfer a lot of
> bits) - only an approximation of that. This means that electromagnetic
> emanations will be created on every RSA operation.

Huh, you need air vents to move bits around???  That's a new one on
me.  You only need electrical connections.  The modules are typically
completely potted in epoxy (airtight) and surrounded by metal
shielding.  It is very true that the connection points are hot spots
for leakage and the designers must work hard to make sure they don't
radiate any data that way.  But the techniques for that are well
developed.

> And by the way, the secret key *cannot* ly idle in memory, it must be
> transferred to the crypto processor's RSA arithmetic processor every
> time a symmetric SSL key is to be exchanged. Which happens hundreds of
> times a second on busy sites. 

The persistent secret key is *never* transferred into the crypto
module from the outside.  It is generated inside the module and stored
there and it never leaves the module's security boundary.

Maybe you could read the manuals for some of these modules before
making guesses about how they work.  The FIPS 140-1 standard on
nist.gov (I posted the exact url earlier) or vendor web pages
(www.ncipher.com etc.) are good places to start.

------------------------------

From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: qrpff-New DVD decryption code
Date: Thu, 15 Mar 2001 11:24:33 +0100

Benjamin Goldberg <[EMAIL PROTECTED]> wrote:

> > In a market economy, prices should be down when, say, new technologies
> > enable production at lower prices. New technologies now permit very
> > cheap diffusion of music. Powerful Music Conglomerates are only
> > distributors, even if they incidentally own rights on music by
> > contracts. So how is it that we pay, say 5$ or 12$ (on, say, 15$ for a
> > a music CD) to the distributor, when the actual cost of distributing
> > by new means is much cheaper, say 0.25$ ?
> 
> When you go to a fast food place, and pay a couple dollars for a soda,
> when it actually costs them a few cents, does that piss you off?
> 
> > Because market economy fails when there are Monopolies (or equivalent
> > to monopolies). When they exist, they nearly define legality (legality
> > differs from moral/ethical consideration, as Douglas A. Gwyn maked the
> > remark).
> 
> Do you believe that all fast food places are part of one huge monopoly?

Actually, the OP is right. There are only 3 major record companies that
own practically all other record labels, even if these seem to be
independant. I'm not sure, but I think it's EMI, Warner and another
company (Sony?). Music industry is a relatively dirty and monopolistic
business. For example, record companies tie musicians with very long
term contracts, and they are able to completely ruin a musicians
career---and this has happened very often with musicians that have
critizised the business. Radio stations are forced to play a certain
quantity of certain songs (if not, they don't get any free promo records
anymore). Or did you think that radio producers are keen on hearing
Madonna's remake of "American Pie" 10-20 times a day on their channel?
Record companies can push anything they want into the top 10. When a
marketing campaign for a new "style" is launched, they buy all labels
and bands with the same style, but they'll only push one or two of them
in the first marketing phase. The other bands are later thrown in, or,
if they have bad luck, the trend is over and they are dropped. The
reason for this is that a uniform style and a few bands make more money
than high diversity of styles and many bands with the same style at the
same time. Also, customer demand can be controlled better and is more
predictable that way.

So yes, music industry holds a monopoly on the distribution channels.
The few cominant companies do not only completely control the mass
market, they also control the musicians themselves (even famous
musicians) to an amount that even limits their freedom of speech.

Regards,

Erich

------------------------------

From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: Thu, 15 Mar 2001 11:41:19 +0100

Paul Rubin wrote:
> 
> Frank Gerlach <[EMAIL PROTECTED]> writes:
> > It seems that you did  not understand me. I was referring to the
> > emanations generated by the cryptographic processor (which is embedded
> > in the "tamper proof"/"TEMPEST hardened" module). It is not possible to
> > create an airtight faraday cage (because you need to transfer a lot of
> > bits) - only an approximation of that. This means that electromagnetic
> > emanations will be created on every RSA operation.
> 
> Huh, you need air vents to move bits around??? 
Ok, I meant something like "absolutely perfect faraday cage"

>That's a new one on
> me.  You only need electrical connections. 
Very bad. Electical connections (such as a copper SCSI bus or power
cables) will leak orders of magnitude better than the opening for the
fiber cable. That was the reason I suggested to put the power source for
the crypto processor into the faraday shielding itself.

> The modules are typically
> completely potted in epoxy (airtight) and surrounded by metal
> shielding.  It is very true that the connection points are hot spots
> for leakage and the designers must work hard to make sure they don't
> radiate any data that way.
"any data that way" is an impossible proposition, as I am trying to
explain all the time. This is because even the faintest noise generated
by the RSA processor will leak millions of times. I am saying that you
can minimize that leakage (by proper shielding and proper electronic
design), but you will never ever make it ZERO.
(0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000....infinetely)
 


  But the techniques for that are well
> developed.
> 
> > And by the way, the secret key *cannot* ly idle in memory, it must be
> > transferred to the crypto processor's RSA arithmetic processor every
> > time a symmetric SSL key is to be exchanged. Which happens hundreds of
> > times a second on busy sites.
> 
> The persistent secret key is *never* transferred into the crypto
> module from the outside.  It is generated inside the module and stored
> there and it never leaves the module's security boundary.
"security boundary" is good term for asessing threats that result from
the web server (compromise, eavesdropping), but it is a useless term, if
we are talking about eavesdropping onto the emanations of the
(faraday-encased) crypto processor. There is no such thing as perfect
TEMPEST shielding. 

> 
> Maybe you could read the manuals for some of these modules before
> making guesses about how they work.  The FIPS 140-1 standard on
> nist.gov (I posted the exact url earlier) or vendor web pages
> (www.ncipher.com etc.) are good places to start.
Thanks for that reference. I'll have a look at it.

------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 15 Mar 2001 10:37:39 GMT

Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Dave Knapp <[EMAIL PROTECTED]> wrote:
:> : On Fri, 9 Mar 2001 10:59:32 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:> :>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:

:> :>: In contrast, the irreducible nature of quantum randomness has been
:> :>: well established by experiment and theory.  It's not due merely a
:> :>: lack of more detailed knowledge of the state of the system.
:> :>
:> :>Yet there are deterministic theories of how the world operates,
:> :>which appear to be quite consistent with observation:
:> :>
:> :>http://www.anthropic-principle.com/preprints/manyworlds.html
:> :>
:> :>Q13 Is many-worlds a deterministic theory?
:> :>    Yes, many-worlds is a deterministic theory [...]
:> :>
:> :>A deterministic theory has no place for randomness.
:>
:> : Wrong.  Thanks for playing, though.  The many-worlds hypothesis (it
:> : isn't a theory yet) is deterministic, but it is unable to predict
:> : the results of a single observation, since the worldline in which
:> : the observation will be made is unpredictable.
:> 
:> Actually many worlds does make concrete predictions if the initial
:> state is completely known.  That's a consequence of its determinism.

: I think you're parsing that wrong.  Knapp said "the wordline in which
: the observation will be made is unpredictable."  You seem to be
: interpreting that as "the worldline will be unpredictable."

The observation is made in dozens of world-lines.  In the multiverse,
which ones it is made in is determined exactly.

:  I would interpret it as "it is not possible to predict which worldline the
: observer will be in, after the observation is made."

That doesn't even make sense.  The observer is in all the world lines he
started off in (except the ones where he was struck by lightning).

:> Consequently, DAG's statement that: "It's not due merely a lack of
:> more detailed knowledge of the state of the system" is mistaken - if
:> sufficiently detailed knowledge of the state of the system were
:> available, prediction would be possible.

: God is able to obsere the entire state of the system.  Is anyone else
: capable of such?

Not AFAIK - embodied observers appear to have extremely severe
limitations about how much of the multiverse they can measure.

:> The problem is that an embodied observer does not appear to have any
:> way to obtain information about the entire state of the system.

: Isn't that what Kanpp just said?

No.  He just said it was unpredictable - without specifiying who it was
unpredictable to.

: It is impossible for an observer to predict what timeline he will be
: in.  Or rather, he'll be in both, but he won't know... urgh, this is
: hard to phrase.

Well, I don't know if it's impossible.  The orthodox laws - if ones
assumes they are the last word - don't provide a method which could result
in an observer getting the relevant information, I would grant that.

[snip duplicating machine]

: To God, many-worlds is both deterministic and predictable.  To man,
: many-world is deterministic, but not predictable.  Determinism doesn't
: change based on who or what the observer is, but predictability does.

Yes, this appears to be correct.  Prediction may be possible given exact
information about the system - and this /may/ not be obtainable by man.

It certainly seems from the what we currently know of the laws of
physics that obtaining it by probing the system with photons may
be an enterprise destined not to succeed.  The question of whether he can
get this information seems likely to boil down to whether there is some
other way of obtaining this information, or the results of predictions
which stem from it.

[Now going back a bit... Gwyn said:]
:> :>A deterministic theory has no place for randomness.

: Now I'm rather curious.  How should we define randomness?  Suppose
: many-worlds is fact, not hypothesis... us humans have no way of
: predicting the future, but God does.  Is randomness "merely" lack of
: predictability?  In that case, randomnes only exists for man, but not
: for God...

Yes again.  Now, the question of randomness for man could be stated as
whether he can find a way to communicate with god ;-)
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

------------------------------

From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: SSL secured servers and TEMPEST
Date: Thu, 15 Mar 2001 21:50:43 +1100

CRTs and serial lines etc have a useful property: they do things 9or not do
them) at very regular periods.
The situation you describe:
- is very unpredictable, timing wise.  But a variaton of the Kocher timing
attacks might/might be theorised as feasible - by careful analysis of SSL
handsaking start times etc.  But I think (without empirical evidence) that
multi-tasking OSs will be too unreliable, timing wise.  Any comments out
there?
- assume the emanations can be detected at all. Most cpus don't emanate
enough to be above the themal noise floor.  n is proportional to KTBR - with
a CPU clock  and thus bandwidth of say 500Mhz, the noise floor is pretty
high
- assume the sensor can be close enough to detect the emanations
- assume a receiver with a 500-5000 MHz bandwidth exists

Faraday acages used for these sorts of situations use waveguide attenuators
for cooling airflow, and passing fiber optic comms lines in-out.



Frank Gerlach wrote in message <[EMAIL PROTECTED]>...
>I am not sure whether there is a better newsgroup for this, so please
>tell me if you know such.
>The problem is the following:
>Some websites (like  retail banks) have a lot of traffic, which is
>secured with SSL. For each SSL session establishment (symmetric key
>exchange), the secure RSA key must be processed either by the CPU (or
>more likely) by a dedicated cryptographic coprocessor ("cryptobox").
>Heavily used sites will have SSL session establishment rates in the
>order of 100 per second. This means that the secret key is being
>"broadcast" as often as the CRT signal of a PC. Admittedly, the signal
>might be much weaker, but it is transmitted hundreds of thousands of
>times over a couple of days. Also, it will *always*be the same signal,
>contrary to a CRT signal.
>Even if one encases the cryptographic processor in a lot of metal, there
>must be a high-speed transmission link to the (web) server. To harden
>the crypto processor, a fiber cable would be used for that purpose. As
>power supply cables are always an emanation risk, the crypto processor
>would be powered from an accumulator inside the metal casing.
>Even with this kind of TEMPEST hardening, the signal will just be
>dramatically attenuated, as there is the hole for the fiber and the
>opening for the accumulator.
>The attacker could record the emanations for days or even weeks on
>broadband devices (essentially a farm of VCRs in a truck trailer) and
>then let  the "square acres of signal processors"  do sophisticated
>filtering on the recorded signal.
>These are my questions:
>    -has anybody done some scientific considerations on this (maybe
>estimatic attenuation & jamming needs  for cryptographic processors) ?
>    -would salt water be a feasible strong attenuation medium (operating
>the crypto device in a salt water barrel) ?
>    -are there any key usage policies *in use* to make this kind of
>attack impossible (such as temporary certificates signed with the
>"master" certificate of the site) ?
>
>
>



------------------------------


** 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
******************************

Reply via email to