Cryptography-Digest Digest #375, Volume #9       Sun, 11 Apr 99 19:13:04 EDT

Contents:
  Re: True Randomness & The Law Of Large Numbers ("Franzen")
  Re: credit card encryption? ([EMAIL PROTECTED])
  Re: True Randomness & The Law Of Large Numbers (R. Knauer)
  Re: Epson digital camera image authentication (Xcott Craver)
  Re: Can someone think this through, please.  (PGP) (Norm I. Leaky)
  Re: Not a PGP Expert ([EMAIL PROTECTED])
  Re: Are LFSR's codebook rngs? ("Douglas A. Gwyn")
  Re: True Randomness & The Law Of Large Numbers ("Franzen")
  Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
  Re: Can someone think this through, please.  (PGP) (Jerry Coffin)
  Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
  Re: tops9720.zip source code for "Topsecret" ([EMAIL PROTECTED])
  Re: Epson digital camera image authentication (David R Brooks)
  Re: Comments to DOJ re NICS (Erik)

----------------------------------------------------------------------------

From: "Franzen" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Sun, 11 Apr 1999 12:37:08 -0500

On Sun, 11 Apr 1999 02:31:10 -0500, "Franzen" <[EMAIL PROTECTED]>
wrote:

>>My most expected head count is 500,335, or its complement 499,665.

Bob Knauer <[EMAIL PROTECTED]> replied Sunday, April 11, 1999
at 5:11 AM:

>Most expected head count is 500,000.

Well, you said it out loud. Let us see if you can live with your
assertion.

1. I refer you to a chi-square table in any standard math reference.
Go to the 0.5 probability column in the middle of that table. Do you
see a zero chi-square sum anywhere in that column. My table starts
with .45 at one degree of freedom, and the listed sums increase with
each added degree of freedom.

You do know how to calculate chi-square sums? The sum of
((Achieved heads - EV heads)^2)/EV heads. You are saying (and
someone else seems to agree with you at the moment) 2*
(((500,000 - 500,000)^2)/500,000) = (0.225 + 0.225).

2. Assume for the moment the chi-square table is invalid and your
assertion is correct. Assume further I have tossed 999,999 times
and achieved 499,999 heads. What is the independent probability of
my getting a head on the one millionth toss using your 1-bit bias
assumptions? Can you see the characteristic of independence going
right out the window using your 1-bit bias definition.

What we are discussing here is the very core of your "position." I
think it very worthwhile getting straight here before moving on.

---
Douglas McLean




------------------------------

From: [EMAIL PROTECTED]
Subject: Re: credit card encryption?
Date: 11 Apr 1999 18:03:58 GMT

Probably DES.

>Hi,
>  what is the encryption method of credit card used in bank?
>thanks

------------------------------

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Sun, 11 Apr 1999 18:21:57 GMT
Reply-To: [EMAIL PROTECTED]

On Sun, 11 Apr 1999 12:37:08 -0500, "Franzen" <[EMAIL PROTECTED]>
wrote:

>1. I refer you to a chi-square table in any standard math reference.

[snip]

Chi Square is a statistic that tests variances. Variances are not the
same as biases. Bias is a deviation from the mean which is related to
the first moment of a distribution, whereas variance is related to the
second moment of a distribution. They are fundamentally different
quantities, just as the center of mass and the moment of inertia are
fundamentally different quantites.

Perhaps you would benefit from a reading of the elementary book on
statistics by Mario Triola. He discusses Chi Square in detail. I never
could figure out why the poster who recommended Triola ever suggested
Chi Square with regard to non-randomness tests when there are more
direct estimates of deviation from normality.

Bob Knauer

"The contagious people of Washington have stood firm against
diversity during this long period of increment weather."
- Marion Barry, Mayor of  Washington DC


------------------------------

From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Epson digital camera image authentication
Date: 11 Apr 1999 19:32:31 GMT

In article <[EMAIL PROTECTED]>, Paul Rubin <[EMAIL PROTECTED]> wrote:

