PGP 6.0.2i

Robert Guerra (az096@freenet.toronto.on.ca)
Sun, 18 Apr 1999 19:09:29 -0400

• Next message: Olivier Langlois: "(x * x) % y"
• Previous message: Vin McLellan: "Hiding cyphertext in cyphertext (FW)"
• In reply to: Mail System Internal Data: "DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

humm...don't know where to ask, so though i'd try here...

I've been looking at the pgp source code on http://www.pgpi.com and
have noticed that the mac source doesn't have optimization on in all
the projects..
(rest of details below)

comments?

*** PGP Signature Status: good
*** Signer: Richard Outerbridge <outer@interlog.com>
*** Signed: 1999/4/18 at 6:53 AM
*** Verified: 1999/4/18 at 7:04 PM
*** BEGIN PGP DECRYPTED/VERIFIED MESSAGE ***

1999-04-18 06:34:02 EDT
Robert -

>Will the the level of instruction scheduling/optimization (ie. 1-4)
>affect any of the core crypto routines. I'm afraid that by perhaps
>optimizing the code "too well" it will go fast, but somehow "weaken"
>or "affect" the crypto..you're the expert...so hope you don't mind me
>asking.

There are at least a couple of ways the scheduling could have an
impact. First: if the compiler gets it wrong (that is, if there's
a bug in the optimizer) and the emitted code doesn't actually do
what it's supposed to. The effect could, I suppose, be subtle
enough that you wouldn't notice it, but I've always relied upon
the intolerance of crypto for even small errors to guide me here.
So I don't think it could effect the crypto as such without notice,
but as to things like PRNG or cert attributes or internal keyring
consistency (etc, etc, etc) : who can say, and how would you know?

Second: if the original unoptimized code were specifically written
to guard against DTA (differential timing analysis) then I suppose
that the optimizer could under some circumstances undo all that hard
work and generate faster object code that was exposed to DTA. I'm
just handwaving here, since I know of no claims by NAI that any of
their code was specifically written with DTA in mind.

I guess the point is that *every* new build of any complex project,
with *anything* changed, using what passes for *any* modern compiler
essentially presents an opportunity for something unexpected and
bad to go wrong. Hyper-optimizing increases the chance of this
happening. Only testing and use can give you any confidence that
everything works as designed and expected. Your mileage may vary,
as the saying goes.

outer

*** END PGP DECRYPTED/VERIFIED MESSAGE ***

<outer@interlog.com> :
Just an eccentric soul with a curiosity for the bizarre.

Robert Guerra <az096@freenet.toronto.on.ca>
WWW Page <http://www.interlog.com/~rguerra/www>
PGPKeys <http://www.geocities.com/CapitolHill/3378/pgpkeys.html>

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2i
Comment: Digital Signatures ensure message authenticity

iQA/AwUBNxpmr4PIpEZLQI57EQLT+ACg29fdL96nbGIRxs8IaydhlbjXci0AoJeZ
6gDK+x+mnQQLW+AJqrZyQhP+
=7phn
-----END PGP SIGNATURE-----

• Next message: Olivier Langlois: "(x * x) % y"
• Previous message: Vin McLellan: "Hiding cyphertext in cyphertext (FW)"
• In reply to: Mail System Internal Data: "DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA"