Cryptography-Digest Digest #100, Volume #11 Fri, 11 Feb 00 18:13:01 EST
Contents:
Re: RFC: Reconstruction of XORd data (zapzing)
Re: PIII Random Number Generator (John Savard)
Re: Twofish vs. Blowfish (Albert Yang)
Re: Period of cycles in OFB mode (John Savard)
Re: help DES encryption (John Savard)
Re: Newbie Encrypt question ([EMAIL PROTECTED])
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Terry Ritter)
Re: Latin Squares (was Re: Reversibly combining two bytes?) ("Tony T. Warnock")
Re: Latin Squares (was Re: Reversibly combining two bytes?) ("Tony T. Warnock")
Re: new standart for encryption software.. ([EMAIL PROTECTED])
Re: Using Gray Codes to help crack DES (Mok-Kong Shen)
Re: Which compression is best? (John Chandler)
Re: Guaranteed Public Key Exchanges (Mok-Kong Shen)
Re: Eurocrypt 2000 (David A Molnar)
Re: Bounding (p-1)(q-1) given only knowledge of pq ("Joseph Ashwood")
Re: Newbie Encrypt question ("Joseph Ashwood")
Re: RFC: Reconstruction of XORd data (Mok-Kong Shen)
Re: RFC: Reconstruction of XORd data (Mok-Kong Shen)
Re: help DES encryption (Paul Koning)
Re: Period of cycles in OFB mode (Paul Koning)
Re: Somebody is jamming my communications -- this has been happening at (Paul
Koning)
Re: "Trusted" CA - Oxymoron? ("Brian Hetrick")
----------------------------------------------------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Fri, 11 Feb 2000 20:59:53 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Mok-Kong Shen wrote:
> >
> > Ian Clarke wrote:
> > >
> >
> > > The algorithm is simple, I take the initial data, and XOR each
byte with
> > > the previous byte (the first byte is left unchanged). This moves
> > > forward through the string compounding the XOR at each stage (ie.
each
> > > byte is actually XORd with all previous bytes).
> > >
> > > The following piece of java does this: (Data is in char[] strC):
> > >
> > > for (int x=1; x<strC.length; x++)
> > > {
> > > strC[x] ^= strC[x-1];
> > > }
> >
> > This is a form of what is in classical terminology termed auto-key
> > encryption. One can simply try all possible values of the first byte
> > to decrypt.
>
> Addendum: In the present special form, the 'key' is known, namely
> the first byte.
>
> M. K. Shen
>
It does seem as if it could be done better.
What if one used a reasonably large-ish block,
encrypted the data in a known key, then split
the block into first half and last half,
wouldn't that do it? Wouldn't it help if
random noise were included in the block?
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: PIII Random Number Generator
Date: Fri, 11 Feb 2000 14:22:25 GMT
"Nick Shaffner" <[EMAIL PROTECTED]> wrote, in part:
> So did the PIII ever ship with that cryptographic quality RNG that they
>promised? If so, anyone know where I can find information on getting access
>to it? www.intel.com doesn't seem to mention anything about it, and a
>couple of web searches didn't turn up anything...
There is stuff about it on the Intel web site, but the RNG is not part
of the Pentium III chip; it's part of the 810 chipset. So it is
available to some Celeron users as well.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Twofish vs. Blowfish
Date: Fri, 11 Feb 2000 21:23:13 GMT
Thanks, Understand what you are getting at.
I was thinking the same thing, I will have a pretty common API so I can
change the backend at will and not effect the program.
I might go with Serpent, but it's slow compared to Twofish.
I was thinking about just doing a quick 10 liner XOR encryption and
decryption algorithm as a stub, but I thought, shoot, then I can plug
RC5 or RC6 in there for just a few lines more! So that's what I might
do.
But I'm hoping to finalize on an algorithm..
When's AES suppose to be picked again?
Albert
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Period of cycles in OFB mode
Date: Fri, 11 Feb 2000 14:32:06 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
>In researching such questions, I uncovered what /appears/ to be an error
>in Schneier's "Applied Cryptography".
>On P.205, in a section called "Security problems with OFB", he writes:
>``When the feedback size equals the block size, the block cypher acts as
> a permutation of m-bit values (where m is the block length) and the
> average cycle length is 2^m - 1.''
>I believe the expected cycle length will be 2^(m - 1), and *not* 2^m - 1.
>The proof of this is not quite trivial. I'll provide it only if it is needed.
I think you're right. (2^m) - 1 for an average cycle length for m-bit
values does seem a bit high. However, I would have thought the
Birthday Paradox would make it even lower than 2^(m-1).
Let's take a 3-bit block.
We feed in an initial value of 0 to our cipher - which is bijective
(this is important, as it changes the odds).
There is a 1/8 chance that we will have a cycle length of 1, with the
sequence being { 0 }.
There is a 1/7 chance that our cycle is of length 2, { 0, S(0) }
There is a 1/6 chance that our cycle is of length 3, { 0, S(0),
S(S(0)) }
... and that's why we don't have the Birthday Paradox to worry about,
because ONLY going back to 0 can make a cycle. If we were using a hash
function instead, then all previous values would contribute to the
chance of a cycle, not just the first. But with a bijective cipher,
for the last value to produce a previous output requires two different
blocks to encipher to the same value.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: help DES encryption
Date: Fri, 11 Feb 2000 14:33:30 GMT
Hideo Shimizu <[EMAIL PROTECTED]> wrote, in part:
>In D.R. Stinson's book 'CRYPTOGRAPHY Theory and Practice' page 79,
>such a example of 16 round of DES is given.
The book "Cryptography: A Primer" by Alan Konheim also does so, which
was a great help to me quite a while ago when I implemented DES.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Newbie Encrypt question
Date: Fri, 11 Feb 2000 21:30:29 GMT
Let me ask this then (last question I promise, at least for today :-))
I found some source code to RC5. Question is, is that patented stuff?
Or can I use it/play with it for my own use?
Thanks again, you guys have helped me a ton!
p.s. I've been told that RC5 is crackable, but for my purposes I think
it would work fine.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Fri, 11 Feb 2000 21:45:57 GMT
On 11 Feb 2000 18:51:36 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Michael Wojcik) wrote:
>[...]
>But to answer your question: I don't think anyone's made any very
>strong arguments for using Latin Squares as combiners yet (in this
>thread). Terry Ritter has made some suggestions in that direction,
>but at the moment most of us are just playing with the idea.
My main reason for using combiners is to complicate or eliminate
known-plaintext or defined-plaintext attacks. Normally, in a stream
cipher using an additive combiner, known-plaintext (or just "guessed
plaintext") will immediately reveal the keystream or confusion stream.
Then the opponents start to work on the key generator. A keyed
nonlinear combiner at least prevents easy access.
The reason for having *Latin square* combiners is to prevent leakage
through either input port. We certainly don't want leakage from
plaintext. But if we choose things at random I think it would be
common to find some amount of correlation between output and key under
known-plaintext conditions. Then the opponents can at least start to
work on the key generator.
I recommend using keyed nonlinear combiners even for "one time pad"
systems. The reason for this is that neither user nor designer can
test that there is no pattern in the confusion sequence. The
randomness tests we have can be passed by PSEUDO random generators,
which can be attacked. So if by some mischance the "really random"
generator is not as random as one hoped, the combiner prevents easy
access to the confusion sequence and so complicates a normal stream
cipher attack.
To the extent that a keyed nonlinear combiner complicates access to
the confusion sequence, it has *strengthened* the cipher against that
attack. This increase in strength can then be the basis for a
decrease in complexity of the confusion generator itself.
>Personally, I'm not persuaded we need new combiners at all, as far as
>practical cryptography goes. Existing methods certainly look good
>enough for *my* purposes; those with more stringent threat models may
>be looking elsewhere, but the state of public crypto is such that
>inventing new encypherment methods doesn't appear to be a priority.
>This is just a mental exercise, as far as I'm concerned. Others may
>feel different, of course.
I think the massive use of just a few well-known ciphers simply begs
attack. These ciphers have been around for a while, and attacks on
them can use everything in the academic literature *plus* whatever
insights long and concentrated work can provide. Those ciphers could
have been broken years ago, and if the opponents just kept quiet about
that, people would still use those ciphers. Well, people *are* still
using them. We do not and can not know whether or not the ciphers are
broken on a regular basis.
It is not only in theory but also in practice that we do not know if
our ciphers are secure. But we *do* know that if our ciphers are
*not* secure, that situation is not going to change itself. Indeed,
we know the situation will change only if *we* act to change our
ciphers. I think that is a fine reason to continue the development of
a broad array of new cipher designs.
Note that the major investment involved in breaking a cipher could be
intellectual time and effort already past. Success might well be
automated, and thus available at will simply by acquiring data and
starting the program. Cipher breaking may be cheap and easy and thus
practical even for rather casual data.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Fri, 11 Feb 2000 14:45:22 -0700
Reply-To: [EMAIL PROTECTED]
Using a Latin square has the following property that may be of
advantage. If the key symbol and the plaintext symbol are chosen
independently, the sums of the squares of the probabilities of the
output symbols is smaller (or equal) to the sums of the squares of the
probabilities of the input symbols; equality obtains if one of the
inputs has only a single symbol. This makes the output distribution
closer to uniform than either of the two input distributions (equality
if only one symbol on one of the inputs.) I haven't tried to prove a
similar theorem for other types of combiners. If there were biases in
the keystream this might help a bit.
I devised this years ago for combining random number generators in
non-cryptographic applications. It turns out it doesn't matter
(distributionally speaking) what the combiner is, just that it is a
Latin square.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Fri, 11 Feb 2000 15:02:39 -0700
Reply-To: [EMAIL PROTECTED]
Latin squares are really only useful if the input alphabet and key
alphabet are the same size. The DES S-boxes don't have the same sizes
but seem to work OK.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: new standart for encryption software..
Date: Fri, 11 Feb 2000 22:03:31 +0000
How could you make sure that the key was not being emailed somewhere as data
was being encrypted??
there was one quite good email program that sent usernames and passwords of
accounts that people checked using it to an email address at hotmail, I guess
that sort of thing is a bigger threat when it comes to closed-source encryption
products than carefully crafted weaknesses in the key generator or a
mis-implmented algorithm.
-Emrul
[EMAIL PROTECTED]
finecrypt wrote:
> Eric Lee Green wrote in message ...
>
> >In short: If it ain't source, it ain't secure, as far as most crypto types
> are
> >concerned. There's been too many cases of government bodies bribing crypto
> >companies to put in hidden back doors (See the Crypto A.G. case, for
> example)
> >for anybody to trust closed-source crypto nowdays.
>
> Dear Eric Lee Green,
>
> I agreed with you that you cannot trust program if you don't know how it
> works. But if you test the program with oficial test vectors of authors of
> algorithms and IF ciphertext produced by the program will *exactly matches*
> with test ciphertext, THEN you will know how program works. Moreover, you
> will know that the program encrypts exactly as intended by authors of
> encryption algorithms and that there is no any backdoors. You will be able
> to crack ciphertext produced by the program only if you crack algorithm.
> Oficial test vectors is the more reliable guarantie than the source code.
> Today FineCrypt is sole program that offer possibility to check it with
> oficial test vectors.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Using Gray Codes to help crack DES
Date: Fri, 11 Feb 2000 23:19:04 +0100
Dan Day wrote:
>
> On 8 Feb 2000 23:24:52 GMT, [EMAIL PROTECTED] wrote:
> >
> > count = count + 1
> > greycode = count ^ (count >> 1)
>
> Hey, that's really slick. But I'll be damned if I can figure
> out why it works...
Let's denote two successive code values built according to this
scheme by G(c) and G(c+1). We have
G(c)^G(c+1) = [c ^ (c >> 1)] ^ [(c+1) ^ ((c+1) >> 1)]
= [c ^ (c+1)] ^ [(c >> 1) ^ ((c+1) >> 1)]
= P ^ Q (definition)
We illustrate with an example for 8 bits, with the symbol b denoting
any value 0 or 1. (Note that max. of c for use in the above relation
is 2^n-2, hence the case c=11111111 is excluded from the following.)
Case 1: c=odd. A typical case is e.g.
c bbbb0111 c >> 1 0bbbb011
c+1 bbbb1000 (c+1) >> 1 0bbbb111
P 00001111 Q 00000111
Note that both P and Q have two blocks of bits, one being
all 0 and the other all 1 and it is Q = P >> 1.
Case 2: c=even.
c bbbbbbb0 c >> 1 0bbbbbbb
c+1 bbbbbbb1 (c+1) >> 1 0bbbbbbb
P 00000001 Q 00000000
Note that P is 1 and Q is 0.
Hence in both cases G(c)^G(c+1) has only one 1-bit and all other bits
are zero. This is exactly the property of the Gray code.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (John Chandler)
Subject: Re: Which compression is best?
Date: 11 Feb 2000 21:35:34 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>John Chandler wrote:
>
>> I just noticed a post crediting "DS" with suggesting using
>> adaptive compression in _both_ directions before encrypting.
>
>If the forward pass does a good compression job, I wonder how much
>additional compression could be expected from the backward pass.
None.
The idea is to remove the asymmetry wherein the first few bits
can be subjected to a trial decompression using the known or
assumed initial frequency table. The initial table for the
second (backward) pass depends on the entire message, which should
make the job of cracking it more difficult.
>M. K. Shen
--
John Chandler
[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Fri, 11 Feb 2000 23:24:21 +0100
Paul Koning wrote:
>
> Mok-Kong Shen wrote:
> >
> > No Brainer wrote:
> > >
> > > Does anyone know of a secure way to exchange public keys between two
> > > people via the Internet (e-mail) without using any other form of
> > > communication?
> > >
> > > Also, would the proposed system work if *someone* was intercepting and
> > > modifying the key exchanges?
> >
> > Perhaps you would need mechanisms like the web of trust. My knowledge
> > about your topic is rather meagre. Hopefully others would provide you
> > useful informations.
>
> No, that doesn't solve the problem. It merely moves it.
In a later follow-up (11 Feb 08:19:32+0100) I expressed myself more
precisely thus:
As far as I know, you could only 'approximately' not 'absolutely'
solve your problem, ...........
M. K. Shen
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Eurocrypt 2000
Date: 11 Feb 2000 22:03:20 GMT
Eurocrypt 2000 <[EMAIL PROTECTED]> wrote:
> A provisional program (list of accepted papers), and all
> registration details and accommodation information can now
> be found on the conference web site:
> http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/
One title leaps out at me :
"Cox-Rower Architecture for Fast Parallel Montgomery Multiplication"
Can't wait to read that one! :-)
-David (a 3 seat)
also "How to Break a Practical MIX and Design a New One" - given the
authors, wonder if it has anything to do with subliminal channels??
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Bounding (p-1)(q-1) given only knowledge of pq
Date: Fri, 11 Feb 2000 12:52:58 -0000
Actually in general there will be 2^1024, and in particular
it is the general assumption that the best way to do RSA is
to use primes of the same length, so for a 1024 bit modulus,
each of the primes cannot be less than 2^512+1 and so p-1
cannot be less than 2^512, (2^512)^2 is 2^1024. You also
seem to have ignored the upper bound of pq which puts a
severe cap on the possible values.
What I posted is simply a first revision, and while it is
not of too much use, there are situations where it will be
of use. I am also working on achieving better p and q
estimates.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Newbie Encrypt question
Date: Fri, 11 Feb 2000 13:01:54 -0000
Well, if you want something secure, go to the AES pages
(search for AES it should come up, I don't have the link
available to me right now) and pick any of the finalists,
they have very complete descriptions, analysis, test
vectors, and if you want to check to see how your code looks
against the pros the source code also.
Joe
<[EMAIL PROTECTED]> wrote in message
news:881obf$nbr$[EMAIL PROTECTED]...
> So the general response from my question is that the crypt
I was
> planning on using is very very weak. I thought that the
standard 56bit
> key encryption (which was cracked) was based on this
theory though?
> Even though it is no longer considered good anymore, it
was at one point
> and I thought it would be good enough for me.
>
> So am I wrong in assuming that the 56bit key encription
standard was
> based on shifting/xoring?
>
> And last but not least, what do you guys suggest using
instead. Keep in
> mind I want to code it myself as opposed to using/buying
an ocx.
>
> Thanks again for all the help
>
> > I'll note, however, that anytime you store ANYTHING that
verifies
> > entry of the correct password, you're giving information
away to an
> > attacker, making it easier to break your encryption.
OTOH, the form
> > of encryption you're suggesting is so weak that this
doesn't really
> > matter in any case -- it can be broken in a fraction of
a second on a
> > modern computer. In fact, with my old 386/20, it still
only took a
> > second or two to break as a general rule.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Fri, 11 Feb 2000 23:58:35 +0100
zapzing wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Mok-Kong Shen wrote:
> > >
> > > Ian Clarke wrote:
> > > >
> > >
> > > > The algorithm is simple, I take the initial data, and XOR each
> byte with
> > > > the previous byte (the first byte is left unchanged). This moves
> > > > forward through the string compounding the XOR at each stage (ie.
> each
> > > > byte is actually XORd with all previous bytes).
> > > >
> > > > The following piece of java does this: (Data is in char[] strC):
> > > >
> > > > for (int x=1; x<strC.length; x++)
> > > > {
> > > > strC[x] ^= strC[x-1];
> > > > }
> > >
> > > This is a form of what is in classical terminology termed auto-key
> > > encryption. One can simply try all possible values of the first byte
> > > to decrypt.
> >
> > Addendum: In the present special form, the 'key' is known, namely
> > the first byte.
> It does seem as if it could be done better.
> What if one used a reasonably large-ish block,
> encrypted the data in a known key, then split
> the block into first half and last half,
> wouldn't that do it? Wouldn't it help if
> random noise were included in the block?
Yes. In my humble opinion using larger units than bytes and a
pseudo-random value as 'key' should perform much better. In fact,
with 32-bit units I used auto-key processing as one component (among
others) in my algorithm WEAK3-EX. See my web page. There each block
has twenty 32-bit units. In each round a pseudo-random 32-bit value
is used as the key for auto-key processing from left to right and
then another pseudo-random 32 value is used for processing from
right to left. (The purpose is to 'diffuse' the informations contained
in the individual 32-bit words to the others.)
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Fri, 11 Feb 2000 23:58:55 +0100
Jerry Coffin wrote:
>
> [EMAIL PROTECTED] says...
> >
> > In an attempt to split data into several parts in such a way that each
> > part would be useless without the others, I came up with a simple
> > algorithm which I would like to expose to public scrutiny.
>
> Unless I'm missing something, this doesn't really qualify as
> encryption at all, but merely obfuscation. IOW, there's no key
> involved -- there's only a deterministic algorithm, and the only way
> you get any security at all is if the algorithm is secret. Generally
> speaking, that's considered an untenable assumption.
You are right. A correct auto-key encipherment should have a
secret 'key'. (In what was described by the original poster, however,
the 'key' is known!! cf. my follow-up.)
M. K. Shen
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: help DES encryption
Date: Fri, 11 Feb 2000 17:34:37 -0500
> mati wrote:
>
> > i am trying to implement the DES algorithm. I have use the des-how-to by
> > Matthew Fischer. I have completed the coding but it doesn't give me the good
> > result.
> >
> > Could someone provide me DES encryption examples with step by step results
> > (subkeys, R[i], L[i], etc.) in order to locate the problems?
NIST publishes a book that spells out a detailed set of validation
procedures, including some that will help isolate problems.
It's NIST Special Publication 800-17, "Modes of Operation Validation
System
(MOVS): Requirements and Procedures". I don't know if it's free (I
think I
got mine for the asking).
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Date: Fri, 11 Feb 2000 17:32:17 -0500
Scott Fluhrer wrote:
>
> Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > It appears to me that when using most block cyphers in OFB mode, there
> > will exist both weak keys (keys where there exists no period anywhere
> > near 2^n in length), and - for the vast mayority of keys - there
> > will be weak IVs (IVs that happen to hit on a shorter-than normal
> > cycle).
> >
> > I am interested to learn about what efforts (if any) have been made
> > to avoid these problems in block cyphers in OFB mode.
> Well, one obvious approach would be to add in a step counter after every
> encryption step. That is, (if X(n) is the internal state at step n), turn:
>
> X(n+1) = Encrypt( X(n) )
>
> into
>
> X(n+1) = Encrypt( X(n) ) + n
>
> where the above + is either xor, or addition modulo the block size.
> Then, cycles are impossible (if X(n) = X(m) for some n!=m, then
> X(n+1) != X(m+1) )
Of course that's not true.
In OFB, you have a cycle of length k if E(X(k-1)) == X(0).
In your scheme, you have a cycle of length k if E(X(k-1)) + n == X(0).
It seems plausible that the average cycle length is no worse for
your scheme than for OFB, but I see no reason to believe it is longer.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Somebody is jamming my communications -- this has been happening at
Date: Fri, 11 Feb 2000 17:35:40 -0500
"Douglas A. Gwyn" wrote:
>
> "-=HaVoC=--" wrote:
> > "Markku J. Saarelainen" wrote:
> > > I suppose the CIA / NSA has initiated the information operation ...
> > Yeah, sounds like the are on to you pretty bad. I would suggest ...
> > Also, if your house looks faces a street, you may wanna put foil over
> > the windows and open a small hole for surveillance.
>
> And when he goes outdoors, he should wear a tinfoil hat to block
> the CIA's mind control beams...
Why? How could you tell the difference?
paul
------------------------------
From: "Brian Hetrick" <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Fri, 11 Feb 2000 23:06:38 GMT
"Sander Vesik" wrote...
> How much does it cost to have a druggy go and get himself set up as
> a notary using false ID?
>
> Get a fresh asian immigrant / inner city youth to get the notary
> papers and then sell them to me?
>
> > So at least you have a collection of photographs of the person(s)
> > involved in the fraud, at least if the fraud is detected within
> > five years of it starting.
>
> Which are probably no good. It helps only against a very small and
> very undetermined adversary.
<snip>
> Photo on file is not such a good advantage. It just discourages
> those who have no determination.
Sigh. Incidentally, there are no "notary papers."
Can the Thawte "web of trust" be subverted? Of course.
But the question is not whether the Thawte "web of trust" gives
perfect assurance of identity. The question is whether the Thawte
"web of trust" is significantly more vulnerable than the alternatives.
The scenarios presented so far for subverting the Thawte "web of
trust" involve some large number of unscrupulous persons deliberately
infiltrating the "web of trust" while presenting innocuous cover
activities over multiple years. Given labor cost equivalents of
$25,000/year, the described scenario involves a minimum of $625,000 in
actual or opportunity costs before the conspirators become
untraceable. The result is a digital ID owned by some other person
than the person identified.
Given that you are buying criminal activity -- not just one criminal
act, but ongoing activity, in particular maintaining secrecy of a
prior criminal act -- however, I suspect the costs are much greater
than $25,000 per conspirator per year, and so the price tag of this
attack is larger than $625,000. But let's take $625,000 as a low-ball
estimate for the cost of subverting the Thawte "web of trust."
I suspect you would not have to look far to find someone willing to
sell their perfectly valid identity for a lot less than $625,000,
regardless of what they suspect or imagine the long-term consequences
to be.
I suspect it would cost a lot less than $625,000 to steal someone's
identity in a more usual way, and have that stolen identity certified
by a CA in the normal way.
I suspect it would cost a lot less than $625,000 to bribe or torture a
clerk at a CA into issuing a certificate for a fabricated identity.
I suspect it would cost less than $625,000 to obtain financing to set
up your own commercial CA which would be subverted from the start.
That an "adversary" is "determined" does not make him or her either
stupid or irrational. Can the "web of trust" be subverted? Yes, of
course. It is made up of things with physical realities, and can be
tricked, bribed, or bludgeoned into submission. Is the "web of trust"
an additional vulnerability over the alternatives? Yes, of course --
since it is there, it is an additional vulnerability. But the
question is whether the "web of trust" is a larger vulnerability than
those shared with the alternatives. The answer, so far, appears to be
"no." There are easier targets that give the same result.
------------------------------
** 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
******************************