>Epson's PhotoPC 700 and 750Z digital cameras apparently put some
>kind of authentication code into the .jpg output that can be used
>with an external program to authenticate the image. 
>
>I wonder how many days it will be before somebody cracks this?  

        Or until someone takes a picture with it, adds Bill Clinton,
        prints it out wall-size, and takes a picture of it again?

                                                        -Caj

        [Who will gladly provide expert testimony of the watermarking 
        technology's validity, just for the havoc it will cause.]

------------------------------

From: [EMAIL PROTECTED] (Norm I. Leaky)
Subject: Re: Can someone think this through, please.  (PGP)
Date: Sun, 11 Apr 1999 20:00:02 GMT

Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:

>After all, the PGP software is the same and the public key is the same.
>Is it not true that if the same original message is used that you get
>the same encrypted message?

Did it ever occur to you to try it? Encrypt the same message twice with PGP
and see if you get the same output. You (very probably) won't, because the
key is randomly generated each time.
-- 
"Norm I. Leaky"     better known as [EMAIL PROTECTED]
 0123 4  56789      <- Use this key to decode my email address.
                    Fun & Free - http://www.5X5poker.com/

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Not a PGP Expert
Date: Sun, 11 Apr 1999 20:24:23 GMT

In article <[EMAIL PROTECTED]>,
  Geoff Thorpe <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Anthony Stephen Szopa wrote:
>
> > Can someone think this through, please.
>
> Sure.

//snip a good explanation of how PGP works

> than the "bit-twiddling" of the symmetric algorithms).
>
> Hope that helps?
>

Your explanation would help any normal person understand how PGP works and why
the proposed "attack" does not in fact exist, if not for the fact that Anthony
Stephen Szopa has a certain agenda of his own. Namely, he sells overpriced
snake-oil software pretending to offer real cryptographic strength through his
web site at www.ciphille.org. Explaining to him why PGP works or from where it
derives its strength is like explaining why Windows is flawed to a Microsoft
programmer; he or she knows that you are right, but merely wants to spread FUD
(Fear, Uncertainty, and Doubt) in the minds of others.

> Cheers,
> ME
>
>

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Are LFSR's codebook rngs?
Date: Sun, 11 Apr 1999 20:30:35 GMT

[EMAIL PROTECTED] wrote:
> One question though... How do you seed or start a LFSR properly?

It's known as the "initial fill", and depends on the system.
That can be considered part of the "key".

------------------------------

From: "Franzen" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Sun, 11 Apr 1999 15:35:31 -0500

Date: Bob Knauer  <[EMAIL PROTECTED]> wrote Sunday, April 11,
1999 at 1:21 PM:

>Chi Square is a statistic that tests variances. Variances are not the
>same as biases.
>
> Bias is a deviation from the mean which is related to
>the first moment of a distribution, whereas variance is related to the
>second moment of a distribution.

I prefer Beethoven's fifth myself.

>They are fundamentally different quantities, just as the center of
>mass and the moment of inertia are fundamentally different quantites.
>
>Perhaps you would benefit from a reading of the elementary book on
>statistics by Mario Triola. He discusses Chi Square in detail. I never
>could figure out why the poster who recommended Triola ever suggested
>Chi Square with regard to non-randomness tests when there are more
>direct estimates of deviation from normality.

Perhaps we could both benefit from sticking to the point we are at. You
assert if I flip a fair coin one million times, my single most probable
result will be 500,000 heads. By your prior arguments, you also appear
to believe it is the most desirable result also.

I assert to you that the chi-square table (derived from the incomplete
Gamma fuction) is the most accurate and reliable predictor of the number
of heads expected each and every one million tosses.

In your final sentence above you assert there are more direct estimates
of expected deviation. I assume you mean predictors such as the Poissan
approximation. It may be more direct, but it will lead to approximately
the same answer if used correctly. It will not be as accurate because
it is an approximation.

For people looking in on this thread, there is a fairly easy way to check
out who is on the correct side of this argument. It does not require
flipping a coin one million times!

Start flipping a coin and recording the heads and tails. After every two
flips count the accumulated heads. Whenever the accumulated heads are
exactly one half the total flips, make a check mark.

See if your check marks become rarer as your flip total increases. You
decide when you have flipped enough.

