Cryptography-Digest Digest #885, Volume #10 Tue, 11 Jan 00 17:13:01 EST
Contents:
Re: Simple Encryption ... ("Derek Potter")
Re: Clearer (hopefully?) example of 1-1 problem. ("Gary")
A Post-Caribbean Update (JPeschel)
Re: Rijndael (was: Square?) (David Crick)
Re: Intel 82802 Random Number Generator (Mike Rosing)
Re: frequency analysis with homophones ([EMAIL PROTECTED])
Re: AES & satellite example (Frank Gifford)
Re: another newbie (James Felling)
Re: AES & satellite example (Doug Stell)
Re: Intel 810 chipset Random Number Generator (Michael Sierchio)
Re: Double transposition/playfair (John Savard)
Re: "1:1 adaptive huffman compression" doesn't work (Tim Tyler)
Re: AES & satellite example (John Savard)
Re: Question about public key encryption in Z*_n (David Wagner)
Re: "1:1 adaptive huffman compression" doesn't work (Tim Tyler)
Re: Questions about message digest functions (Tim Tyler)
Re: Anyone give any pointers? ("Derek")
Re: Double transposition/playfair (Jim Gillogly)
Re: Wagner et Al. (lordcow77)
----------------------------------------------------------------------------
From: "Derek Potter" <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Tue, 11 Jan 2000 17:36:23 -0000
"Anton Stiglic" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Koning wrote:
>
> > Derek Potter wrote:
> > >
> > > There are times when it would be cool (Ok, so
> > > you now know this is going to be one of *those*
> > > questions!) to be able to encrypt something not
> > > so much to stop it being read by third parties
> > > but to prove to the *recipient* that you have
> > > some information but you aren't prepared to
> > > divulge it *yet*.
> >
> > That's easy.
> >
> > Put the description in a text file, and sign it
> > with a "detached signature" (as PGP calls it).
> > Publish the signature. Keep the original
> > file secret.
> >
> > At some later time you can publish the text file,
> > and anyone can then verify that the previously
> > published signature is valid for that file.
> >
> > paul
>
> That doesn't work if you want to imediatly proove
> your knowledge, without letting people gain knowledge
> of what it is...
> It works if you don't care that everybody else figures
> out the answer when they are to be convinced that you
> know the answer.
Well, that *is* what I had in mind.
Frankly I can't see how it would be possible to
convince third parties that you had the answer
all along if a) they never get the means to find
it out, and b) the second party refuses to admit
that your answer is correct even though he knows
it is. (There must be a name for problems like
that, where "Bob" is bluffing!)
What kind of situations could your first scenario
apply to?
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Clearer (hopefully?) example of 1-1 problem.
Date: Tue, 11 Jan 2000 17:38:29 -0000
Yours works because redundancy in compressed data does indirectly reference
redundancy in the decompressed file.
IE redundancy in the compressed data must be a code and not dictionary data
for 1-1 to work.
Which is what you do.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: A Post-Caribbean Update
Date: 11 Jan 2000 18:29:43 GMT
Upon returning from a 2-week vacation
in the Virgin Islands I found my mailbox
stuffed with, among other correspondence,
letters about my web site.
One of those letters included C source
from Casimir. This revised code not only
cracks G. Braun's Crypto 3.5 program, but
now an older 2.6 version.
Other updates include a link on the
"People" page to D. Scott's web page.
Since Dave reminds me his contests are over,
they have been removed from the "Contests"
page.
Brian Gladman advised me that my old
link to his site has changed. It's now
updated on the "Algorithms & Attacks"
page.
The usual requests for registration cracks
and site cracking will, however, go ignored.
Of course, those requests don't come from
the regulars here, but still those entreaties
abound. Strange -- after 3 years on the
web some folks don't understand that the
"crack.htm" page is encryption cracking.
If you see anything else that needs updating,
or ought to be added let me know. Stocks
tips are appreciated, too, as I would like
to visit the Virgin Islands again next year.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: Rijndael (was: Square?)
Date: Tue, 11 Jan 2000 18:45:00 +0000
> the number of rounds for other key sizes is not specified.
See section 12.1 - "Other block and Cipher Key lengths".
Note that the AES only requires key sizes of 128, 192 and 256 bits,
and a block size of 128 bits.
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| ICQ#: 46605825 PGP: RSA 0x22D5C7A9 DH-DSS 0xBE63D7C7 0x87C46DE1 |
+-------------------------------------------------------------------+
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Intel 82802 Random Number Generator
Date: Tue, 11 Jan 2000 12:48:45 -0600
Guy Macon wrote:
> Could one of you fellows who know more about crypto take a look
> at the way Intel suggests doing the SHA1 and comment on it?
> It seems that you could write a device driver to get at the output
> of the chip and then use whatever method you choose.
>
> [ ftp://download.intel.com/design/security/rng/CRIwp.pdf ]
Thanks for posting the pointer. I found this paragraph interesting:
"As expected, significant biases are present
before the corrector. By far the largest
nonrandom characteristic detected was the bias
in the ratio of "0" and "1" bits. In devices
operating under extreme environmental conditions,
bit frequencies were observed on the order of
+/- .5x10^-2. Data with a 1% bias has 0.9997
bits of entropy per bit."
The corrector is the 00, 10, 01, 11 bit filter.
They collect 8 bits, then feed that to the SHA-1
algorithm. I can't see anything wrong with the
data manipulation. They take 16 bytes, hash it down
to 5, and the most significant byte is the RNG output.
The next input to the hash is those 5 bytes, the physcial
output byte followed by the 10 least significant bytes
of the previous hash.
It sounds like a good low cost and very simple solution.
If there's anything wrong with SHA-1, I would expect
a 100 million users of this implementation will find it!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: frequency analysis with homophones
Date: Tue, 11 Jan 2000 19:03:28 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
<< One of many amazing facts in cryptanalysis is that fitting an HMM to
the observed data often results in approximate categorization that is
good enough to work with. >>
I've found quite a bit of interesting material about HMM's on the
Internet, but I'm lacking a good example of how these could be applied
in cryptanalysis. Can you refer me to a text or other source?
-- Jeff Hill
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: AES & satellite example
Date: 11 Jan 2000 14:10:27 -0500
In article <[EMAIL PROTECTED]>, Nicol So <see.signature> wrote:
>DJohn37050 wrote:
>>
>> I am writing a paper for 3rd AES and remember someone discussing in sci.crypt
>> that a reason for having multiple AES winners were situations where hardware
>> was used but was not able to be updated, as in satellites, Does anyone
>> remember who said that?
>
>Are you sure it is indeed difficult (or not possible) to update the
>(hardware) encryption implementation on satellites? (I can think of a
>fairly obvious yet secure solution to the problem).
And fast? Sure a Space Shuttle can be sent up with a new cipher-on-a-board,
but those take quite a while to get going.
Having multiple ciphers as backups is almost certainly a good idea as long
as they are all believed to be strong, and there is a way to securely tell
the satellite to stop using a given cipher.
-Giff
--
Too busy for a .sig
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: another newbie
Date: Tue, 11 Jan 2000 13:52:39 -0600
Markus Eiber wrote:
> Hi there,
> I am looking for information about how to calculate the practical secrecy of
> a cipher.
> Is there a measure like the unicity distance for theoretical secrecy? How
> can it be calculated?
>
> Thanks for any input you could provide.
There are upper bound measures -- i.e. this algorithim takes at most (best
attack vs. it) time/space to preform. Unfortuantely in most cases that is not
sulficient as that ignores the potenial of better attacks vs. the algorithim,
and many implementations will also weaken security vs. theoretical due to design
defects.
The only algorithims that have a 100% valid measure are those that are way to
weak to use.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: AES & satellite example
Date: Tue, 11 Jan 2000 19:58:23 GMT
On Mon, 10 Jan 2000 18:06:01 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Please do not fail to note the weaknesses inherent in a system whose
>cryptologic capabilities can be updated remotely. I suspect the cost of
>securing the update capability would be larger than the cost of installing
>multiple ciphers in the first place.
>
>In the update case the need to replace a cipher implies that there may be
>no secure way to do so. After all the cipher being replaced is insecure.
I think there is a basic assumption here that the new cipher would be
delivered, encrypted under the old, insecure cipher. This is not a
sound assumption. Executable algorithm code is generally signed, such
that the target satellite will reject any attempt to upload bogus
algorithm code. The code may also be encrypted and separate algorithms
are generally used to secure code.
For example, I know of systems where classified algorithm code in
encrypted under an algorithm specific to that function and the
encrypted code image is signed under another algorithm specific to
that purpose. Both of these algorithms that protect the code from
substitution and disclosure are dedicated to these functions, not used
for anything else and can not be replaced.
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Date: Tue, 11 Jan 2000 12:17:42 -0800
Vernon Schryver wrote:
> >Ok, fine, but there are a zillion other ways to generate random
> >numbers at the OS level.
>
> That is a gross overstatement. Randomness is always hard to find in
> software. Yes, /dev/random works, but only by lots of work and some leaps
> of faith about what are almost errors in disk drives, clocks, and other
> hardware. The Intel mechanism is very valuable, its low speed and other
> difficulites notwithstanding, because the only leap of faith required is
> that it works as advertised.
I would like to agree with emphasis on the leaps of faith. It is one thing
to observe glibly that there must be scads of potential sources of local
entropy, and another to exploit this correctly, in a manner not predictable
or reproducible. /dev/random in the worst case cannot supply *any* random
bytes, since the entropy pool must be stirred. Even the variable maximum
bit rates provided by the Intel RNG, by the SG100 "dongle," by the Tundra
1210 RBG, etc. are far better.
What's more, there are some very strong, non-linear software random
number generators which lack precisely one thing to be used as
secure cryptographic RNGs: irreproducible seeding from a suitable
source of entropy bits that pass all the important statistical
tests.
> The word "the" which suggests not only that there is at least one
> microphone but that there is exactly one. I've seen more systems with
> more or less than one than with exactly one microphone.
Server hosts rarely have any. Try reading /dev/audio from a Netra ;-)
> I wonder what happens when a "multi-threaded app" or two applications try
> to read from the the microphone?
Can't be good...
--
QUI ME AMET, CANEM MEUM ETIAM AMET
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Double transposition/playfair
Date: Tue, 11 Jan 2000 13:21:17 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
>Double Playfair is not as simple as it looks from Bauer and the other
>authors I've seen published. I found a paper from Bletchley in the
>declassified NARA "Open Door" documents: besides using two squares
>like a Two-square cipher, it has two encryption steps. The encrypted
>digraph is pushed through the same cipher process a second time.
Although I do remember reading books in which the term "double
Playfair" was used to mean the two-square cipher, which you are now
saying is incorrect history, I think the poster meant applying regular
Playfair twice when he said "double Playfair".
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Reply-To: [EMAIL PROTECTED]
Date: Tue, 11 Jan 2000 19:59:12 GMT
Daniel Vogelheim <[EMAIL PROTECTED]> wrote:
[Scott's compressor failing to decompress]
:>If someone else doesn't beat me to it I'll look at this and report back.
: Please do, that's why I posted.
It appears that David has acknowledged that you found a bug, and has
posted what he claims is a fixed version to his web site.
I'm sure reports of any further problems would be gratefully received.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Old frogs never die - they just croak.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES & satellite example
Date: Tue, 11 Jan 2000 13:30:29 GMT
[EMAIL PROTECTED] wrote, in part:
>Jerry Coffin.
Yes, and the key paragraph from his post is:
>To reasonably postulate a hardware design, it looks to me
>like we have to combine low power and small size with high
>bandwidth requirements. For one example, a communication
>satellite. The problem here is that building in an extra
>algorithm or two is a TINY fraction of the cost of a
>communication satellite, and even in this space-restricted
>environment, an extra fraction of a square millimeter of die
>area is still hard to notice. At the same time, if you use
>an algorithm that gets broken, the cost of launching a new
>satellite is truly astronomical.
So that was the post you were thinking about; Terry Ritter's post,
although touching on similar ideas, did not talk about AES winners,
while this one did.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Question about public key encryption in Z*_n
Date: 11 Jan 2000 12:34:30 -0800
In article <[EMAIL PROTECTED]>,
David Hopwood <[EMAIL PROTECTED]> wrote:
> Are there any public key encryption algorithms based on arithmetic
> in the ring Z*_n, where n is composite, that do *not* require the
> factorisation of n (or any equivalent information) to be known to
> the private key holder?
Sure -- any discrete log based scheme, e.g., Diffie-Hellman.
If n=pq, then taking discrete logs mod n is at least as hard as
taking discrete logs mod p (or mod q).
> Alternatively, does anyone know of public key encryption algorithms
> where the secret key includes a root (e.g. square root or e'th root
> for gcd(e, phi(n)) = 1) of the public key, or a vector of such roots?
Can Fiat-Shamir be used for encryption?
> If it helps, the reason I'm asking is that this would help me in
> constructing a public key encryption algorithm with a "forward
> secrecy" property, similar to the property of perfect forward
> secrecy for key agreement protocols. (I.e. a compromise of the
> private key would not allow messages sent before a given time to
> be decrypted.)
I'm curious -- how does the above help? What's wrong with a standard
Diffie-Hellman key-exchange, followed by encryption with the exchanged key?
Are you trying to provide non-interactive forward secrecy, or somesuch?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Reply-To: [EMAIL PROTECTED]
Date: Tue, 11 Jan 2000 20:17:13 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> One idea behind such a scheme is essentially that if the EOF occurs while
:> the decompressor is in the middle of a symbol, it *knows* that this can
:> only happen if the decompressor chopped of a tail of zeros. This tail of
:> zeros can be unambiguously reconstructed *provided* the file does not end
:> with any all-zero Huffman symbols - and this case can be avoided fairly
:> simply.
: Excuse me, if I am arguing based on wrong knowledge (I haven't followed
: the stuff for quite a while and perhaps have forgotten a lot). What
: if the analyst decrypts with a wrong key which produces a file that
: has at the end a sufficiently long sequence of zeros?
I haven't really specified what scheme I was talking about.
I was /trying/ to describe the scheme proposed by Matt - details at:
http://www3.sympatico.ca/mtimmerm/biacode/biacode.html
His scheme post-processes the file after any trailing zeros have been
chopped off in a manner that is a bijection between the set of
"finitely odd" files (binary streams that end with an infinite
string of zeros) - and the set of all possible 8-bit files.
The objection relating to a "00000" file would only apply if this
mapping were not subsequently applied. Since I failed to mention it
in my description, the objection is understandable.
As Daivd has mentioned, you can try decompressing files of zeros with the
compressors in question for yourself to verify that they result in valid
files.
Incidentally, "finitely odd" *seems* like a /slight/ misnomer to me -
one of the files in question appears to be even. _Perhaps_ the term
refers to all of them, except for that one ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
This tagline handcrafted from only the finest ASCII.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Tue, 11 Jan 2000 20:40:18 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Matt Timmermans <[EMAIL PROTECTED]> wrote:
:> : I missed the start of this thread, but as far as I know, there are no
:> : known one-way permutations that can be shown to be permutations [...]
:>
:> : For instance: If I publish an RSA modulus and public exponent as a PRP,
:> : how do I show that it _is_ a permutation without revealing private
:> : information, at which point it would cease to be one-way?
:>
:> As I understand it, RSA-based block cyphers can losslessly encode
:> information from a message in the same number of bits as are present in
:> the message.
:>
:> I don't see how can this fail to be a bijection when used as a hash (i.e.
:> by destroying the private key) - when hash size, message size and block
:> size are all equal?
: You're missing Matt Timmerman's point. [...]
Yes, I was.
: The person who generated the RSA modulus and exponent may know that
: this is a PRP, but no-one else is able to verify that a valid RSA public
: key is being used (specifically, they cannot check that gcd(e, phi(n)) = 1
: because they don't know phi(n)).
Yes, I think I understand, now.
Is there any objection (besides the one I have mentioned) to the scheme
raised by Scott Fluhrer, who wrote:
=========START QUOTE============
>Doing modular exponentions can be shown to be a permutation without
>giving away any secret material. That is, you can find particular values
>of g and p such that:
>
> f(x) = (g**x) mod p
>
>can be demonstrated to be a permutation from (1..p-1) to (1..p-1),
>without there being any known way to compute the inverse in a reasonable
>period of time.
=========END QUOTE============
:> When you use RSA to encrypt, you can decrypt again and recover the
:> original message. If you can do this for all possible files of a given
:> length, and the size of the domain is equal to the size of the range,
:> what other possible maps could there be, besides a bijection?
: Think about what happens if e and phi(n) are not relatively prime.
This doesn't produce any noticable effect at this point - it seems that
they would be, by design.
Currently I can't imagine how the construction from the asymmetric cypher
to the bijective one-way function could fail - though I'm happy to agree
that an individual with no knowledge of the (discarded) private key
has no way to easily verify that the structure is performing as it
should be.
:> Also, (to answer your question another way) hashes of individual messages
:> could be computed with the public key.
:>
:> In principle this would allow a demonstration that the map was a
:> permutation by exhaustively going through all the possible messages
:> of the given length, and seeing if there are any hash collisions.
: Cough, splutter! That's rather a lot of messages.
That depends on the hash size in question, but yes - for normal
cryptographic purposes - this is likely to be less-than-feasible in practice.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
When everyone agrees with me, I know I'm wrong.
------------------------------
From: "Derek" <[EMAIL PROTECTED]>
Subject: Re: Anyone give any pointers?
Date: Tue, 11 Jan 2000 16:31:00 -0500
Like I said, some of their files are not encrypted... so I know the actual
decrypted file's format. I can also view the plaintext in the software
itself, so I've been able to do a little bit of the analysis by hand to
determine that it's only 1 bit per byte that's being changed.
I don't really understand how 1bit/byte reduces the exposure. Also, how you
make a 16-bit PRNG cover a 524K file? By my guess, you could only get it to
262140 bytes (you'd have to use two bits from the random number to tell you
which bit to XOR). But that'd be a lot of work. And they're actually
needing 9 states, since sometimes they don't flip any bits.
Does the typical PRNG libraries on 16-bit compilers typically use a 16-bit
PRNG?
Derek
<[EMAIL PROTECTED]> wrote in message news:85djvs$qiu$[EMAIL PROTECTED]...
> Well it sounds like you seem to "know" quite a bit about this encryption
> format. Often I find that the assumptions I make when decrypting things
> are not always 100% correct the first time...
>
> However, to answer one of your questions, one of the main reason to
> only xor 1bit/byte is to reduce the amount of encrypted data that
> is exposeable to attack. Suppose you needed 65535 terms to find
> the repeating sequence (16 bit PRNG). If you used only the 8lsbs
> of this PRNG to XOR you would discover it in a 65535 byte file.
> If you only use 1bit/byte you could have a 524K file to find the
> repeat...
>
> Maybe these guys aren't as dumb as you think... ;-)
>
> In any event, this is clearly a case of security through obscurity...
> Reverse engineering the player is probably the best way to go. If
> you had the original and the decrypted stream, you would just XOR
> them and have a table of xor... Then you could take stuff like the
> shift amount and the cycle length to reverse engineer the sequence.
> However, the easiest thing to do is just hack the player and look
> for the subroutine that does the decryption... If I'm not mistaken,
> that's pretty much how DVDs got cracked...
>
> But don't do anything illegal...
>
> -slew
>
> BTW, this is the way most encryption schemes get cracked. Secure
> encryption has the algorithm advertized and the only unknown quantity
> is the key. Then the problem reduces to the security of the key.
> (such as hiding it or making it so long so cracking is computationally
> unfeasible). Hiding the algorithm itself helps too, but only if it's
> a good algorithm to start with... (but ususally people hide algorithms
> because they aren't very good algorithms)...
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Double transposition/playfair
Date: Tue, 11 Jan 2000 21:43:57 +0000
John Savard wrote:
> Although I do remember reading books in which the term "double
> Playfair" was used to mean the two-square cipher, which you are now
> saying is incorrect history, I think the poster meant applying regular
> Playfair twice when he said "double Playfair".
Seems likely from the way he suggested composing the two. However,
since double transposition and a system <called> double Playfair were
used and broken by the same groups in sequence during the war, I gave
him the benefit of the doubt. I'm confident that regular Playfair
used twice without an offset is far simpler than the double Playfair
used by the German police during WW2. Yes, it's definitely different
from the two-square cipher. I've typed in one of the documents from
Bletchley describing the version they broke; it matches another
document that contains actual intercepts and corresponding decrypts.
If the doc is of interest I'll post it... it's pretty short.
Another way to do something that could be called "double Playfair"
was used by Robert Thouless in his attempt to demonstrate life after
death. He took a text, encrypted it with Playfair, added a character
to front and back to break up the pairs (suitably dinking it so that
double letters wouldn't get them back into alignment), and then
encrypted it a second time with Playfair using a different key. I
wrote a paper describing my crack with Larry Harnisch for Cryptologia
a few years ago, with title "Cryptograms from the Crypt."
--
Jim Gillogly
Highday, 20 Afteryule S.R. 2000, 21:35
12.19.6.15.10, 6 Oc 18 Kankin, Fourth Lord of Night
------------------------------
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Tue, 11 Jan 2000 13:45:51 -0800
In article <[EMAIL PROTECTED]>, Shawn Willden > On a
standard installation of Windows NT, he'd have no trouble.
> Theoretically, a properly locked-down installation would be
> secure, but since
> (1) there doesn't seem to be a large community of NT users who
> focus seriously
> on security and (2) Microsoft's approach to security breaches is
> generally to
> deny them for as long as possible, and quietly half-fix them when
> forced to, I
> would depend on it too strongly.
> Further, even the resistance of a locked-down NT box only holds
> while NT is
> running. Boot off a floppy and all bets are off.
> Shawn.
Can your floppy read/write to NTFS filesystems (yes, I know about
NTFSDOS and other OS drivers to do this)? Did you bring a floppy drive
with cables? How did you manage to get into the locked server room? You
must have physical security.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
** 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
******************************
