Cryptography-Digest Digest #565
Cryptography-Digest Digest #565, Volume #14 Fri, 8 Jun 01 08:13:01 EDT
Contents:
Re: MD5 for random number generation? (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: MD5 for random number generation? ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Some questions on GSM and 3G (Arturo)
Re: Some questions on GSM and 3G (Arturo)
Re: National Security Nightmare? (Derek Bell)
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: MD5 for random number generation?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 8 Jun 2001 11:11:52 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
:> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> : No PRNG is ever secure if the initial seed is compromised. The seed
:> :> : is what determines the PRNG output...
:> :>
:> :> Security in the face of state compromise is a very important part of
:> :> what forward secrecy in RNGs is all about.
:>
:> : Yes. And my PRNG I proposed is forward secure.
:>
:> : H[i] = HASH(SEED || I)
:>
:> : Suppose you guess H[i], how do you get H[i+1] or H[i-1]?
:>
:> You don't.
:>
:> However, say someone breaks into your office and wanders out with i and
:> SEED.
:>
:> With this information they have access to all the past outputs of the RNG.
:>
:> This is known as a "backtracking attack" - and can be of significance if
:> the RNG is used for key generation - since you don't want numerous past
:> keys to be compromised by a single lapse of security on some future date.
:>
:> Backtracking attacks can be prevented - they are not inherent in all
:> PRNGs.
: Which is why (if you well I dunno, ... er ... um READ MY ENTIRE POST) would
: have found that I said you should reset the seed whenever you make a new
: key. That way "wandering into the office to get SEED" will be a useless
: venture.
A commendable approach - if you have lots of suitable seed material to hand.
:> :> As for backward secrecy - this is (as I mentioned) impossible in a PRNG
:> :> whose state has been compromised. However, the OP never mentioned
:> :> PRNGs.
:>
:> : Are you sure? Read the subject line!
:>
:> I see an R, an N and a G there - but can see no sign of a P.
:>
:> While concealing the forward evolution of a PRNG is impossible in the face
:> of state compromise, this is not true of other types of random number
:> generator.
: Um MD5 for RNG. The OP is a newbie and used the wrong term. MD5 cannot be
: used to make an RNG at all.
I don't know about MD5 - but SHA-1 can be (and has been) used to make a RNG:
See Yarrow: http://www.counterpane.com/yarrow.html
--
__
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Fri, 8 Jun 2001 11:26:16 GMT
Vincent Quesnoit <[EMAIL PROTECTED]> wrote:
: Tim Tyler a écrit :
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:>
:> : I was referring to the following that you wrote previously:
:>
:> :Yes it is. Consider BICOM for example. It can map a
:> :8 bit cyphertext to one of some 2^128 plaintexts -
:> :considerably more than your figure of 2^8.
:>
:> : Does the 2^128 come from using a 128 bit key for the
:> : AES in it and there are 2^128 possible keys for AES?
:>
:> Yes.
: I am puzzled, I thought AES was a block cypher which could not produce a
: cypher text smaller than its own blocksize. Do you mean that AES can
: decrypt one byte and produce a 16 byte output ?
Yes.
I composed an extensive reply to Mark Wooding on that question.
He asked:
Now I'm very confused. You can't get a one-byte ciphertext out of a
128-bit block cipher in CBC mode. There's nowhere to put an IV, for one
thing.
I replied with the following:
Firstly, Rijndael doesn't use an random IV. It uses a fixed one which is
(I believe) wired into the algorithm.
In order to disguise the first blocks of the message it uses a whitening
step, which preproce
Cryptography-Digest Digest #565
Cryptography-Digest Digest #565, Volume #13 Sat, 27 Jan 01 02:13:00 EST
Contents:
Re: Between Silk and Cyanide ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) ("Matt Timmermans")
Re: Steak Stream Cipher ([EMAIL PROTECTED])
32768-bit cryptography, updated ("lemaymd")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: 32768-bit cryptography, updated ("Scott Fluhrer")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: 32768-bit cryptography, updated ("Matt Timmermans")
no joke (adam)
From: [EMAIL PROTECTED]
Subject: Re: Between Silk and Cyanide
Date: Sat, 27 Jan 2001 02:11:56 GMT
In article <_Kic6.67331$[EMAIL PROTECTED]>,
"Roger Peniston-Bird" <[EMAIL PROTECTED]> wrote:
<< For instance, what happened to Giskes, who captured so many agents
sent to the Netherlands? Did he survive the war? >>
Giskes not only survived the war, he wrote a book about the whole
affair. An English translation was published in 1953 by British Book
Centre, Inc. and by William Kimber and Co, in London. It was reprinted
in paperback by Bantam Books in 1982 under the title, London Calling
North Pole.
I found it odd that Marks never mentions Giskes' book. There was an
investigation in the Netherlands after the war, which seems to have
drawn considerable publicity in both the Netherlands and England, and I
suspect that the publication of Giskes' book was due entirely to the
controversy stirred up by this investigation, yet Marks takes no notice
of this in his book.
-- Jeff Hill
Sent via Deja.com
http://www.deja.com/
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 02:11:54 GMT
On Sat, 27 Jan 2001 01:20:23 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>There is simply no hope of being able to reach every possible
>conventional block cipher substitution "table" in the same way that
>Dynamic Transposition can reach every possible permutation.
Absolutely! I agree with that 100%.
But what I'm on about is that that's a comparison between apples and
oranges.
Two rounds of DES with independent subkeys can produce 2^32 different
substitutions which will take any plaintext block P to any ciphertext
block C.
Similarly, "every possible permutation" can produce, for every N-bit
balanced block P, every possible N-bit balanced block C, in
(N/2)!(N/2)! different ways.
However, DES cannot produce every possible overall substitution, every
possible table C(0),C(1),C(2^64-1) of output ciphertext blocks
from input plaintext blocks.
And transposition, period, also cannot produce every possible overall
substitution, every possible table C()
C() where the 12870 possible balanced 16-bit blocks,
(for N=16) are assigned, as ciphertext outputs, to the 12870 possible
balanced 16-bit blocks as inputs.
Transposition of balanced blocks is "better than XOR", because there
is more than one way to get from a particular P to a particular C, but
it does not have the sort of exhaustiveness that you are demanding a
substitution-based polyalphabetic block cipher have in order to be
comparable to Dynamic Transposition. The exhaustiveness it does have,
"all possible transpositions", is not equivalent.
Maybe it seems so because 'transposition' is treated as a class of
encipherment in itself, comparable to 'substitution'; this isn't a
semantic problem, it's a conceptual problem; I think you may be a
victim of the Whorf hypothesis, that language limits how we can think.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 02:28:25 GMT
"AllanW" <[EMAIL PROTECTED]> wrote in message
news:94sl80$alu$[EMAIL PROTECTED]...
> I think I missed one of my classes when I learned programming.
> Could you please show me the code corresponding to "generate a
> photon?" Use any well-known computer language -- ADA, APL,
> BASIC, C, C++, COBOL, FORTRAN, PASCAL -- whatever you feel
> comfortable with. I just need to see the basic algorithm for
> "generate a photon."
It sounds more like you missed the drunken argument in the college bar about
the feasibility of strong AI, the limits of simulation, the possibility that
that nature can support useful modes of super-Turing computation, who that
girl in the corner is _really_
Cryptography-Digest Digest #565
Cryptography-Digest Digest #565, Volume #12 Tue, 29 Aug 00 14:13:01 EDT
Contents:
Re: Optimal length of the sieve before a Miller-Rabin test (DJohn37050)
Re: could someone post public key that is tempered ? (Rich Wales)
Re: 96-bit LFSR needed ([EMAIL PROTECTED])
Re: e-cash protocol concept, comments wanted (Eric Murray)
Re: Reading recommendations on protocol design (Chris Yuen)
Re: A little technical note about intepreters (Daniel Leonard)
Re: Optimal length of the sieve before a Miller-Rabin test ([EMAIL PROTECTED])
Re: On pseudo-random permutation (Herman Rubin)
Idea for creating primes ([EMAIL PROTECTED])
Re: I need ADK tampered key that PGP will not detect ADK, on it ... (jungle)
Re: A little technical note about intepreters (Andrew Carol)
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed ("Paul
Pires")
Re: Idea for creating primes (David A Molnar)
Re: Future computing power (John Myre)
Re: PRNG Test Theory ("Trevor L. Jackson, III")
Re: Future computing power (James Felling)
Re: I need ADK tampered key that PGP will not detect ADK, on it ... ("JL")
RSA n-bit key...is p and q n or is the mod n? ("John Matzen")
Re: Future computing power (Ichinin)
Re: PROMIS-software for worldwide spy network by US/Isreal ("Trevor L. Jackson, III")
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Optimal length of the sieve before a Miller-Rabin test
Date: 29 Aug 2000 15:46:16 GMT
My understanding of the reason to do the small primes tests before MR is that
you really want to have SOME confidence that what you run an MR test on is a
prime. That is, sieving is very fast, MR is slow, so just doing MR is a waste
on a totally random number. As fast RN methods could be considered a
competitve advantage, the dirty details are often left to discover for
yourself, like the break even point. Of course, this depends on how fast you
can make the MR test run.
Don Johnson
--
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: could someone post public key that is tempered ?
Date: 29 Aug 2000 09:07:19 -0700
"jungle" wrote:
> the question is open : could someone post public key
> that is tempered & pgp will not detect added ADK to it ?
Have you read Ralf Senderek's paper?
(http://senderek.de/security/key-experiments.html)
Try Ralf's key "A4".
==> http://senderek.de/security/ADK-testkeys/key-A4
contains the actual binary key
==> http://senderek.de/security/ADK-testkeys/html/key-A4.html
contains an analysis of the key
According to Ralf, this key contains one legitimate ADK -- but it
also contains a second (illegitimate) ADK, which was added to the
unhashed part of the key (the kind of thing a malicious attacker
could do).
Ralf reported that PGP 5.5.3i and 6.5.1i saw both ADK's on key A4,
but they failed to note that the second ADK was in the wrong place,
and they encrypted messages to all three keys (the main key, the
legitimate ADK, and the unauthorized ADK) without complaining.
Now, I will admit that Ralf's tampering with this key did not go
totally undetected (since the newly added ADK was reported by PGP).
However, PGP did =not= report any problem with the extra ADK; it
treated the bogus addition exactly as if it were a legitimate part
of the user's public key.
By the way, the correct word in this situation is "tamper", not
"temper". (These two words may sound identical to native speakers
of some non-English languages, but they are completely different.)
Also, "tamper" is normally used together with the preposition "with"
(as in, "someone has tampered with this key", or "this key has been
tampered with").
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
--
From: [EMAIL PROTECTED]
Subject: Re: 96-bit LFSR needed
Date: Tue, 29 Aug 2000 15:59:23 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I am trying out the stream cipher where I take three bytes from the
> > LFSR in the form (a, b, c) and return (((a+1)(b+1)) mod 257)+c) mod
256
> > as the stream output.
>
> Why? And how does the plaintext enter into this?
You use the output and xor it against the input.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED][Rot 13] (Eric Murray)
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject
Cryptography-Digest Digest #565
Cryptography-Digest Digest #565, Volume #11 Mon, 17 Apr 00 16:13:01 EDT
Contents:
Re: Thank you, gentlemen (was Why is this algorithm insecure? (Newbie (Richard
Heathfield)
Re: ? Backdoor in Microsoft web server ? [correction] (Pred.)
Re: AND on encrypted data ("Tony T. Warnock")
Re: One Time Pads Redux (JimD)
Re: Q: Entropy (Bryan Olson)
Re: Paper on easy entropy (Guy Macon)
Re: Q: Entropy (Bryan Olson)
Re: Q: source code for recognizing English ("Douglas A. Gwyn")
Re: Letter frequencies ("Douglas A. Gwyn")
Re: Prngxor with substitution? ("Trevor L. Jackson, III")
Date: Mon, 17 Apr 2000 19:29:09 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Thank you, gentlemen (was Why is this algorithm insecure? (Newbie
Gentlemen, I thank you for a highly skilled demolition of my first
serious attempt at cryptography. I expected it, and was not
disappointed. (What's the emoticon for 'wry grimace', I wonder?)
Perhaps I will feel able to trouble these hallowed halls once more in a
few months time, when I've learned a bit more about cryptanalysis. Until
then, I will retire to Lurkers' Corner. :-)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
29 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (68
to go)
--
From: Pred. <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ? [correction]
Date: Mon, 17 Apr 2000 18:26:14 GMT
Yup. On my Windows 2000 machine, I found the file c:\Program
Files\Common Files\Microsoft Shared\MSDesigners98\MDT2LV.DLL containing
the "weenies" text in reverse. Looking at the exports, it contains a
function called VSetActiveSite. I wonder what it does...
Has anybody tried to search the string in Unicode format? That could be
rather interesting!
In article <[EMAIL PROTECTED]>,
Francois Grieu <[EMAIL PROTECTED]> wrote:
> I'm glad I started the thread with a disclaimer.
>
> The text "Nescape engineers are weenies!" is indeed embedded
> [reversed] in the file dvwssr.dll coming with some Microsoft
> web server software for Windows 95/98 and NT 4 [not Windows
> 2000], and reportedly in file mtd2lv.dll coming with some
> corresponding web authoring tool.
> But contrary to some early press reports, evidence is this
> string is NOT a universal password, nor part of such a
> deliberate mechanism.
> My analysis of Microsoft's statements is
> - this string is "an obfuscation key to obscure the names
> of files being requested by the client from the server"
> while gathering information used to draw a site map.
> - knowledge of this algorithm and key only "allows a user
> who has privileges on a web server to read certain files
> from other web sites hosted on the same computer", and
> therefore the vulnerability only affects "customers who
> host more than one web site on a server".
>
> Still, it looks like Microsoft has distributed a product
> [reportedly acquired from another company] relying
> deliberately on obscurity for some of it's security features,
> a bad professional practice.
>
> Microsoft statements on dvwssr.dll issues are at
> <http://www.microsoft.com/technet/security/bulletin/ms00-025.asp>
> and
> <http://www.microsoft.com/technet/security/bulletin/fq00-025.asp>
> Understandably, the focus is on another vulnerability:
> a subsequently discovered potential for a buffer overrun,
> which can lead to a denial of service attack, or conceivably
> [IMHO assuming the attacker is immensely clever and lucky]
> to arbitrary code being run.
>
>Francois Grieu
>
--
Thanks,
- Pred.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: AND on encrypted data
Date: Mon, 17 Apr 2000 12:41:35 -0600
Reply-To: [EMAIL PROTECTED]
Jim Reeds wrote:
> Tony T. Warnock wrote:
> >
> ...
> > Actually the operation table for ADD (modulo 2**k) and XOR (on k-bit words) are
> > permutations of each other...
>
> This is so totally false, even for k=2, that I cannot refrain from
> splutter. The two operation tables are both Latin squares, but
> the two squares are not isotopic: neither can be obtained from
> the other by permuting the rows, permuting the columns, and
> permuting the values of the symbols in the tables. One way to see
> this is to take two adjacent rows in the ADD table and chain them
> together: starting with the first 2 rows in the k=2 table, for
> instance, we have 01
Cryptography-Digest Digest #565
Cryptography-Digest Digest #565, Volume #10 Sun, 14 Nov 99 02:13:01 EST
Contents:
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: about the win rng using the timer (Tom St Denis)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re:SCOTT16U SOLUTION ON THE WEB (SCOTT19U.ZIP_GUY)
Re: Public Key w/o RSA? (DJohn37050)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Quantum Cracking (UBCHI2)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Trevor Jackson,
III")
Codebook examples on Web? (UBCHI2)
Re: Need technique for about 24 bytes (Boris Kazak)
Re: PALM PILOT PGP found here (Peter W)
Re: Public Key w/o RSA? (Jerry Coffin)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Sun, 14 Nov 1999 01:07:05 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>In sci.crypt SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>[snip]
>
>:>However, there /are/ techniques which attempt to disguise the file length,
>:>through the use of random padding.
>:>
>:>**If** these are used, the analyst may well be able to usefully discard
>:>supposedly compressed files if they are an odd number of bytes long.
>
>[snip]
>
>:>"Scott" commonly mentions that ``Comp(Decomp(X)) = X for all X''
>:>is what one-on-one compression involves.
>:>
>:>The scheme under discussion fails this - if X is an odd number of bytes long.
>:>
>:>I don't want to stress this too much - for most applications, it's probably
>:>a relatively minor issue.
>
>: Actually you still can make one to one compress if you redefine a byte to
>: be 16 bits.
>
>Well, that would be a "henious terminological sin" - a byte is 8 bits ;-)
>
>: That way all files of your english text when tokenized would
>: be a mulitply of 16bits.
>
>Fine if you're only compressing unicode. Not much help for other things ;-/
>
>To illustrate the nature of the problem when dealing with "ordinary"
>files an integral number of bytes long, consider the following example:
>
>Warning, this example is a little complex.
>
>"Hiding" consists of compressing with method "A", prepending between one
>and three random bytes to the file, and then applying David's "Adaptive
>Huffman" compression. The file is then encrypted.
>
>"Unhiding" consists of the reverse: decrypt, decompress, remove 1-3 bytes
>from the start of the file and decompress again.
>
>"Unhiding" will normally result in three possible messages, depending on
>the number of bytes removed. The recipient decides which message makes
>sense.
>
>I will consider only a brute force attack in this instance.
>
>If compression method "A" is my (8-bit) dictionary-based method,
>the analyst typically has to decompress all three files with David's
>decompressor, to decide if he can reject the key.
>
>If compression method "A" is a 16-bit method which leaves the files an
>even number of bytes long, the 1-byte addition and 3-byte additions can be
>rejected before the final decompression is attempted, based on the file
>length. This results in less work for the attacker, and a weaker system.
>
>I mentioned that this example was contrived? ;-)
>
>The point is only that the security considerations for an 8-bit 1-1
>compressor are not quite the same as for a 16-bit one.
I think one can if one wish trans fer the text to an intermiditae file of
16 bit multiples and then compress with a modiefed huffman compress
so that it still compress to 8 bit boudariers. that way all possible binary
8-bit multiple files wihen decompress fo to a 16 bit multiply intermediate
file and then to the text. I am not saying to do this I am saying you can
still get a 1-1 mapping from the ascii test to 8bit binary files.
What I said a few message back was before I gave it more thought.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: about the win rng using the timer
Date: Sun, 14 Nov 1999 00:0
Cryptography-Digest Digest #565
Cryptography-Digest Digest #565, Volume #9 Wed, 19 May 99 11:13:02 EDT Contents: [SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1 (Shannon Appel) From: Shannon Appel <[EMAIL PROTECTED]> Crossposted-To: alt.security,comp.security.misc,comp.protocols,comp.infosystems.www.misc,alt.answers,comp.answers,news.answers,sci.answers Subject: [SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1 Date: 19 May 1999 14:28:54 GMT Content-type: text/x-usenet-FAQ; version=1.1; title="[SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1" Archive-name: computer-security/ssl-talk-faq Posting-Frequency: monthly Last-modified: Nov 16 12:00:00 PST 1998 Version: 1.1.1 (text) Mon Nov 16 12:00:00 PST 1998 URL: http://www.consensus.com/security/ssl-talk-faq.html Copyright-Notice: (c) Copyright 1996-1998 by Consensus Development Corporation -- All Rights Reserved SSL-Talk FAQ Secure Sockets Layer Discussion List FAQ v1.1.1 Mon Nov 16 12:00:00 PST 1998 FAQ Maintained by: Shannon Appel <[EMAIL PROTECTED]> Consensus Development Corporation <http://www.consensus.com/> The latest edition of this FAQ can always be found at: <http://www.consensus.com/security/ssl-talk-faq.html> <http://www.consensus.com/security/ssl-talk-faq.txt> Copyright (c) 1996-1998 Consensus Development Corporation - All Rights Reserved * Due to the November 15, 1998 dissolution of the SSL-Talk mailing list, this will be the last version of this FAQ in its current form. It will be replaced by a more general TLS & SSL FAQ in the near future that is not tied to any mailing list or newsgroup. * All information contained in this work is provided "as is." All warranties, expressed, implied or statutory, concerning the accuracy of the information of the suitability for any particular use are hereby specifically disclaimed. While every effort has been taken to ensure the accuracy of the information contained in this work, the authors assume(s) no responsibility for errors or omissions or for damages resulting from the use of the information contained herein. This work may be copied in any printed or electronic form for non-commercial, personal, or educational purposes if the work is not modified in any way, provided that the copyright notice, the notices of any other author included in this work, and this copyright agreement appear on all copies. Consensus Development Corporation also grants permission to distribute this work in electronic form over computer networks for other purposes, provided that, in addition to the terms and restrictions set forth above, Consensus Development Corporation and/or other cited authors are notified and that no fees are charged for access to the information in excess of normal online charges that are required for such distribution. This work may also be mentioned, cited, referred to or described (but not copied or distributed, except as authorized above) in printed publications, on-line services, other electronic communications media, and otherwise, provided that Consensus Development Corporation and any other cited author receives appropriate attribution. Comments about, suggestions about, or corrections to this document are welcomed. If you would like to ask us to change this document in some way, the method we appreciate most is for you to actually make the desired modifications to a copy of the posting, and then to send us the modified document, or a context diff between the posted version and your modified version (if you do the latter, make sure to include in your mail the "Version:" line from the posted version). Submitting changes in this way makes dealing with them easier for us and helps to avoid misunderstandings about what you are suggesting. Many people have in the past provided feedback and corrections; we thank them for their input. In particular, many thanks to: Christopher Allen <[EMAIL PROTECTED]> Shannon Appel <[EMAIL PROTECTED]> Nelson Bolyard <[EMAIL PROTECTED]> Tim Dierks <[EMAIL PROTECTED]> Eric Greenberg <[EMAIL PROTECTED]> Charles Neerdaels <[EMAIL PROTECTED]> Bruce Schneier <[EMAIL PROTECTED]> Tom Weinstein <[EMAIL PROTECTED]> Jonathan Zamic