If your check marks appear with continuing regularity, Bob Knauer is
correct. I assure you I will be properly chagrined in that case. What-
ever happens in your particular experiment, I would like to hear about
its result.

---
Douglas McLean




------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Sun, 11 Apr 1999 20:42:42 GMT

"R. Knauer" wrote:
> I never could figure out why the poster who recommended Triola ever
> suggested Chi Square with regard to non-randomness tests when there
> are more direct estimates of deviation from normality.

Perhaps because it had nothing to do with "normality".
Pearson's chi-square statistic measures the difference between
observations and theoretical predictions, with no assumption
about the underlying distribution.  It is closed related to
Friedman's "index of coincidence".  Pearson's chi-square doesn't
work too well when there are fewer than about five observations
in a category, but Kullback's information statistic does, and
twice that statistic has asymptotically a chi-square distribution
(not the same as Pearson's statistic) with the same number of d.f.,
which means that it can be related to confidence or significance.
I mentioned Pearson's chi-square statistic instead of Kullback's
merely because it is much better known, being taught in nearly
every course that discusses data fitting.

------------------------------

From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Can someone think this through, please.  (PGP)
Date: Sun, 11 Apr 1999 14:50:40 -0600

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...

[ ... ] 

> Can the NSA or anyone else just take one of these encrypted messages and
> read the first byte from the encrypted message then using the same PGP
> software and the same public key simply enter one at a time all possible
> one byte input until they get the same output for the first byte and
> conclude that this must be the same input entered by this one message
> sender.

No.

> Is it not true that if the same original message is used that you get
> the same encrypted message?  

No -- a new IDEA session key is generated for each message you 
encrypt.

> Then does it follow that if you use the
> same first byte from the original message that you get the same output
> from this first byte? 

Each of the first eight bytes of output depends on all of the first 
eight bytes of input.  There are approximately 2^56 different sets of 
the first 8 bytes of input that will result in the correct first byte 
of output.

To summarize:
1) You can't normally use the same IDEA key for multiple PGP sessions.
2) If you could, you still couldn't work with one byte at a time.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Sun, 11 Apr 1999 21:52:59 GMT

"R. Knauer" wrote:
> On Sun, 11 Apr 1999 12:29:08 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
> >If it is a "consensus", then it's an uninformed one, since the
> >definition you gave was of an unrealizable system.
> It was synthesized from the prevailing consensus of experts here on
> sci.crypt.

Excuse me, but whoever came up with the following is no expert:

> It is the specification for a flat distribution of
> finite integers, ...

> >If you think that there is agreement on your "specification",
> >you haven't been paying attention, *especially* to recent discussions.
> I have been paying close attention, so much so that I have been
> challenging every assertion which runs counter to ...

Then there is not a consensus, since, as you say, several posters
have disagreed with your position.

> If I use the term "PRNG", then I use it correctly
> to signify a deterministic process. Not all deterministic processes
> are computer algorithms. Classical physical processes are also
> deterministic.

That's not what "pseudo-random" means in the established technical
literature.  Another poster, Herman Rubin, explained it thusly:
        Pseudo-random is used, at least in the statistical and
        simulation literature, to refer to deterministically
        generated numbers designed to imitate random numbers,
        generally equidistributed and independent.
(He used "deterministic" differently from thw way you just did.)
The important aspect of pseudo-random numbers is that they are
intentionally used *in place of* actual random numbers, as a
matter of convenience, for example in computer simulations, and
are generated by an algorithm that is completely known and
predictable.  Even if hardware RNGs were commonplace, there would
still be a major r�le for pseudo-random number generation in
simulations, because they are *reproducible* (so an experiment
can be re-run and examined in more detail).
Random physical processes are emphatically *not* "pseudo-random".

> >To the contrary, the UBP was one of the suggested meaningful
> >formulations (models) for what "TRNG" might denote.
> I just said that. Read my exact words, which are verbatim with my
> original post:
> For example, to date no one has seriously defended the uniform
> Bernoulli process although it has been suggested as a model for a
> TRNG, and is implicitly references in the form of the "fair coin
> toss". I suspect that is because people know that it is impossible to
> build a classical device which has p = q = 1/2. Anything other than
> that and you do not have a UBP, which means you cannot meet the TRNG
> specification.

