Cryptography-Digest Digest #265, Volume #10 Sat, 18 Sep 99 20:13:03 EDT
Contents:
Re: VICTORY??? (was: crypto export rules changing) ("Douglas A. Gwyn")
Re: Glossary of undefineable crypto terms (was Re: Ritter's paper) ("Douglas A.
Gwyn")
Re: (US) Administration Updates Encryption Export Policy ("Douglas A. Gwyn")
Re: (US) Administration Updates Encryption Export Policy (Bill Unruh)
Re: Second "_NSAKey" ("Douglas A. Gwyn")
Re: crypto papers (jerome)
Re: Second "_NSAKey" ("Trevor Jackson, III")
Re: Exclusive Or (XOR) Knapsacks ("Trevor Jackson, III")
Re: Okay "experts," how do you do it? (jerome)
Re: Okay "experts," how do you do it? (Sundial Services)
Re: Second "_NSAKey" ([EMAIL PROTECTED])
Peekboo 1.4 binary :) (Tom St Denis)
Re: Second "_NSAKey" ("Trevor Jackson, III")
Re: Okay "experts," how do you do it? (jerome)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: VICTORY??? (was: crypto export rules changing)
Date: Sat, 18 Sep 1999 20:13:19 GMT
[EMAIL PROTECTED] wrote:
> "SCOTT19U.ZIP_GUY" wrote: ...
> I'm so sick of you saying that the AES candidates are weak. If they
> are so weak scott, then why don't you break them? All of them.
Any of them.
Or at least, show where the weakness lies in one of them.
I actually think most block ciphers are breakable, with the right
approach of course, but due to lack of funding I'm no longer working
on that project. Short of research results along these lines, it
remains an open issue.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Glossary of undefineable crypto terms (was Re: Ritter's paper)
Date: Sat, 18 Sep 1999 20:03:30 GMT
"Trevor Jackson, III" wrote:
> I nominate the above described phrase "provably secure" to accompany the
> classic "truly random" as not possible to define precisely.
provably secure: adj. (said of a cryptosystem) - Capable of being
shown, using accepted mathematical standards of proof, to possess
some specified property that meets a generally accepted criterion
for suitability in applying the system to some specified security
function (such as privacy, authentication, nonrepudiation, etc.).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: Sat, 18 Sep 1999 20:17:16 GMT
Anthony Stephen Szopa wrote:
> 3) If this is anything to be concerned about then tell me, has the
> US government withdrawn its appeal in the Bernstein case? I doubt
> it because the government is not sincere and full of beans.
No doubt, the government is healthy (full of beans). :-)
The Bernstein case is a different matter. If in fact Bernstein was
in violation of a law that was current when he violated it, then a
later change in the law does not prevent prosecution for the earlier
crime, unless the new law specifically states that (which is rare).
But it seems we're now talking about an administrative policy, not
a law.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: 18 Sep 1999 20:38:46 GMT
In <[EMAIL PROTECTED]> "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>The Bernstein case is a different matter. If in fact Bernstein was
>in violation of a law that was current when he violated it, then a
>later change in the law does not prevent prosecution for the earlier
>crime, unless the new law specifically states that (which is rare).
>But it seems we're now talking about an administrative policy, not
>a law.
Bernstein never broke the law, nor is anyone claiming he did. His was a
pure constitutional challenge that the law did directly affect him in
his ability to communicate if he upheld the law. Changes in law could
make his case moot. However announcements of unknown changes tocome
sometime in the future do not have any affect on the case.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Date: Sat, 18 Sep 1999 20:08:35 GMT
"Trevor Jackson, III" wrote:
> AFAI can tell, there is no explanation of what the second key could do
> that the primary key could not do.
Due to quality control, getting a CSP signed by the primary key is
much more bureaucratic than possibly was desired during the technical
review.
> ... Thus there must be some reason they want to hide the actual
> capabilities of the second key.
No, we know what the capabilities of the backup key are, by an
examination of the object code where that key is used. It acts
the same as the primary key (in authenticating a module), after
the primary key has failed to authenticate.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: crypto papers
Date: 18 Sep 1999 21:29:45 GMT
Reply-To: [EMAIL PROTECTED]
i think it is a very good idea but it will be more convenient to
share them through a web or a ftp site.
On Sat, 18 Sep 1999 01:06:52 GMT, Tom St Denis wrote:
>In the spirit of sharing information here is a list of all the relevant
>crypto papers and such I have... if you want any email me at
>[EMAIL PROTECTED]
>
>16 round differential cryptanalysis of DES.ps 990414-mrobshaw.pdf
>aes-comment-to-nist.ps AES ciphers on the 6805.pdf A faster attack on certain
>stream ciphers.ps A fast new hash function - TIGER.ps All or Nothing
>Disclosure of Secrets.ps Analysis of Splaying.ps Analysis of the sboxes in
>DES.ps A new kind of stream cipher CHAMELEON.ps An Implementation of the
>Number Field Sieve.ps asiacrypt98-slides-c.ps BellareRivest-translucent.ps
>Blowfish Constants.pdf bsa-final-report.txt
>BurmesterRivestShamir-geometric.ps card_cipher.ps CAST-256 AES Submission.ps
>CFB_mode_of_DES.pdf chaffing-980701.txt chaotic.ps Chapter 6 - Stream Ciphers
>(CRC press).ps Chapter 7 - Block Ciphers (CRC press).pdf Chapter 14 -
>Efficient Implementations of Algorithms (CRC press).ps Chapter 2 - Math
>Background (CRC press).ps Chapter 5 - Pseudo Random Bit Generators.ps Cipher
>Block Chaining.ps clipper.txt Correlations in RC6.ps cramer-shoup public
>key.pdf crc faq.pdf CRC Press (Applied Crypto) Block Ciphers.ps Cryptanalysis
>of Blowfish.ps Cryptanalysis of FROG.pdf Cryptanalysis of MAGENTA.pdf
>Cryptanalysis of loki89.ps Cryptanalysis of TWOPRIME.pdf Cryptanalysis of
>loki91.ps Cryptanalysis of MD5.ps Cryptanalysis of ICE.ps Cryptanalysis of
>RC5.ps Cryptanalysis of Lok97.ps Cryptanalysis of Lucifer.ps Cryptanalysis of
>CMEA.ps crypto4n2.pdf Cryptographic File Systems.ps Crypton V1.0 AES
>Submission.ps Cryptanalysis of SKIPJACK (impossible differentials).ps
>Cryptanalysis of ORYX.ps DEAL AES Submission.pdf design-vulnerabilities.pdf
>DFC AES Submission.ps DFC AES Submission (update).ps DFC for smartcards.ps
>diehard.zip Differential Cryptanalysis of FEAL and N-HASH.ps Differential
>Cryptanalysis of DES-like systems.ps Differential Cryptanalysis of IDEA.ps
>Differential Cryptanalysis of Kafre, Loki, REDOC .ps Differential
>Cryptanalysis of SAFER.ps diffusion in the AES candidates.pdf discrete
>logratihms in finite fields and their cryptographic significance.pdf E2 AES
>Submission.pdf Elements of Linear and Abstract Algebra.ps Elliptic Curve
>Cryptography Faq.pdf encryption tutorial (part 1).pdf fast new des.ps
>fast_software_encryption.pdf feistel networks.pdf fibonacci generators.ps
>Formal Treatment of remote key encryption.ps FROG AES Submission.pdf
>GoldmanRivest-MakingMaximumEntropyComputationsEasierByAddingExtraConstraints.
>ps How to forge DES messages in {2^28} steps.ps How to protect DES against
>exhaustive key search DESX.ps How to strengthen DES using existing
>hardware.ps hpc-over.pdf hpc-spec.pdf hpc-subm.pdf IDEACrypt_Coprocessor.pdf
>IDEACrypt_Kernel.pdf Key Schedule Cryptanalysis PART ONE.pdf Key Schedule
>Cryptanalysis PART TWO.ps khufu.tar.gz Links between linear and differential
>analysis.ps list.txt LOKI97 AES Submission.ps lottery.pdf Magenta AES
>Submission.pdf MARS AES Submission.pdf Master Key Cryptosystems.ps mod n
>analysis.pdf multi-permutations.ps observation of key schedule (TwoFish).pdf
>On Modes of operations.ps on the construction of variable-input-length
>ciphers.ps On the Number Field Sieve.ps On the security of the CS-Cipher.ps
>On the security of Quantum Cryptography against Collective Attacks.ps
>Parallel FFT-Hashing.ps pentum optimizations.txt personal-entropy.pdf
>Proth.ini Provably secure one-way hash functions.ps Provable Security using
>Decorrelatiion.ps provably secure and efficient block ciphers.ps pseudo1
>(frobenius primes).ps pseudorandom_number.pdf quasi.ps r1report.pdf Random
>Bit Generators using smoke_detectors.ps ranno.ps rc2-fse.ps rc4_revealed.txt
>RC4_TEST.txt rc6-notes.txt RC6 AES Submission.ps realrandomnum.txt related
>key cryptanalysis.ps Rijndael.pdf
>Rivest-GameTreeSearchingByMinMaxApproximation.ps Rivest-MD5.pdf
>RivestShamirWagner-timelock.ps Rivest-MD4.pdf rivest-factoring.txt rsa129.pdf
>RSA Algorithm - A method for obtaining digital signatures and public key
>cryptography.ps RSA evalutation of RC5.pdf RSALABS Faq.pdf rsa on MD
>algorithms.pdf RSA ROUND ONE.pdf safer.pdf safer key schedule.pdf
>SAFERPPT.pdf sbox generation for TIGER.ps schneier-talk.pdf sciam98.txt
>seal.ps Searching for ultimate correlation (Stream Ciphers).ps sec2_1.ps
>sec2_3.ps sec2_4.ps sec2_6.ps sec2_7.ps security.ps Security of MacGuffin
>(Thesis).ps self-study course in cryptanalysis.pdf SERPENT AES Submission.ps
>SHA-0 Collisions.ps simon_sh.ps skipjack-1.pdf snefru.c sol.c sol.exe Sorting
>Out Zero Knowledge.ps speed-sac.pdf square.pdf ssl-challenge.txt
>street_performer.pdf tests.txt The AKELARRE block cipher.ps The bit
>extraction problem or t-Resilient functions.ps The BLOWFISH block cipher.pdf
>The Boomerang Attack.ps The CAST-128 block cipher.pdf The CRISP block
>cipher.ps The CS block cipher.pdf The ICE block cipher.ps The IDEA block
>cipher.ps The LOKI91 block cipher.ps The LOKI89 block cipher.ps The MacGuffin
>block cipher.ps The RC5 block cipher.ps The Security of Cryptographic
>Primitives.ps The Slide Attack.ps The TEA block cipher.ps The XTEA block
>cipher.ps Three Xor-Lemmas.ps tis_walker_export_101293_hr.txt turtle.ps
>Twinkle RSA factoring device.ps Twofish AES Submission.pdf
>twofish-reference-c.zip twofish-optimized-c.zip twofish-assem.zip vp.txt Why
>Cryptosystems Fail.ps Word Autokey Cipher (WAKE).ps WS_FTP.LOG xmx a firmware
>oriented block cipher.ps xormacs.ps xxtea.ps yarrow-full.pdf
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
------------------------------
Date: Sat, 18 Sep 1999 19:18:21 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Douglas A. Gwyn wrote:
> "Trevor Jackson, III" wrote:
> > AFAI can tell, there is no explanation of what the second key could do
> > that the primary key could not do.
>
> Due to quality control, getting a CSP signed by the primary key is
> much more bureaucratic than possibly was desired during the technical
> review.
OK, assume that two keys are used for efficiency reasons. Like the
developers get one so they can diddle around with modules and not threaten
the master corporate key. In this and all like scenarios Microsoft(tm)
would simply say so. They haven't. They issued a stupendously silly exuse.
If their original intentions were benign, like avoiding
organizational/bureaucratic hassles, why hide them? Why lie about it?
>
>
> > ... Thus there must be some reason they want to hide the actual
> > capabilities of the second key.
>
> No, we know what the capabilities of the backup key are, by an
> examination of the object code where that key is used. It acts
> the same as the primary key (in authenticating a module), after
> the primary key has failed to authenticate.
This is not convincing. By examining some of the object code you can show
the use of the backup key in that code. But showing that the key is not
used elsewhere requires an examination of all of the rest of the code. It's
a negative proposition in a finite space. Mandates an exhaustive approach.
Problem is that searching debug symbol tables only works if everything ships
with debug symbols, which is not usually the case. And a section of code
implementing additional, secret capabilities would probably get more careful
handling (symbol purging) than the rest of the code. So it may not be
visible in the available debug symbol tables.
Monitoring a running application to find references to the backup key
requires activating the additional functionality, so it reduces to a
chicken/egg problem. If you know how to trigger the hidden capabilities
you'll detect the reference to the backup key. If you can't trigger the
code implementing the functionality there will be no references to the
backup key for your bus analyzer/debugger to detect.
Point is that it is hard to show that the key has no hidden functions.
------------------------------
Date: Sat, 18 Sep 1999 19:02:29 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Exclusive Or (XOR) Knapsacks
rosi wrote:
> Trevor Jackson, III wrote in message <[EMAIL PROTECTED]>...
> [Snip]
> >
> >Does the non-unique case permit extension to the point that uniqueness may
> be
> >provided by additional information? I.e., could a "key pair" be created
> such
> >that the "public" portion is non-unique, perhaps in pathologically so,
> while the
> >"private" portion determines the unique solution?
> >
>
> Yes and No depending on a couple of things.
>
> Additional information, yes.
> Private, not necessarily. If private, it is analog to keeping a 'subset'
> bits of an
> RSA modulus secret. (Nonetheless, keeping it secret does in no way, I hope,
> decrease the security or the complexity for an attack)
>
> The property of 'non-uniqueness' (note in quotes) is provided by
> 'structure'
> rather than secret information (but of course the private key is still
> secret).
>
> A bit more (only in the limited one-way trapdoor sense this time). Say, A
> and
> B are to perform the treat with a set {1, 2, 3, 7, 19}. If the subset sum is
> 10,
> well that is beyond NP-complete. An attacker can NOT get it (i.e. 1+2+7 or
> 3+7?). Call it Perfect Secrecy? A bit of flavor. However, non-unique in this
> true sense does not give us any ease. The decryptor can not get it, EITHER!
> If the decryptor winnows out undesirable ones taking advantage of any
> additional characteristic of the message, or any other additional
> information,
> we go back to square one. That is, whether that 'piece' is to be kept
> secret.
> However, to be brief, if one designs it in such a way that the solution can
> be
> unique (which IMHO can be achieved in more than one way with different
> ease for A and B, and no less complexity for the attacker) to the decryptor
> (_AND_ the encryptor), but as a subset sum it can really decomposed in
> more than one way. The simplest is to consider the above example. If one
> can design it in a way that only one of 1+2+7 and 3+7 can be valid, the
> point
> may be clearer.
>
> Finally, I think, when we talk about security, etc. we re-visit the same
> set
> of questions, which are many and can get us very 'involved' and sometimes we
> can not put a satisfactory stop to it once started. The questions are very
> straightforward, independent of math formulae and so forth. Take this for
> an example, what one does is to look hard at the way A and B does the
> treat and the way(s) (any imaginable ones) an attacker can institute. No
> doubt, one can not cover all. But if one thinks in generic terms, he is
> likely
> to cover a large area. One thing obvious to me --- and I believe to all ---
> is that A or B does the decryption treat piece meal while the attacker
> 'cannot'. When such a difference is 'distilled and enlarged' (If you have
> 4-5, you DO HAVE 4-5), ... Needless to say that both the cryptographer and
> the cryptanalysist need to look at any assumption harsh and straight in the
> eye
> and avoid getting intoxicated in the (seemingly) success they (maybe
> temporarily) get.
>
> Thank you so much Trevor.
> --- (My Signature)
>
> P.S.
> Think saying a bit more here won't hurt (about 'unique'). It is, IMO,
> possible
> that the public portion at publication is semantics dense (or in other
> words,
> an attacker gets the 1+2+7 or 3+7 situation). However, if all the secret is
> one-sided, I can not think of a way to really create the situation for an
> attacker while A and B do not get confused at all. It is quite against
> intuition,
> but I can be wrong. One day, somebody may come up with this Perfect
> Secrecy, but I doubt. Therefore, if A and B are to perform the treat, at
> some
> point, more needs to be revealed in one way or another. I just would like to
> emphasize: I have no appetite to bet my life (or any portion of it) on PS. I
> ONLY strive for one-wayness. If any is in the same frame of mind, we are
> in the same camp. I am in no way saying 'shut up' to anybody. I have no
> right to do so in any fashion. I lay down my scope so that other people and
> I talk in the same terms. (BTW, I gave my def. or my version of trapdoor
> one-
> way)
Thank you for the thoughtful response.
It appears that a pathologically dense collection could be publicly defined, and
a secret bit vector selected that indicated a subset with the uniqueness
property (i.e., it does not add to the public collection, but subtracts from
it).
If the number of such unique subsets were large, which should be the case for a
pathological collection, it would be difficult for an attacker to identify the
particular subset.
How difficult?
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Okay "experts," how do you do it?
Date: 18 Sep 1999 23:41:41 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 18 Sep 1999 05:34:10 -0400, Trevor Jackson, III wrote:
>
>This is the reason that a large number of ciphers is an attractive idea. It is
>possible for a large organization to spend more human effort on cryptanalysis
>than the designers of a single cipher can spend. When that ratio grows the risk
>of finding an exploitable flaw grows with it. OTOH, it is hard to maintain a
>high ratio of attack effort vs design effort in the face of a large number of
>ciphers.
here i think you forgot that very few people have the skill to
design good cyphers.
if a beginner designs a cypher, lets say it will be cracked in
2 days by am experienced cryptanalist but the guy who uses the
cypher want to protect his data more than 2 days...
>This assessment is based on the assumption that the design effort for a single
>cipher scales poorly. Some situations may even experience diseconomy of scale
>(too many cooks). But the attack effort scales much better, although probably
>much less than linearly due to duplication.
i fully agree
> I'd expect the design effort for multiple ciphers to scale well, almost
> linearly.
i don't think it scale so well. a lot of cyphers use the same concept
and componants. for example if you find a weakness in the feistel
network concept, it can be used against all the cyphers which use it.
------------------------------
Date: Sat, 18 Sep 1999 15:59:14 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Okay "experts," how do you do it?
jerome wrote:
> so you cryptanalyze all the cyphers described by beginners ?
> i can easily write a feistel network which -seems- not too
> bad in 2hours.
> after that, how resistant it is... even against known attack, it is
> another matter. to find out you have to crypanalyze it and try
> at least the most common attacks (linear, differential, key realated).
To try to steer this discussion gently back on course, let me say that
for example it seems to me [an untutored individual] that one could
create some kind of a test-bed into which the cipher algorithm could be
installed and fed a bunch of known data. One could then statistically
analyze the outputs obtained to predict the quality of the cipher.
Cryptanalysis papers that I have read often focus upon the number of
key-bits actually used by the cipher, the influence of the key vs. the
influence of the data on the output of the cipher, or the difference in
output given slight or substantial changes in the input data.
These should be quantitatively analyzable characteristics. Anyone ought
to be able to do them. And furthermore, it seems to me not wholly
implausible that some kind of automatic, perhaps neural-network-like
strategy could be employed to *design* a cipher or to establish the
actual values used in critical components like s-boxes.
I tend to view with skepticism any argument that says that only certain
individuals know how to do things. HOW do they know? WHAT do they
know? I should not have to undergo the experience of "cracking zillions
of ciphers" to slowly and painfully gain knowledge if anyone else in
this world has gone through the experience before and can, and will,
express in some objective way what it is they learned.
We have notions to this day that cryptographers sit in dark rooms,
poring over large sheets of paper with square grids of letters and
numbers on them, waiting for some magic flash of insight, "ah hah!" But
I doubt that real cryptographers have done that in a hundred years or
more. We have computers now. They can accomplish the work in
milliseconds once we can articulate what the work should be.
So, "what do you do," and "how do you do it?"
Can anyone, more clever than I, speculate in any knowledgeable way what
-might- an automatic test-bed look for, or analyze, to gauge the quality
of a cipher, umm, automatically?
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Sat, 18 Sep 1999 23:45:55 GMT
In article <7rrgli$803$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Integrity checking is very hard (roughly speaking, impossible)
> to do well; and anyway, in real life, nobody does it.
I do. Certainly people who write security applications should - apart
from burglars who come the middle of the night there are viruses out
there.
I suppose, one possible way to protect an executable against surgery is
to encrypt it and have the executable decrypt itself when it loads. If
the key used is secret and unavailable to the burglar, his only
alternative would be to install a Trojan that exactly emulates the
application - a costly proposition. Unless he can easily modify or re-
install an external crypto library (or any external library for that
matter). I really think that serious security applications should use
the OS as little as possible; then the NSAKEY matter would become moot.
> The number of security applications that use CryptoAPI is not
> that large. (As for the rest, they're not relevant, because
> the "_NSAKEY" couldn't be used to compromise them anyway.)
>
> Anyway, if you spike MSIE, Netscape, MS-Office, and PGP, that
> probably accounts for 99% of all encrypted traffic. (I may not
> have the list exactly right, but the point is that 1% of the
> apps probably account for 99% of the ciphertext.)
Oh, I agree. One more reason not to use standard applications for
security, if at all possible. They are big fat targets for attackers.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Peekboo 1.4 binary :)
Date: Sat, 18 Sep 1999 23:54:09 GMT
Well fixed some bugs, added some features, and 1.4 is ready for public
consumption.
Please try it out, I want feedback!!!
Features
- Supports various ciphers
- Key Exchange
- Does auto-crypt, and line-wrap
- It's free
- It's only 35kb or so
the binary is at
http://www.cell2000.net/security/peekboo/peekboo.exe
The cheap manual (anyone good at manuals here?) is at
http://www.cell2000.net/security/peekboo/peekboomanual.doc
(wordpad format)
I can send the source to anyone who asks ([EMAIL PROTECTED])
My public key is
bu0wBGmfDGquzUL3Caaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaq
abaaaaqKY}PJTkY6P}TyLJXYi6qe}HaEaQapBObSg9yhhpfynFvxGkzDuQLZVdIXTWmS
SuQVNGhx0YoL4RjIQN6o30WkVJaWbnNduNQ{2pVSFNkCR0sJBJZq8bEusJNg1vtlr1}9
49IbueN7O5kiM6ES93PQvjBvZseIJ0rxkilvyZSPwGdDMBIIYqjJICfkWcS5jYjuZiOR
OS96NTezIJ0dXvsm0nZEnZSLH56mh{2pTaqJMA{2E9IgSxZV5u{KRFNhpJtCGFKC3CEl
DJ6FNSH1l5Srpd{cH8kPy}FV7}R5zS4EP5Lp}CZ71tTxPKWiZEhWeMjzx9jiDEfJtcJm
nlOlVj9la
Please try it out (it's not a home brew, and it's free!!!)
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Sat, 18 Sep 1999 19:22:52 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Geoff Thorpe wrote:
> Hi there,
>
> "Douglas A. Gwyn" wrote:
> > *obvious* questions: How could MS possibly "lose" the primary key
> > (yet retain the backup key)? We're talking about data here, that
> > can readily be copied and backed up in various physical locations,
>
> Just a thought, but for something so "important" (a signing key that
> protects Windows from malicious code is kind of like a cheese-slice that
> protects elephants from comets), they might have decided (as some CAs
> do) to generate the private key inside hardware, in which case the key
> is buried within tamper-proof confines. In this case a back-up key might
> protect against destruction of the other. This might give the argument a
> shred of legitimacy but not much ... still, it's a thought. This is all
> I can come up with to match their argument with reality - the keys exist
> in an "or" rather than "and" relationship, so there's no protection
> against either getting compromised so the only plausible explanation
> could be the "loss of key" one.
If, as you suggest, the keys are in a form of escrow, why didn't
Microsoft(tm) simply _say so_?
>
>
> Still, the whole thing smells a bit fishy so perhaps there's little to
> be gained by trying to make sense of the press releases.
Clearly we're only getting part of the story (Where is Paul Harvey when you
need him?) How do we tell whether the undisclosed part of the story is
benign? We can't. The very fact of non-disclosure argues that there is
something they have to keep hidden. Something ugly.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Okay "experts," how do you do it?
Date: 19 Sep 1999 00:06:29 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 18 Sep 1999 02:51:21 GMT, Douglas A. Gwyn wrote:
>jerome wrote:
>> an unknown designs a new cypher A and coppersmith, rivest and shamir
>> design a another new cypher B. Will you read both papers with the
>> same 'open mind' ?
>
>If they're published in a reputable peer-reviewed journal, sure.
>(The review/referee process is designed to ensure that only papers
>of acceptable relevance and quality are published; often it involves
>iterative editing until the criteria are met.) At least, I'd read
>the title and abstract to see whether it might be worthwhile to
>read further.
Your example is OK if the referee isnt influenced by the reputation
of the author. According to my experience, it is much easier to be
published when you are well known.
obviously maybe you are well known because you are good and the referee
may not be influenced by the reputation... hard to say.
------------------------------
** 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
******************************
