Cryptography-Digest Digest #961, Volume #10 Sun, 23 Jan 00 22:13:01 EST
Contents:
Re: New Crypto Rules ("John E. Kuslich")
Re: XOR for bits, EOD for trits (wtshaw)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Java's RSA implimentation (Tim Tyler)
"Trusted" CA - Oxymoron? ("Jim Bennett")
Weierstrass Normal Form (Laura Feinstein)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: "Trusted" CA - Oxymoron? (Jimmy Doughan)
----------------------------------------------------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Rules
Date: Sun, 23 Jan 2000 16:15:44 -0700
The "rules" will be determined after you have made your case to the
"authorities" not before.
If the "authorities" specify that there is a one time review and then do
not specify whet they are reviewing, then this is the only conclusion
that may be drawn.
I think those who have bought the hype that the reules have benn relaxed
are in for a terrible surprise.
JK
Bill Unruh wrote:
>
> In <86f8sv$opq$[EMAIL PROTECTED]> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>
> > Could someone be nice enough to state Plainly. What is the minimun
> >one needs to do to leaglly do to put ones own free source code to ones
> >encryption software out on the net for others to download. Please don't
> >say look at the BXA rules. THey are of no help to those of use in the game
> >for fun. I do not wish to make a profit. I just want the minum hassle of
> >putting my source code on the net for FREE.
>
> You are playing with large sums of money here and your freedom. The best
> advice is "read the rules" "Get your lawyer to read the rules". Then you
> can proceed.
> oAnyway, from my very cursory reading of the rules, ( so do not use that
> as justification as the men in black coats come for you-- or if the men
> in white coats come for you), you can publish source code on the net if
> you send Commerce the web address of your site when you put it up.
> This is not legal advice.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: XOR for bits, EOD for trits
Date: Sun, 23 Jan 2000 18:21:23 -0600
It appears to me that there are six balanced tables of logic for two trit
inputs with one output, balanced meaning that inputs can be arbitrarilly
reversed. There are six that I quickly found that are unbalanced, inputs
have different effects, yet, like the the others, if you have an output
and an input, specified input as required, then you can solve for the
other input.
--
As an issue in the campaigns, crypto may be forgotten unless we
ask questions whenever we can to bring it up. Report responses.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MIRDEK: more fun with playing cards.
Date: 24 Jan 2000 00:07:13 GMT
In article <[EMAIL PROTECTED]>, CLSV <[EMAIL PROTECTED]> wrote:
>Hmm, if we use the ARC4 setup that means creating
>52 output values that we throw away. Say 30 secs
>per character that means 25 minutes shuffling cards
>at top speed before encryption starts.
R.e.s. said he was getting around 5 chars/minute, apparently without
much practice. Key setup wasn't discussed though-the procedure
is a bit different. Anyway, 30 secs/char may be way too conservative
an estimate. At 10 secs/char, the setup time starts approaching
tolerable. I don't know what's possible with practice.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MIRDEK: more fun with playing cards.
Date: 24 Jan 2000 00:09:01 GMT
In article <86fbdm$pri$[EMAIL PROTECTED]>,
Rex Stewart <[EMAIL PROTECTED]> wrote:
>I have been practicing Mirdek and have noticed several things.
>
>First is that, because I haven't done much with card deck cyphers
>in a while I am rusty, and it appears to require about 15 hours
>to get proficient. This is an important fact to convey to anyone
>planning to use these cyphers in a "real world" situation.
That's about how long it takes to get any good at sending and
receiving morse code with a telegraph, as many spies in the movies
have had to learn how to do, so it doesn't seem completely out of line.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sun, 23 Jan 2000 16:17:17 -0800
"CLSV" <[EMAIL PROTECTED]> wrote ...
[...]
: Hmm, if we use the ARC4 setup that means creating
: 52 output values that we throw away.
Depending on how well-randomized the passphrase letters are, it
could be quite a bit worse than that if we want say 128 bits of
entropy in the passphrase -- and this applies to all the card
ciphers discussed in this thread.
(If a cipher's key is determined by a passphrase, and we want
the overall system to be secure in the sense of requiring any
adversary to do brute-force searches in a space of, say, at
least 128 bits, then it's inescapable that the passphrase
itself must incorporate at least that much entropy.)
Since the entropy per letter in a passphrase from a 26-letter
alphabet is in the range ~1.3-4.7 bits, depending on how
randomized the selection is, 128 bits of entropy would require
about ~28-99 letters. But the passphrase- alphabet can consist
of the *52* letters a-zA-Z, as I suggested before, which changes
the 4.7 bits/letter to 5.7 bits/letter, in the truly randomized
best case. That corresponds to roughly an 18% reduction in the
number of letters needed, e.g. roughly ~23-81 letters for
128 bits, if my arithmetic is OK.
The bottom line is that someone wanting 128-bits of entropy and
using a 10-letter IV (essential with stream cipher "passphrase"
keys) may very well be stuck with ~90 letters to key in before
enciphering a single letter of plaintext. (This is not an
unrealistic rough estimate, I think, because most people can't
remember very much random text, and a "Diceware" wordlist may
not be handy ;-)
(As I recall, Bruce Schneier has recommended >=80 letters in
passphrases for Solitaire, but that doesn't include an IV and
doesn't capitalize on a 52-letter passphrase-alphabet.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sun, 23 Jan 2000 16:24:11 -0800
"Rex Stewart" <[EMAIL PROTECTED]> wrote ...
[...]
: On output feedback cyphers based on ARC4 variants (like
: Solitaire) insulating the state information (and therefore the key)
: from the output seems fairly straightforward, and in fact Solitaire
: seems to have two layers of such insulation. The downside of
: course is the requirement to use a new key for each message.
[...]
But it's a "downside" required for any stream cipher, and hence
applies to all of the card ciphers mentioned in this thread.
IMO, I don't think it's accurate to describe Solitaire as an
"ARC4 variant", although it may have been influenced by ARC4.
(As I posted before, I'm actually interested in the whole class
of what we might call ARC4-M variants -- where M is the length
of the state vector -- whether implemented by cards or computer.
The lack of response to those earlier postings suggests that
this may be an unexplored area.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
Date: Sun, 23 Jan 2000 19:44:41 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Michael Kagalenko wrote:
> Herman Rubin ([EMAIL PROTECTED]) wrote
> ]In article <86au71$m0n$[EMAIL PROTECTED]>,
> ]Michael Kagalenko <[EMAIL PROTECTED]> wrote:
> ]>Guy Macon ([EMAIL PROTECTED]) wrote
> ]>]In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning) wrote:
> ]
> ] ................
> ]
> ]
> ]> No. You are wrong. So long as you can reliably count the number of cycles
> ]> of quartz crystal, you can use this to recover thermally random numbers.
> ]> Temperature dependence may be indeed a proble, but it can be accounted
> ]> for either by thermostabilising or by simply measuring it and feeding
> ]> it into computational process.
> ]
> ]Using the general idea of random, not only this, but everything
> ]else, is random.
>
> False. You did not understand the physics that I am proposing to use.
>
> ] But this does not mean that it will have the
> ]independence properties needed for use as "random numbers".
>
> As I said elsewhere, you are wrong.
You can _say_ that as much as you like. But the readers of the sci.* fora prefer that
you _show_ it.
You haven't.
*NEXT*.
------------------------------
Date: Sun, 23 Jan 2000 19:50:40 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
wetboy wrote:
> In sci.physics Paul Koning <[EMAIL PROTECTED]> wrote:
> : Michael Kagalenko wrote:
> :>
> :> Paul Koning ([EMAIL PROTECTED]) wrote
> :> ]Of course they do. But their signal to noise ratio is high.
> :> ]If you're after noise, then you want a source that has a low
> :> ](preferably negative) signal to noise ratio. Crystals fail
> :> ]that criterion by a very large margin, which is why no competent
> :> ]designer uses them for this purpose.
> :>
> :> That's fair comment, however note, that quartz crystals are a very common
> :> component of digital equipment, and atomic time standard is available
> :> via internet. You can produce thermally random
> :> data by measuring the clock drift against more precise clock (first
> :> you'd have to find out the crystal frequency, of course). To elaborate
> :> a bit, if t is precise time, and t' is the time measured by quartz
> :> oscillator (reclaibrated by using t to avoid systematic drift),
> :> then
> :> <t-t'> = 0 (1)
> :>
> :> (<> stands for math. expectation), however, that does not
> :> mean that there is no drift, but that drift in both directions is equiprobable
> :> (the recalibration I mentioned above consists in making sure that (1)
> :> holds)
> :>
> :> If the drift can be assumed to be brownian random walk,
> :> the average square drift < (t-t')^2 > grows linearly with time
> :>
> :> < (t-t')^2 > = constant * t
>
> : I'm not sure what you mean by "thermally random data". It seems
> : that you're making a pile of assumptions that may or may not
> : be valid.
>
> : The error of a crystal oscillator comes from a number of components.
> : First of all there's the manufacturing tolerance of the crystal,
> : typically 0.01%. Note that in practice this means the error is
> : close to -0.01% or +0.01%, a bimodal distribution.
> < snip >
>
> Do you know that to be an actual fact, or is that a cynical
> assumption you're making?
I don't know what the current technique is but crystals used to be tested and then
trimmed. The trimming often produced a gentle by detectable bulge just inside the
tolerance range.
This is also common in optics. Manufacturers of very high fidelity optical equipment
often buffer their incoming components into bins reflecting the limits of the
tolerance on incoming inspection. When assembling a device containing multiple
"identical" components they select an entire set from the same bin.
Of course this is just a degenerate case of the manufacturer imposing tolerances finer
that their vendors, and the number of bins can be arbitrary. But the dual bin case is
adequate often enough to be interesting.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Java's RSA implimentation
Reply-To: [EMAIL PROTECTED]
Date: Mon, 24 Jan 2000 00:32:44 GMT
Paul Schlyter <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
:> Paul Schlyter <[EMAIL PROTECTED]> wrote:
:> [BigInteger objects are "immutable". They can't be altered once created...]
:>
:> : What would happen if you instead of A=A+1 tried e.g. B=A+1; A=0; ???
:>
:> No juice. New A (=0) object created. Old A object still floats around
:> the system like an unwanted turd.
:
: OK -- what if you do:
:
: BigInteger A[1000000], B[1000000];
Then you get compilation errors - this isn't how you declare arrays in
Java.
: for( i=0; i<1000000; i++ )
: A[i] = <something>;
:
: B = A;
:
: Will the B = A discard the old B and create a new copy of B?
B is not now itself a BigInteger object, but a (reference to an) array
of them.
While BigInteger objects are themselves immutable, a (reference to an)
array of them is not (i.e. the answer to your question is "no" - if B
contained no objects, no garbage would be created).
B = A will discard the pointer to the old "B" array (which never
contained any objects anyway in the example code given).
If this was the /only/ pointer to B, then any BigInteger objects that
*had* been put into B would become available for garbage collection.
I'm not sure any of this helps very much with the aim of
"total oblieration" of a BigInteger once it has been created.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
SECRET VIPAR GAMMA GUPPY.
------------------------------
From: "Jim Bennett" <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: "Trusted" CA - Oxymoron?
Date: Mon, 24 Jan 2000 01:10:26 GMT
I have been reviewing the Certification Practice Statements of various
issuers of X.509 digital certificates for S/Mime email. I have been trying
to find one that really tries to verify the identity of the certificate
applicant and will do it for the general public. I haven't been too thrilled
with what I found.
Why do I care? If you are going to use a personal digital certificate for
signing an email that has significant legal implications, like a request to
withdraw $100,000 from your bank and have the funds wired somewhere else,
you sure as hell want to make sure the person who has signed the message is
really the person he says he is.
Now let's see how various vendors have attacked the problem.
VERISIGN (www.verisign.com)- The best you can get from them is a requirement
that you respond to a challenge email sent to the email address you have
asserted is yours. Well, whoopee. Anyone with access to your POP inbox can
assert they are you. Value: minimal.
THAWTE (www.thawte.com)- Your identity must be vouched for by a group of
people whom Thawte has determined are trustworthy. How does Thawte determine
this? If you have had your identity vouched for a selected number of times
by different people, you are considered capable of vouching for other
people's identity. Better than Verisign, but not much. A group of several
co-conspirators could vouch for false identities for each other fairly
easily. Value: still not good enough for a high value transaction.
USERTRUST (www.usertrust.com) - Better. These guys will do a background
check on you to try to confirm your identity claims, and will arrange for
you to buy a fidelity bond to cover people who rely on your certificate. But
they are currently only doing this for "contracted projects", which to me
sounds like big jobs.
PGP - You have to trust the key signers, but if you are dealing with a
stranger, you are unlikely to know any of the key signers. Value: usually
zero, occasionally good.
Does anyone know of a CA who will do what UserTrust claims to do, but on an
individual basis for the general public?
Thanks,
Jim Bennett
Offshore Asset Protection Lawyer
http://www.jim-bennett.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]
PGP public key at http://www.jim-bennett.com/about/pgp.htm
------------------------------
From: Laura Feinstein <[EMAIL PROTECTED]>
Subject: Weierstrass Normal Form
Date: Sun, 23 Jan 2000 17:09:20 -0800
Given a cubic of the form u^3 +v^3 = a, where a is a rational number, how
does one determine new coordinates, x and y given in terms of u and v by
rational functions?
I know the value of these functions:
x=12*a/(u + v)
y=36*a*(u - v)/(u + v)
I'm looking for an algebraic method for determining these functions.
Laura
--
Laura C. Feinstein
University of Washington
Department of Mathematics
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 24 Jan 2000 02:15:25 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <86dvah$aht$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michael
]Kagalenko) wrote:
]>
]>Guy Macon ([EMAIL PROTECTED]) wrote
]>]In article <86au71$m0n$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michael
]Kagalenko) wrote:
]>]>
]>]>Guy Macon ([EMAIL PROTECTED]) wrote
]>]>]
]>]>]I can see the logic behind trying, but not if you are looking for
]>]>]a good RNG. But what if you are looking for a cheap RNG?
]>]>]a cheap crystal (or, better yet, ceramic) oscillator costs very
]>]>]little, and hooks up to a serial or parallel port easily, and is
]>]>]pretty much immune to 60 Hz electrical noise. I agree with
]>]>]everything said about the lack of randomness, though. You really
]>]>]are just measuring fine differences in the time between reads
]>]>]of your serial/parallel port. Such a circuit, if Von Neuman
]>]>]compensated and exlusive or'ed with the output of the best PRNG
]>]>]you can program, would seem to be, on a practical level, much
]>]>]superior to the PRNG alone.
]>]>
]>]> No. You are wrong. So long as you can reliably count the number of cycles
]>]> of quartz crystal, you can use this to recover thermally random numbers.
]>]> Temperature dependence may be indeed a proble, but it can be accounted
]>]> for either by thermostabilising or by simply measuring it and feeding
]>]> it into computational process.
]>]
]>]I made at least six claims in the paragraph above, and I cannot
]>]tell from your response exactly what I wrote that prompted the
]>]"You are wrong" comment. Could you elaborate as to exactly what
]>]you are disagreeing with? I stand by what I wrote above.
]>]
]>
]> It is too bad that you stand by it, because a lot of it is bogus.
]
]Forgive me if I ignore claimed bogosity that you fail to identify.
]
]You may wish to examine your habit of namecalling without mentioning
]exactly what you disagree wit or why. Your current practice is
]sure to cost you in the areas of career advancement and personal
]relationships.
The example is supplied below. Your failure to read "is sure to cost you ..."
usw.
]
]> The most bogus part is
]>
]>> I agree with
]>> everything said about the lack of randomness, though. You really
]>> are just measuring fine differences in the time between reads
]>> of your serial/parallel port.
]>
]> As I said above, you can obtain truly random data by measuring clock
]> drift due to thermal noise in the crystal.
]
]And you think that the circuit I described will accomplish this?
]Or are you postulating a high precision (better than the crystal)
]measurement system then complaining that my comments about a cheap
]crystal oscillator hooked to a parallel port don't describe your
]system? Thanks for defining "Bogus" by example.
Well, I am not complaining that "cheap crystal oscillator
hooked to a parallel port don't describe" what I am proposing.
This part is true, it doesn't. It isn't true that I
"postulate" high precision clock; rather, I am pointing
out that such are readily available via the Internet, and
that quartz crystal is alread part of every computer system, thus
obviating the need to hook anything to a parallel port.
]You are also confusing "has some randomness, however small"
]with "random enough to be a good RNG for crypto".
Well, no; measuring the clock dirft can supply data random enough
for crypto. You simply failed to understand why.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 24 Jan 2000 02:22:15 GMT
Reply-To: [EMAIL PROTECTED]
Herman Rubin ([EMAIL PROTECTED]) wrote
]In article <86dvcl$a17$[EMAIL PROTECTED]>,
]Michael Kagalenko <[EMAIL PROTECTED]> wrote:
]>Herman Rubin ([EMAIL PROTECTED]) wrote
]>]In article <86au71$m0n$[EMAIL PROTECTED]>,
]>]Michael Kagalenko <[EMAIL PROTECTED]> wrote:
]>]>Guy Macon ([EMAIL PROTECTED]) wrote
]>]>]In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning)
]wrote:
]
] ................
]
]
]>]> No. You are wrong. So long as you can reliably count the number of cycles
]>]> of quartz crystal, you can use this to recover thermally random numbers.
]>]> Temperature dependence may be indeed a proble, but it can be accounted
]>]> for either by thermostabilising or by simply measuring it and feeding
]>]> it into computational process.
]
]>]Using the general idea of random, not only this, but everything
]>]else, is random.
]
]> False. You did not understand the physics that I am proposing to use.
]
]>] But this does not mean that it will have the
]>]independence properties needed for use as "random numbers".
]
]> As I said elsewhere, you are wrong.
]
]Independence is a very strong property. For numbers to be
]used as "random numbers" are typically used, it is often
]more important than the uniformity of the distribution,
]which can be corrected, is the independence of the numbers
]produced by the device. Exact independence means that
]the conditional probability distribution of one output
]given the rest is the same as not having that information.
Yes, I know. What is your point, again ?
]
]Perfect independence is impossible. Radioactive decay,
]counting the parity of the number of events sufficiently
]rarely, comes quite close, although the bias in the
]recording device limits how much can be done; there are
]ways to use multiple streams to improve things.
]
]It is only the UNpredictable part which is useful for
]random purposes. Moderate range dependence of thermal
]noise is hard to keep.
The last sentence looks intriguely relevant to the topic, but
I fail to parse it. What I am pointing out that to the extent
that quartz crystal, any quartz crystal, dissipates mechanical energy,
it will produce thermally random noise, according to the flustuation-
dissipation theorem. The reason a resistor produces the
thermal noise is that same theorem. I am also pointing out that this
thermal noise will lead to brownian-walk drift of the clock which
can be measured to produce truly unpredictable random data. So far,
you and others went on all sorts of tangents due to the failure
to understand what I am saying.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 24 Jan 2000 02:17:17 GMT
Reply-To: [EMAIL PROTECTED]
Trevor Jackson, III ([EMAIL PROTECTED]) wrote
]Michael Kagalenko wrote:
]
]> Herman Rubin ([EMAIL PROTECTED]) wrote
]> ]In article <86au71$m0n$[EMAIL PROTECTED]>,
]> ]Michael Kagalenko <[EMAIL PROTECTED]> wrote:
]> ]>Guy Macon ([EMAIL PROTECTED]) wrote
]> ]>]In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning)
]wrote:
]> ]
]> ] ................
]> ]
]> ]
]> ]> No. You are wrong. So long as you can reliably count the number of cycles
]> ]> of quartz crystal, you can use this to recover thermally random numbers.
]> ]> Temperature dependence may be indeed a proble, but it can be accounted
]> ]> for either by thermostabilising or by simply measuring it and feeding
]> ]> it into computational process.
]> ]
]> ]Using the general idea of random, not only this, but everything
]> ]else, is random.
]>
]> False. You did not understand the physics that I am proposing to use.
]>
]> ] But this does not mean that it will have the
]> ]independence properties needed for use as "random numbers".
]>
]> As I said elsewhere, you are wrong.
]
]You can _say_ that as much as you like. But the readers of the sci.* fora prefer that
]you _show_ it.
]
]You haven't.
]
]*NEXT*.
I don't think that collected readership of sci.* groups had ever appointed you
their spokesmen.
------------------------------
From: Jimmy Doughan <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Sun, 23 Jan 2000 22:01:01 -0500
Jim, how about pushing the trust down to the cert holder's company. Let's say I
hold a cert from ABC company, you should be able to authenticate directly to the
issuing CA or VA via OCSP (if the majority of PKI vendors ever adopt OCSP). For
home users' they should authenticate to their online or internet service. These
companies should have their CAs signed by one of the widely known certification
authorities (versign, Thawte, Xcert, Entrust, Baltimore) to establish trust.
It would be near impossible to spoof a cert and the issuing CA using OCSP. The
value of a Thawte chaining cert would diminish greatly using this model though.
Jimbo
Jim Bennett wrote:
> I have been reviewing the Certification Practice Statements of various
> issuers of X.509 digital certificates for S/Mime email. I have been trying
> to find one that really tries to verify the identity of the certificate
> applicant and will do it for the general public. I haven't been too thrilled
> with what I found.
>
> Why do I care? If you are going to use a personal digital certificate for
> signing an email that has significant legal implications, like a request to
> withdraw $100,000 from your bank and have the funds wired somewhere else,
> you sure as hell want to make sure the person who has signed the message is
> really the person he says he is.
>
> Now let's see how various vendors have attacked the problem.
>
> VERISIGN (www.verisign.com)- The best you can get from them is a requirement
> that you respond to a challenge email sent to the email address you have
> asserted is yours. Well, whoopee. Anyone with access to your POP inbox can
> assert they are you. Value: minimal.
>
> THAWTE (www.thawte.com)- Your identity must be vouched for by a group of
> people whom Thawte has determined are trustworthy. How does Thawte determine
> this? If you have had your identity vouched for a selected number of times
> by different people, you are considered capable of vouching for other
> people's identity. Better than Verisign, but not much. A group of several
> co-conspirators could vouch for false identities for each other fairly
> easily. Value: still not good enough for a high value transaction.
>
> USERTRUST (www.usertrust.com) - Better. These guys will do a background
> check on you to try to confirm your identity claims, and will arrange for
> you to buy a fidelity bond to cover people who rely on your certificate. But
> they are currently only doing this for "contracted projects", which to me
> sounds like big jobs.
>
> PGP - You have to trust the key signers, but if you are dealing with a
> stranger, you are unlikely to know any of the key signers. Value: usually
> zero, occasionally good.
>
> Does anyone know of a CA who will do what UserTrust claims to do, but on an
> individual basis for the general public?
>
> Thanks,
>
> Jim Bennett
> Offshore Asset Protection Lawyer
> http://www.jim-bennett.com
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> PGP public key at http://www.jim-bennett.com/about/pgp.htm
------------------------------
** 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
******************************