And that is precisely what I responded to, thusly:
> >To the contrary, the UBP was one of the suggested meaningful
> >formulations (models) for what "TRNG" might denote.
Plus additional commentary that you didn't see fit to reproduce:
> >Whether one can actually construct a TRNG is a separate question
> >from what is *meant* by "TRNG".  Certainly, if one can show that
> >the "meaning" is such as to imply nonexistence, that would be
> >a fatal flaw, as with the definition you gave in terms of
> >uniform distribution over all integers.  However, it is
> >actually not terribly hard to approximate ideal coin flips so
> >closely that no tests are able to tell the difference.  The
> >thermal-noise based random bit generators on some commercial
> >crypto chips do this already.

How is that not a "serious defense of the UBP"?  Defining
"TRNG" in terms of a UBP is infinitely better than your attempt
in terms of a uniform distribution over all integers.

> >Reverse diode noise is a classical thermal, not quantum, effect.
> >exp(-kT) and all that.
> Reverse diode Shot Noise is quantum in nature.

You didn't say "shot noise", you said "reverse diode noise";
thermal noise predominates under normal circumstances.
So far as I know, nobody has created a reliable random-bit
generator based on shot noise, in a commercial product.
(If they have, I would appreciate hearing how they did it.)

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: tops9720.zip source code for "Topsecret"
Date: Sun, 11 Apr 1999 21:40:36 GMT

In article <[EMAIL PROTECTED]>,
  Peter Gunn <[EMAIL PROTECTED]> wrote:
> Ryan Phillips wrote:
>
> > Snakeoil?
>
> Since the sender never stated any claims about what the
> prog was supposed to do, other than simply being an
> "encryption program", it would be hard to label it as
> Snake Oil, well, not high quality Snake Oil anyway.
>
> I think the  "encryption" takes place in as follows....
>
>     C[i]=I[i]^n^l^K1[n]^K2[n]^O[i]
>
> where C is ciphertext, I is input text,
> O is a 'pad' file, l is key length,
> n=i%l, K1 is the key, K2[i]==K1[i+1],
> K2[l-1]==0.
>
> So, K[n]=K1[n]^K2[n]^n, O[i] can be
> dropped since its intended to be used
> for every encryption (its not a
> One Time Pad)... so, after XORing with
> O...
>
>     C[i]=I[i]^K[i%l]^l
>
> Now, this could be a One Time Pad, as
> long as l is less than the size of I
> (the key is bigger than the input file),
> and from the prog l is 0..63 so, I
> doubt this is the intention.
>
> So, I think this can be broken by a
> single plaintext attack, so you can
> remove I by XORing, then...
>
>     C[i]=K[i%l]^l
>
> So, no, I dont think this is Snake Oil,
> I think its something cheaper thats been
> bottled as snake oil :-)
>
> heehee
>
> PG.
>


 OK, I cheerfully take your criticism.  :)
 But now you have to put your programming where your mouth is.

 This is not a text only encryption. But if you want text encryption,
 this is what I recommend. 1)Compress file. 2) Encrypt more than
 once using Catalysts.
 Since the program is batch capable the tasks above will not be
 too difficult.
 Since you feel it is easy to crack, I presume you will not not
 take too long to publish and give me the actual EXE code, that
 will reliably and easily crack coded files even after following
 the program hints.
 Thanks for your comments. Please don't back off now. :)
 I welcome more comments from others.

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: [EMAIL PROTECTED] (David R Brooks)
Subject: Re: Epson digital camera image authentication
Date: Sun, 11 Apr 1999 22:39:07 GMT

[EMAIL PROTECTED] (Xcott Craver) wrote:

