Cryptography-Digest Digest #370, Volume #11 Mon, 20 Mar 00 15:13:01 EST
Contents:
generate a random number (Jesper Stocholm)
Re: Concerning UK publishes "impossible" decryption law (Richard Herring)
ScramDisk problem : storing PLAIN TEXT PASSPHRASE in the driver cache (jungle)
Re: PC-1, anyone ? (Kent Briggs)
Re: Concerning UK publishes "impossible" decryption law ("ÐRëÐÐ")
Re: Any Mathematicians Surnamed _Saint_-Germain? (John Savard)
Re: linux's /dev/random (Darren New)
Re: Improvement on Von Neumann compensator? (Herman Rubin)
Re: hardware errors (Mok-Kong Shen)
Re: Opinions? (Darren New)
Re: The Breaking of Cyber Patrol® 4 (Ichinin)
Re: Card shuffling (Scott Nelson)
Re: generating secure id numbers (Scott Nelson)
Re: DES Decryption Problem (James Muir)
Re: Cipher Contest (Mike Rosing)
Re: Quantum crypto flawed agains Mallory? (Mike Rosing)
Re: Improvement on Von Neumann compensator? (Mike Rosing)
Re: Big Float: square root (Mike Rosing)
Re: New Cryptanalysis of MARS and Serpent (John Savard)
RRI S-Box (Ichinin)
Re: The Breaking of Cyber Patrol® 4 (John Savard)
Re: Opinions? (John Savard)
Re: Opinions? (John Savard)
Re: encryption and decryption with elliptic curve cryptography (Mike Rosing)
Re: hardware errors (wtshaw)
Re: Concerning UK publishes "impossible" decryption law (wtshaw)
----------------------------------------------------------------------------
From: Jesper Stocholm <[EMAIL PROTECTED]>
Subject: generate a random number
Date: Mon, 20 Mar 2000 14:19:29 GMT
I use the Blum-Blum-shup / RSA CPRBG to construct random bitstrings.
However - these require usage of primes. But how do I generate these
primes - or the random bitstrings to make them from ? As far as I know,
using the system-clock degrades the security from 2^500 (or more) to
only 2^32 ... so I am reluctant to use that.
What are the algorithms for this ? Should I use a combination of user-
input and clock ... or ?
thanks
Jesper
--
http://stocholm.dk
MSN Messenger: [EMAIL PROTECTED]
- On Usenet I represent only myself
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Re: Concerning UK publishes "impossible" decryption law
Date: 20 Mar 2000 14:54:20 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, ÐRëÐÐ ([EMAIL PROTECTED]) wrote:
> an electric magnet is not so hard to make or get hold of, its harmless
> unless power is given to it, and when powered, can be easily be strong
> enough to destroy data an the disks.
I find that difficult to believe Can you provide figures to
justify your assertion?
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: ScramDisk problem : storing PLAIN TEXT PASSPHRASE in the driver cache
Date: Mon, 20 Mar 2000 15:30:56 GMT
Aman, has this problem been addressed ?
it has been documented in the past that serious security problem exist in the
current version of the scramdisk ...
the reported problem : storing PLAIN TEXT PASSPHRASE in the driver cache ...
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: PC-1, anyone ?
Date: Mon, 20 Mar 2000 15:31:37 GMT
Christoph Weber-Fahr wrote:
> Hi,
>
> in a project I stumbled upon a piece of software using
> Alexander Pukall's PC1 (Pukall Cipher 1).
>
> I'm trying to form an opinion on this. Abusing deja to some degree I found
> a number of hints vaguely linking it to RC4, but nothing precise.
FYI: I've been referring to my own RC4 implementations as PC1 in my encryption
applications: Puffer, CryptaPix, & Order Maven. Mine was short for Puffer Cipher
1, going back to 1996. I know nothing about this Pukall cipher, however.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: "ÐRëÐÐ" <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Re: Concerning UK publishes "impossible" decryption law
Date: Tue, 21 Mar 2000 02:40:33 +1100
well, if configured right to use power from your power pack, it might be
strong enough to damage your disks, it shouldn't turn on unless the right
switch is triggered to allow it to have power, but as I amended, its useless
as someone had stated that the LEOs will remove everything before turning it
on. so ignore this part of my thread.
--
"Oh GOD, Please save me from your followers"
more of my ramblings can be found at http://oakgrove.mainpage.net
"Man is a part of nature, not apart from nature"
anti spam, remove 'nospam' to mail me
ICQ:16544782
"Richard Herring" <[EMAIL PROTECTED]> wrote in message
news:8b5e2s$f9d$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, ÐRëÐÐ ([EMAIL PROTECTED])
wrote:
> > an electric magnet is not so hard to make or get hold of, its harmless
> > unless power is given to it, and when powered, can be easily be strong
> > enough to destroy data an the disks.
>
> I find that difficult to believe Can you provide figures to
> justify your assertion?
>
> --
> Richard Herring | <[EMAIL PROTECTED]>
>
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Any Mathematicians Surnamed _Saint_-Germain?
Date: Mon, 20 Mar 2000 09:49:30 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>You "just don't get it", do you. It would honor her more to treat
>her as a peer.
That I agree with. It's the rush to judge that she is not being so
treated, and the ease with which sweeping, severe condemnations of the
mathematical community as a whole are made, that I'm uncomfortable
with. (Although, noting that we don't even talk about I. J. Good
graphs is a legitimate piece of evidence.)
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: linux's /dev/random
Date: Mon, 20 Mar 2000 17:13:31 GMT
Lincoln Yeoh wrote:
> But isn't a held down key a random event itself? So it should be worth at
> least more than 0 ;).
I would think it's worth less than one bit. It's a 1/0 as to whether it's
still held down, but once released, it can't continue to auto-repeat.
--
Darren New / Senior MTS / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Improvement on Von Neumann compensator?
Date: 20 Mar 2000 12:14:52 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> Recently I tried to use a Geiger counter to produce random values,
>> only to find that the event rate seemed to vary much more than I
>> expected. With the tube positioned close to a lantern mantle, the
>Probably a very dumb question: Is it possible with today's techniques
>to get random values out of Brownian motions?
>M. K. Shen
Brownian motion is a physically unrealizable continuous
process. Keep in mind that ONE real number with a known
continuous distribution produces an infinite number of
random bits.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardware errors
Date: Mon, 20 Mar 2000 18:28:50 +0100
[EMAIL PROTECTED] wrote:
>
> I s'pose an even rarer event which be when a message is being
> encrypted, and the hardware error changes the value in a bit register
> such that the value of one of the keys is altered, and the message is
> enciphered with a randomly incorrect key, and is subsequently
> indecipherable by anyone. This is presuambly a higher probability of
> such an event affecting a calcualtion if, as Joe suggested, there is
> iterative calculation going on.
One of the standard technique I know of coping with hardware errors
is to employ duplicated hardware or triple hardware (for consensus).
It one needs that level of security, then it seems also to be
preferable to have different implementations of the algorithm
on these in order to protect against a further mode of potential
failure.
Having barely any knowledge in hardware, I always wonder how the
chip manufacturers check their products which are extremely complex
and minute entities. What is the rate that a defective chip passes
through the production controls? (It is known that even design
errors sometimes occured and escaped sophisticated systems aimed
to help the design engineers to ensure correctness.) Do I have
any practical (not expensive) means to check to some satisfactory
degree that the chip in my PC is o.k.?
M. K. Shen
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Opinions?
Date: Mon, 20 Mar 2000 17:27:53 GMT
Marc Howe wrote:
> For instance, a hurricane's wake may appear chaotic, but each branch, spec
> of dust, etc. had only a certain way it could react to the hurricane given
> its properties and the hurricane's properties.
No. That's what quantum effects are all about. It's just not true that each
spec of dust etc had only a certain way it could react.
--
Darren New / Senior MTS / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The Breaking of Cyber Patrol® 4
Date: Fri, 17 Mar 2000 19:12:55 +0100
John Savard wrote:
> Had they asked that of a judge in a Swedish court, promptly erasing
> these records would constitute contempt. Asking a judge in a U.S.
> court to issue such an order, however, is something of a waste of
> time. Although Sweden is a signatory to international copyright law
> treaties, the world we live in isn't quite _that_ borderless just yet.
*What* exactly are they claiming here?
How does bypassing a complete program affect copyright, from what i've
heard the program only allow you to _bypass_ cyber patrol - _not_ copy
it.
Any more links/references to where i can find more info on this?
(names, documents etc.)
Thanks,
Glenn
Sweden
(This sounds as insane as thinking that l0phtcrack allow you to
pirate Windows NT)
_________________
(Yes - my email adress is real)
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Card shuffling
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Mar 2000 17:49:48 GMT
On Sat, 18 Mar 2000 Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
[edited]
>
>Does there exist any objective means to determine (or help to
>determine) the relative quality of shuffling or is one left to
>rely on pure subjectivity in deciding on that issue?
>
First you need to define "quality"
If a "quality" shuffle is one which interleaves the cards
exactly 1 for 1, then there's are many objective measures.
Here's a simple way to calculate one:
Split a deck into red and black piles.
Shuffle the two piles once.
Count the number of packets (groups of the same color)
This should be a number between 2 and 52
The higher the number, the higher the quality of the shuffle.
If a "quality" shuffle is one which introduces the maximum
amount of uncertainty into the deck, then it's much harder.
I'd guess the best is something like each packet being a
random number from 1 to 4, but the mechanics of shuffling
preclude certain possibilities so there's probably some sort
of weighting based on previous runs that needs to be included.
(It's more likely that you'll have smaller red packets after
bigger ones.) Note that smaller packets have fewer possible states,
but they allow more packets per deck, so there's actually less
variance in the amount of uncertainty than one would normally
suppose. A "reasonable" shuffle will add about 40 bits
of uncertainty to the deck. - Well, not exactly add,
but until we're very close to 226 bits, (log2(52!)) adding
is a very good approximation.
Using the above "packet" method, the best number is
probably in the 20-30 range. For human shufflers that's
probably a good enough measure, but for machines we need
to include the variance of the packets too. I.e. we need
to verify that the size of the packets actually changes
between shuffles.
As an aside, I consider myself a good shuffler.
I average about 35 packets with my normal "fast"
riffle shuffle.
Another measure of quality is how many cards stick together
after the final shuffle. For instance, order a deck and
shuffle it four times, then examine it. You will probably
notice that several of the cards are still in sequence.
(If the deck was completely random, more than 3 in sequence
would be extremely unlikely.) This "stickyness" has actually
been used by some bridge players to make educated guesses
as to the position of certain cards. I.e. if you hold
the King of hearts, and you remember that the King was
followed by the Ace last hand, then there's a good chance
the Ace of hearts is to your left. (Assuming of course
that the deck wasn't shuffled enough.)
Scott Nelson <[EMAIL PROTECTED]>
- Don't forget to vote on sci.crypt.random-numbers
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: generating secure id numbers
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Mar 2000 18:09:17 GMT
On Sun, 19 Mar 2000 22:51:38 GMT, [EMAIL PROTECTED] wrote:
>I want to generate a secure id based system
>containing unique identifiers for people yet
>generated in such a way that they would be
>particularly difficult to guess.
>
>Can I use a random number generator with a key
>and hash these to give encrypted id's ???
>
The problem with hashing the output of a random number
generator is that there's a chance that the ID's
won't be unique. You can minimize this by picking
an ID size that's large so the probability
of a repeat is essentially 0, but then the ID's are big.
The classic method is to encrypt a counter.
I suggest TEA (Tiny Encryption Algorithm),
though you could use any block encryption algorithm.
The advantages are;
All ID's are guaranteed unique,
It's possible to get the original number from the ID,
The ID's can be relatively small,
you only need to keep the key and the current count value.
An alternative is to generate the ID's at random
(or with a secure pseudo-random generator) and
keep track of all of them. This requires a lot
more storage, but has the advantage that the ID's
can be the minimum size.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: Re: DES Decryption Problem
Date: Mon, 20 Mar 2000 18:12:26 GMT
Let me try to explain it this way.
You should have a key schedule function which generates the 16 subkeys:
k[1], k[2], k[3] ... k[16].
To encrypt a message M you do this:
L[0]R[0] = IP(M)
L[1] = R[0]
R[1] = L[0] xor f( R[0], k[1] )
L[2] = R[1]
R[2] = L[1] xor f( R[1], k[2] )
L[3] = R[2]
R[3] = L[2] xor f( R[2], k[3] )
:
:
L[15] = R[14]
R[15] = L[14] xor f( R[14], k[15] )
R[16] = R[15] *** irregular swap ***
L[16] = L[15] xor f( R[15], k[16] ) *** irregular swap ***
C = FP(R[16]L[16])
To decrypt a ciphertext, C, you do this:
L[0]R[0] = IP(C)
L[1] = R[0]
R[1] = L[0] xor f( R[0], k[16] )
L[2] = R[1]
R[2] = L[1] xor f( R[1], k[15] )
L[3] = R[2]
R[3] = L[2] xor f( R[2], k[14] )
:
:
L[15] = R[14]
R[15] = L[14] xor f( R[14], k[2] )
R[16] = R[15] *** irregular swap ***
L[16] = L[15] xor f( R[15], k[1] ) *** irregular swap ***
M = FP(R[16]L[16])
Note that the only difference here is the order of the subkeys used in
the f function. That's the beauty of the design of DES. You do not
have to change any of the primitives to do decryption.
Specifically, in answer to your question, you do not have to change the
IP, or the S-boxes, or anything else.
I suspect your encryption process has a bug. You should check it
against test vectors. Check that:
DES_encrypt ( 4e6f772069732074 ) = 3fa40e8a984d4815
-James
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Mon, 20 Mar 2000 12:23:08 -0600
Adam Durana wrote:
>
> So ...
> Requirements:
> Block Cipher
> Reasonable/Justifiable resource usage.
>
> Anyone have a problem with those?
Looks pretty wide open to me. Put the emphasis on Justifiable, each
entry should have enough commentary to explain the design decisions
and point out the implementation of those decisions. If the number of
rounds is < 32 or ram space < 1k, it may not take much commentary, but
if the number of rounds >64 or ram space > 1M then more commentary would
be needed to move up the ranking.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Quantum crypto flawed agains Mallory?
Date: Mon, 20 Mar 2000 12:38:16 -0600
[EMAIL PROTECTED] wrote:
> From what I understood, Mitra's technique requires a shared key
> between the legitimate users. How could we exchange this shared key
> securely?
The basic idea is that Alice generates sets of coupled photons.
She captures one set and measures their polarity. The other set
goes to Bob. Bob measures the polarity of those he can capture.
Then Alice and Bob compare their measurements publicly. This is
the step that foils the man-in-the-middle. If comparison of each
photon pair which is caputured matches, then there's no way any
of the photons were disturbed. If the photons were disturbed, then
Bob's measurements wouldn't match at all with Alice's, and they
would know an active attack was in progress.
See the April issue of Scientific American for a really good
description with out any math. It goes into transporters on
Star Trek too, so it's a blast to read.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Improvement on Von Neumann compensator?
Date: Mon, 20 Mar 2000 13:02:20 -0600
Guy Macon wrote:
> Could I then conclude that the best algorithmic aproach to "improving"
> a bitstream that comes from radioactive decay or thermal noise random
> number generator (RNG) would be to make a pseudorandom bitstream using
> the best pseuodorandom generator available (PRNG) seeded with a seperate
> run of the RNG, then XOR the two together? Or is there some superior
> method of trying to remove unknown biases caused by the electronics?
A statistically acceptable method is to integrate. I've proven it
works.
Check out http://www.terracom.net/~eresrch and look for /dev/random.
It's based on strong math, and it works. What's wrong with that?
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Big Float: square root
Date: Mon, 20 Mar 2000 13:18:56 -0600
Mok-Kong Shen wrote:
>
> I am rather surprised by this, since Knuth's books are sort of
> bible in CS. Could you please supply some more information about the
> presumed trouble, giving the exact locations in the text, etc?
> Thanks.
I wouldn't be supprised if I did something wrong. It's under classical
algorithms, the division by multiple chunks. He shows that if the
bottom is > b/2 (where b is the chunks size) then you always get results
in the range 0..b-1. The idea is you can divide a 2 chunk piece by
a one chunk piece and get one chunk. The problem is that 2 chunks
are in the range 0...b^2-1, and that divided by b/2 ~= 2b. So you
get 1 bit in the next bin for b = 2^n, and that blows the algorithm.
I got the division routine to work now, and square root too. Don't
quite have #E computations working yet, but it may just be my
float_to_ascii
is busted. I need that for debugging anyway, so I'll be fixing that
for then next couple of evenings.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New Cryptanalysis of MARS and Serpent
Date: Mon, 20 Mar 2000 12:38:38 GMT
[EMAIL PROTECTED] (Bruce Schneier) wrote, in part:
>http://www.counterpane.com/mars-attacks.html
Can't resist a good pun, can you?
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: RRI S-Box
Date: Fri, 17 Mar 2000 21:11:36 +0100
Hithere.
Disect and comment:
http://www.geocities.com/ichinin/RRI_SBox.htm
It's just my theory on how an S-Box should be built:
- Key + passphrase dependent
- Modified by all the given inputs.
- One way hashing function for determining the next output.
No source code. Examples are... well; examples.
Comments welcome.
Regards,
Glenn
Sweden
_____________________
Crypto novice.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Breaking of Cyber Patrol® 4
Date: Mon, 20 Mar 2000 12:40:06 GMT
Ichinin <[EMAIL PROTECTED]> wrote, in part:
>How does bypassing a complete program affect copyright, from what i've
>heard the program only allow you to _bypass_ cyber patrol - _not_ copy
>it.
Well, copyright requires you to accept the license agreement, the
license agreement can forbid reverse engineering...
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Opinions?
Date: Mon, 20 Mar 2000 12:42:56 GMT
"Marc Howe" <[EMAIL PROTECTED]> wrote, in part:
>There is nothing that is truly random, correct?
That is a philosophical question. Current scientific belief is that
things involving quantum mechanics can be "truly random".
However, for cryptographic purposes, things like the physical rolling
of dice do offer important advantages over attempting to produce
random numbers by a mathematical pseudorandom process on a computer -
essentially, because the need of having a long unknown key as a
starting point is removed - and so such things are referred to as
truly random in this context to distinguish them from PRNG outputs.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Opinions?
Date: Mon, 20 Mar 2000 12:44:55 GMT
"Marc Howe" <[EMAIL PROTECTED]> wrote, in part:
>Certainly the intellect here is great! Discussion like this is one of the
>reasons to live.
Perhaps, but this particular subject is deprecated as a topic for
discussion in this newsgroup, as it leads around in circles. Perhaps
in sci.math they would object to it less, but I wouldn't really
encourage it.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: encryption and decryption with elliptic curve cryptography
Date: Mon, 20 Mar 2000 13:28:41 -0600
kingtim wrote:
>
> Please tell me simply how to do encryption and decryption with elliptic
> curve cryptography.
> and any web site about this topic.
Check out http://www.certicom.com and
http://www.manning.com/rosing
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: hardware errors
Date: Mon, 20 Mar 2000 13:02:56 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Having barely any knowledge in hardware, I always wonder how the
> chip manufacturers check their products which are extremely complex
> and minute entities. What is the rate that a defective chip passes
> through the production controls? (It is known that even design
> errors sometimes occured and escaped sophisticated systems aimed
> to help the design engineers to ensure correctness.) Do I have
> any practical (not expensive) means to check to some satisfactory
> degree that the chip in my PC is o.k.?
>
I remember a time when a whole shipment of 7490's would break into divide
by 8 instead of 10 above not too hot a temperature. As them were used to
sync clock rates at both ends of a system, when the complementary fair
both failed, the problem seemed to go away as they synced again....really
drove us up the wall for a while.
We were curious how these chips ever made it out of the factory in
Salvador. The answer was that if we wanted good testing, buy mil spec.
But, they did replace the chips, recall the lot, etc. Good testing never
shows up as a defective practive, but it does tend to be a necessary cost.
--
To see the results of GW Bush's shaddow, visit the Valley;
notice the miserable conditions he allows to fester.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,alt.privacy
Subject: Re: Concerning UK publishes "impossible" decryption law
Date: Mon, 20 Mar 2000 13:15:11 -0600
In article <[EMAIL PROTECTED]>, "ÐRëÐÐ" <[EMAIL PROTECTED]> wrote:
> well, if configured right to use power from your power pack, it might be
> strong enough to damage your disks, it shouldn't turn on unless the right
> switch is triggered to allow it to have power, but as I amended, its useless
> as someone had stated that the LEOs will remove everything before turning it
> on. so ignore this part of my thread.
>
A backup power system need not have a large battery. Consider that an
internal one would last just long enough for a graceful shutdown that
might be caused with line interruption. It should be not trick to arm a
sequence which could also purge data from certain storage media, a small
key data disk with only a few megs on it.
--
To see the results of GW Bush's shaddow, visit the Valley;
notice the miserable conditions he allows to fester.
------------------------------
** 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
******************************