:In article <[EMAIL PROTECTED]>, Paul Rubin <[EMAIL PROTECTED]> wrote:
:
:>Epson's PhotoPC 700 and 750Z digital cameras apparently put some
:>kind of authentication code into the .jpg output that can be used
:>with an external program to authenticate the image. 
:>
:>I wonder how many days it will be before somebody cracks this?  
:
:       Or until someone takes a picture with it, adds Bill Clinton,
:       prints it out wall-size, and takes a picture of it again?
:
 In any event, surely all such a code can prove (assuming it's secure
- a big if) is that the picture was taken by *some* Epson camera. I
don't think the camera has a serial number, that goes in the file?
 Taken at *some* time & place, & not afterward modified. Not really
much use in Court, for example.

------------------------------

From: Erik <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.guns
Subject: Re: Comments to DOJ re NICS
Date: Sun, 11 Apr 1999 17:36:18 -0500


==============EB82631ABFC6EC3A6D313F9D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Paul Rubin wrote:

> In article <[EMAIL PROTECTED]>,
> Eric Williams  <[EMAIL PROTECTED]> wrote:
> >Yes, I was thinking of a MAC, thank you for pointing out the
> >difference.   A 64-bit MAC could be represented with about 12 readable
> >characters.  If you want to go to 128-bit (eg: MD5), you're up to about
> >26 (maybe a couple more if you throw in some check digits), but a
> >typical credit card verification involves about 20 digits, so that is
> >not much of a leap.
>
> Actually the scheme you suggested (encrypting a hash) isn't exactly
> a MAC in the usual sense, but the idea is the same.
>
> Credit card verifications involve the card number, expiration date,
> and amount going in one direction, and a 6-digit authorization code
> coming back.  Note that at most retailers these days, this is done
> automatically--the merchant swipes the card through a reader and keys
> in the amount.  The authorization code (if approved) is automatically
> printed on the ticket.  At places with no card reader, they normally
> don't phone in the card numbers unless the transaction is over a
> certain amount.  (Because of the increased exposure, they pay a higher
> fee to the card company than if they had a card reader.)
>
> In your system, the stuff going to the DOJ in place of the card number
> and expiration date would be *all* the data from the form (name, address,
> etc.) plus the MAC.  Also, in the case of a field audit of a dealer,
> they'd want to verify a whole stack of registrations and not just
> a single one.  So it's just not workable unless the data is machine
> readable.  But if it is, it has to get signed by a DOJ computer, so
> there's no guarantee that the data wouldn't actually stay there.
>
> >I think a MAC would be sufficient for this application, the key (or
> >keys) would remain with DOJ.  Since the government is the only party who
> >is interested in generating and verifying signatures, I don't think the
> >complexity of a public key system is necessary.
>
> I guess that's plausible.  It means though that field auditors have
> to carry equipment containing the secret key.  If the auditors can be
> robbed or bribed, the key is vulnerable.

That's not even needed.  Network computers togeter to search all possible
keys untill you Crack the code.
Simple...we can even do it with home computers... it's  going to to take a
considerable amount of time (hey it's information worth having right?)  but
if you get enough computers networked and searching specified segments of
code you can do it ... once you have the key the database is comprimised.
And everyone's privacy is lost.  Hackers do this all the time...Cryptography
Research, Advanced Wireless
 Tech INC. just have better toys and can do it faster.

Emphasis added bellow.
>From :  http://www.cryptography.com/des/index.html
             DES, the most widely used
             commercial encryption algorithm, protects financial transactions

             and electronic communications worldwide.  Developed by the
             US Government and IBM in the 1970s, DES is the
             government-approved symmetric algorithm for protecting
             sensitive information.

             The DES algorithm uses a 56-bit encryption key, meaning that
             there are 72,057,594,037,927,936 possible keys. The DES
             Key Search Project developed specially designed hardware and
             software to search 90 billion keys per second, determining the
             key and winning the $10,000 RSA DES Challenge after
             searching for 56 hours.


One last thing.... If the government is morally corrupt enough to violate
thier own laws,  then why trust them with letting us know WHAT they are doing
with this database.?  I hate this idea, I remember a sceene in a movie where
one military comander says "go to town hall, there they have a list of people
who own weapons, we go after these people first" ..... or something like
that.. it was a long time ago.


==============EB82631ABFC6EC3A6D313F9D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Paul Rubin wrote:
<blockquote TYPE=CITE>In article &lt;[EMAIL PROTECTED]>,
<br>Eric Williams&nbsp; &lt;[EMAIL PROTECTED]> wrote:
<br>>Yes, I was thinking of a MAC, thank you for pointing out the
<br>>difference.&nbsp;&nbsp; A 64-bit MAC could be represented with about
12 readable
<br>>characters.&nbsp; If you want to go to 128-bit (eg: MD5), you're up
to about
<br>>26 (maybe a couple more if you throw in some check digits), but a
<br>>typical credit card verification involves about 20 digits, so that
is
<br>>not much of a leap.
<p>Actually the scheme you suggested (encrypting a hash) isn't exactly
<br>a MAC in the usual sense, but the idea is the same.
<p>Credit card verifications involve the card number, expiration date,
<br>and amount going in one direction, and a 6-digit authorization code
<br>coming back.&nbsp; Note that at most retailers these days, this is
done
<br>automatically--the merchant swipes the card through a reader and keys
<br>in the amount.&nbsp; The authorization code (if approved) is automatically
<br>printed on the ticket.&nbsp; At places with no card reader, they normally
<br>don't phone in the card numbers unless the transaction is over a
<br>certain amount.&nbsp; (Because of the increased exposure, they pay
a higher
<br>fee to the card company than if they had a card reader.)
<p>In your system, the stuff going to the DOJ in place of the card number
<br>and expiration date would be *all* the data from the form (name, address,
<br>etc.) plus the MAC.&nbsp; Also, in the case of a field audit of a dealer,
<br>they'd want to verify a whole stack of registrations and not just
<br>a single one.&nbsp; So it's just not workable unless the data is machine
<br>readable.&nbsp; But if it is, it has to get signed by a DOJ computer,
so
<br>there's no guarantee that the data wouldn't actually stay there.
<p>>I think a MAC would be sufficient for this application, the key (or
<br>>keys) would remain with DOJ.&nbsp; Since the government is the only
party who
<br>>is interested in generating and verifying signatures, I don't think
the
<br>>complexity of a public key system is necessary.
<p>I guess that's plausible.&nbsp; It means though that field auditors
have
<br>to carry equipment containing the secret key.&nbsp; If the auditors
can be
<br>robbed or bribed, the key is vulnerable.</blockquote>

<p><br>That's not even needed.&nbsp; Network computers togeter to search
all possible keys untill you Crack the code.
<br>Simple...we can even do it with home computers... it's&nbsp; going
to to take a considerable amount of time (hey it's information worth having
right?)&nbsp; but if you get enough computers networked and searching specified
segments of code you can do it ... once you have the key the database is
comprimised.&nbsp; And everyone's privacy is lost.&nbsp; Hackers do this
all the time...Cryptography Research, Advanced Wireless
<br>&nbsp;Tech INC. just have better toys and can do it faster.
<p>Emphasis added bellow.
<br>From :&nbsp; <A 
HREF="http://www.cryptography.com/des/index.html">http://www.cryptography.com/des/index.html</A>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DES, the most widely used
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
commercial encryption algorithm, protects financial transactions
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and electronic communications worldwide.&nbsp; Developed by the
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<b><u>US Government</u></b> and IBM in the 1970s, DES is the
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
government-approved symmetric algorithm for protecting
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<b><u>sensitive information</u></b>.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The DES algorithm uses a 56-bit encryption key, meaning that
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
there are 72,057,594,037,927,936 possible keys. The DES
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Search Project developed specially designed hardware and
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
software to search 90 billion keys per second, determining the
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
key and winning the $10,000 RSA DES Challenge after
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
searching for 56 hours.
<br>&nbsp;
<p>One last thing.... If the government is morally corrupt enough to violate
thier own laws,&nbsp; then why trust them with letting us know WHAT they
are doing with this database.?&nbsp; I hate this idea, I remember a sceene
in a movie where one military comander says "go to town hall, there they
have a list of people who own weapons, we go after these people first"
..... or something like&nbsp; that.. it was a long time ago.
<br>&nbsp;</html>

==============EB82631ABFC6EC3A6D313F9D==


------------------------------


** 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
******************************

Reply via email to