Cryptography-Digest Digest #839, Volume #13       Thu, 8 Mar 01 18:13:01 EST

Contents:
  Re: => FBI easily cracks encryption ...? (Matthew Montchalin)
  Re: Meaninog of Kasumi (Gregory G Rose)
  Re: Super strong crypto ("Douglas A. Gwyn")
  Re: frequency "flattening" (Mok-Kong Shen)
  Re: Super strong crypto (Mok-Kong Shen)
  Re: The Foolish Dozen or so in This News Group (Benjamin Goldberg)
  Re: NTRU - any opinions (Dan Bailey)
  Re: One time authentication (Tim Tyler)
  Re: One-time Pad really unbreakable? (Tim Tyler)
  Re: One-time Pad really unbreakable? (Tim Tyler)
  Re: => FBI easily cracks encryption ...? (Jim D)
  Re: One-time Pad really unbreakable? (Tim Tyler)
  Re: Buy a PDF edition of Applied Cryptography of Bruce SCHNEIER ("Dan Beale")
  Re: One-time Pad really unbreakable? (Ben Cantrick)
  Re: One-time Pad really unbreakable? (Tim Tyler)
  Re: One-time Pad really unbreakable? (Jerry Coffin)
  Re: The Foolish Dozen or so in This News Group (Benjamin Goldberg)

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

From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Thu, 8 Mar 2001 13:09:05 -0800

On Thu, 8 Mar 2001, Mxsmanic wrote:
|By selecting specific frequencies with an antenna that can be aimed; 
|at least that is one method that comes immediately to mind.

Not easy if you have to go through one monitor to get to the next one;
there's bound to be interference sufficient to make it easier to tap
a phone line physically than point a gizmo directly at a window.  And
if the communication is encrypted on both sides of the connection,
then the gizmo is still a tough choice to make.

It seems that having a "line of sight" to the target is something of
a necessity.


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

From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Meaninog of Kasumi
Date: 8 Mar 2001 13:30:01 -0800

In article <[EMAIL PROTECTED]>,
Mike Rosing  <[EMAIL PROTECTED]> wrote:
>Arturo wrote:
>> 
>>         KASUMI is the name of the encryption algorithm to be used in
>> third-generation mobile phones.  My question is, what does that workd stand for?
>> Does it have any meaning?  TIA
>
>It's an "ordinary" japanese name.  It may be from a famous ninja or war lord
>who is famous in Japan.  It might also stand for something in Japanese, but
>I sure wouldn't have a clue how to parse it!  Look for it on Mitsubishi's
>web site http://www.mitsubishielectric.com and search for kasumi.  You'll get
>some interesting hits.

Replying to Mike's post because I haven't seen
Arturo's yet...

"Kasumi" means "fog", and the name is derived (as
is the algorithm) from MISTY.

Greg.

-- 
Greg Rose                                       INTERNET: [EMAIL PROTECTED]
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/ 
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Thu, 8 Mar 2001 20:40:54 GMT

Mok-Kong Shen wrote:
> ... I use to believe, though, that
> for applications of extremely high security requirements
> bandwidth commonly isn't a big problem, since their volume
> cannot be excessive and one is in such cases more ready to
> pay for the costs involved in being conservative in all
> respects.

There are many, many assumptions behind that argument,
and in cases like the one I have in mind those assumptions
are wrong.

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: frequency "flattening"
Date: Thu, 08 Mar 2001 22:43:23 +0100



"Joe H. Acker" wrote:
> 
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> 
> > > F_result(a) = F_result(b) = F_result(c) = k
> >
> > Suppose a, b and c have frequencies of 0.5, 0.25 and
> > 0.25 respectively. If one maps a to r and s with equal
> > probability and maps b to t and c to u, then the output
> > signs r, s, t, u will have equal frequencies. Is that
> > what you want?
> 
> That's exactly what I want. (Of course, I also want to be able to decode
> the output to the original input.)
> 
> >But you have here a problem of precision.
> > If the values of the initial frequencies are not that
> > nice, the equality is only rough and you could get in
> > general better approximations to equality through mapping
> > each of a, b and c to a larger number of signs. The question
> > would be then at which stage you would be satisfied with a
> > certain approximation of equality of frequencies of output
> > signs. In the ideal case where one gets exact equality in
> > frequencies, the optimal code will be a block code for the
> > output signs, i.e. all signs have the same number of bits
> > (special case of Huffman codes). Does the above correspond
> > to what you mean by 'optimality' or do you want something
> > different?
> 
> I'm not sure if I understand you correctly. Does such a block code as a
> special Huffman code ensure these two conditions:
> 
> 1. all signs in the output have the same frequency
> 2. all signs of the alphabet A are in the output, regardless wether they
> occur in the input or not
> 
> If yes, that's exactly what I'm looking for. Do you have any references
> or links where I can look further for that?

Sorry, what I mentioned about the block code is misleading.
(Only for 2^n elements, like the example I gave, is the
Huffman code a block code.) 

The essence of my explanation is that you can use homophones,
(i.e. by suitably mapping each input symbol to a number
of output symbols) to obtain (in general) a more or less
flat distribution of the output symbols (how these are
coded is another issue, preferably with the Huffman 
scheme to optimize the number of bits) and that better 
results can be obtained with larger sets of output symbols 
(unless by chance one gets exactly equal frequencies). I 
suppose that my example has made it clear what you have to 
do with any real input symbol distributions. As said, you 
have to decide what kind of almost equal frequencies is 
acceptable to you and stop, otherwise you would finish with 
a huge set of output symbols and a correspondingly large 
ratio of ciphertext to plaintext. That homophones flatten 
the frequency distributions is well known. Being a rather 
simple concept, I don't think there is any special literatures 
about that.

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Thu, 08 Mar 2001 22:49:39 +0100



"Douglas A. Gwyn" wrote:
> 
> Mok-Kong Shen wrote:
> > ... I use to believe, though, that
> > for applications of extremely high security requirements
> > bandwidth commonly isn't a big problem, since their volume
> > cannot be excessive and one is in such cases more ready to
> > pay for the costs involved in being conservative in all
> > respects.
> 
> There are many, many assumptions behind that argument,
> and in cases like the one I have in mind those assumptions
> are wrong.

Perhaps you should also check in those your cases whether
the keys need to be perfectly random (barely realistic)
and (in case no) whether using pseudo-random keys
(thus permitting no expansion of bandwidth) is feasible.

M. K. Shen

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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Thu, 08 Mar 2001 21:52:02 GMT

Anthony Stephen Szopa wrote:
> 
> Richard Herring wrote:
> >
> > In article <[EMAIL PROTECTED]>, Crypto
> > Neophyte ([EMAIL PROTECTED]) wrote:
> > > On Sun, 4 Mar 2001 17:22:02 -0600, Anne & Lynn Wheeler wrote
> > > (in message <[EMAIL PROTECTED]>):
> >
> > > > however, overwriting 27 times is a little harder since
> > > > straightforward overwrite is likely to just be updating buffer
> > > > records. frequently multiple overwriting passes consists of
> > > > different combinations of ones & zeros with the intent of
> > > > exercising the magnetic flux in different ways on the disk
> > > > surface.
> >
> > > Ok, please help out a neophyte. I have a program called MACWASHER.
> > > The box states that it overwrites files according to the DoD
> > > directive 5220.22-M.
> >
> > If the program does what it claims to (and I have no knowledge of
> > that) it will be accessing the hardware at a lower level than
> > Szopa's calls of the C library functions fopen()/fclose().
> >
> > > It looks like from what I have read on this discussion that the
> > > above DoD directive doesn't actually do what the DoD thinks it
> > > does.
> >
> > If that's what you think, you have severely misread something.
> > The DOD directive presumably states that the program *shall* do
> > something. If the program doesn't do what the DoD requires, it
> > means that the program fails the directive, not that the
> > directive is wrong.
> >
> > > In other words I am not actually deleting the files and making
> > > them unrecoverable? When I say unrecoverable I mean to a software
> > > based attack and not SEM data.
> >
> > No. The point here is not that it is impossible to do
> > what you want, but it can't be done using high-level
> > platform-independent library functions.
> >
> > --
> > Richard Herring       |  <[EMAIL PROTECTED]>
> 
> here are the calls:
> 
> fopen in r+b mode
> fprintf character by character
> fclose that flushes all OS buffers associated with the stream.  You
> would think this would be enough to force a write.

How many times does this need to be pounded into your head?  fclose
flushes the C library buffers, not the OS buffers.

> Just to make sure I added one of ...
> 
> ...the Colonel's secret spice codes of 8 characters in length in
> each pass
> 
> Down load the UPDATE.  You will see the hard drive accesses after
> each pass.  Larger file size makes for more hard drive accesses.
> 
> There can only be one reason for these hard drive accesses with the
> code as described:  a write to the hard drive.

That's ignoring the hdd buffers.  The drive light goes on for a bus
transfer of data to the drive, not for actual writing.

-- 
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.

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

From: Dan Bailey <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: Thu, 8 Mar 2001 16:52:41 -0500

Don,

NTRU works nicely in constrained environments because it's fast, taking
less time and battery life. For ease in comparison, consider Pentium
III/800 MHz performance.  Consider Wei Dai's excellent Crypto++ library
since it runs thereon and most people can agree it's a good, independent
implementation of RSA and ECC.  NTRU timings from NTRU's NERI toolkit:

Function        Units           NTRU 251        RSA 1024        ECC 155
Enc Keygen      Keys/sec        1512                            259
S/V Keygen      Keys/sec        1996                            
Encrypt         Blocks/sec      16556           2744            132
Decrypt         Blocks/sec      8620            90              70
Sign            Sigs/sec        3215            94              255
Verify          Sigs/sec        3225            2949            151

NTRU code is portable C, no assembly.  ECC numbers over GF(2^155) with
precomputation, signing is ECNR, encryption is ECIES.  RSA 1024 has e=3.  
There's a similar speed advantage on constrained devices, it's just that
reliable, independent RSA and ECC numbers are harder to come by.

Beyond that, anecdotal information suggests even with better
performance, NTRU's footprint and gate count are much smaller than
either RSA or ECC.  

Cheers
Dan

PS Yes, I work for NTRU.  Is this the same Don Johnson who works for
Certicom? :)

On 8 Mar 2001, DJohn37050 wrote:

> ECC is very suited to constrained environments, having short keys and sigs and
> simple key gen.  It is not cleat at all to me that NTRU is as suited as it has
> longer keys than even RSA, longer sigs than RSA, not studied key gen yet but I
> do not see how anything can be simpler than ECC.  It seems to be faster than
> RSA on NTRU's implementations but they also seem to say that ECC SigGen is
> slower then SigVer which does not compute.
> Don Johnson
> 
> 
 





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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One time authentication
Reply-To: [EMAIL PROTECTED]
Date: Thu, 8 Mar 2001 22:09:42 GMT

David Wagner <[EMAIL PROTECTED]> wrote:

: Carter-Wegman authentication (universal hashing) provides provable,
: perfect authentication, much like the OTP provides provable, perfect
: secrecy. [...]

Aha.  I believe that is /exactly/ what I was looking for.

Some wandering around led me to:

http://theory.lcs.mit.edu/~dmjones/hbp/jcss/References/carterw1979:143.html

...which gives many references related to this subject.  Thanks.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 8 Mar 2001 22:13:08 GMT

Jim D <[EMAIL PROTECTED]> wrote:
: On Wed, 7 Mar 2001 11:00:09 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Mxsmanic <[EMAIL PROTECTED]> wrote:

:>: One-time pads are indeed unbreakable, and provably so.
:>
:>Only in mathematical never-never land.  The OTP "specification" does not
:>offer any prescription for the generation of suitable random numbers -
:>and since no such recipe is likely to be forthcoming, the "provably
:>secure" OTP will never make it off the paper and into the real world.

: I can send you a piece of OTP cipher and I'll guarantee
: you won't break it in a million years.

What will that prove?  How can I place any trust in your guarantee?
I don't know you from Adam.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 8 Mar 2001 22:17:55 GMT

Frank Gerlach <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mxsmanic <[EMAIL PROTECTED]> wrote:

:> : One-time pads are indeed unbreakable, and provably so.
:> 
:> Only in mathematical never-never land.  The OTP "specification" does not
:> offer any prescription for the generation of suitable random numbers -
:> and since no such recipe is likely to be forthcoming, the "provably
:> secure" OTP will never make it off the paper and into the real world.
: If you call the widely used SIGSALY (check www.nsa.gov for it)
: "mathematical never-never land"
: then you are correct.

Nope - but the fact that some people use OTPs and do not have their
systems compromised does not prove that they are secure in real world
applications.

The assertion in question is "One-time pads are indeed unbreakable, and
provably so."  There is no proof that applies to actual realisations of
the OTP.

: The russian KGB and the german BND regularly used it during the cold war
: to communicate with their agents operating in enemy territory. Why
: should they stopped using it ?

I never stated nobody used OTPs.

: Your criticism boils down to technology and philosophy.

I'm not sure about this involving philosophy.  This is an issue relating
to security - and to what extent communication systems can be trusted.  I
don't see it as terribly philosophical.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

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

From: [EMAIL PROTECTED] (Jim D)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Thu, 08 Mar 2001 22:28:16 GMT
Reply-To: Jim D

On Wed, 7 Mar 2001 16:11:50 -0800, Matthew Montchalin
<[EMAIL PROTECTED]> wrote:

>On Wed, 7 Mar 2001, CR Lyttle wrote:
>|> TEMPEST "eavesdropping" is very resource intensive and not something
>|> that's done at random.  If that van's parked across the street, you
>|> did something to bring it there.
>|
>|I've seen and built system for less than $100 that can read your
>|monitor from across the street. Several countries have regular patrols
>|checking, from the street, what their citizens are watching on TV or
>|listening to on radios. (Does England still do that?). Such technology
>|has been available for over 50 years. It just keeps getting cheaper.
>
>What is the easiest way to screen yourself (that is, your screen)
>from this sort of unwanted eavesdropping?  If you have lots of screens
>turned on, and lots of phone lines going, how can they tell which one
>you are doing stuff with?   Not that I do anything like that, of course;
>my own premises are extremely clean, in a very legitimate sense.  Of
>course, in the next few days I will be heading to a big metropolitan
>area to make a contact with someone who makes a contact with someone
>else (or maybe I am just saying this because I am yanking their chain,
>haha).  But from a hypothetical situation, how would 'spooks' zero
>in on the right monitor and right phone line?

You can cover the entire inside of the monitor with earthed tinfoil
or paint it with metalic paint. Screen and decouple the mains and
data leads.

You used to be able to buy screen filters which incorporated a very
fine mesh (again earthed) to prevent radiation from the front of
the screen.

Someone on here recently said that even with many active screens
and TV sets, a good TEMPEST spook could select the screen he
wanted. I find that difficult to believe.

There will always be radiation from a computer. Short of putting
it in a screened room, with special arrangements for doors and
windows and filtered 'phone and supply lines, you won't be able
to contain radiation completely.

-- 
___________________________________

George Dubya Bushisms No 4:
 'Welcome to Mrs Bush and my
   fellow astronauts.'

Posted by Jim Dunnett
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 8 Mar 2001 22:25:06 GMT

Mxsmanic <[EMAIL PROTECTED]> wrote:
: "Paul Crowley" <[EMAIL PROTECTED]> wrote:

:> We have many sources of random numbers that
:> *seem* to be effective in *practical* terms, but
:> none of them are *proven* effective the way
:> the one-time-pad is *proven* effective.

: My understanding is that the randomness of radioactive decay is
: _proven_, not merely postulated, because it is an inevitable consequence
: of quantum mechanics as that theory is now understood. [...]

I believe you are mistaken here.  As I understand it, the theory is
consistent with sub-atomic physics being random - but it is also
completely consistent with it being based on deterministic rules.

Anyway this is irrelevant - since we have no way to go from radioactive
decay events to a usable cryptosystem whilst eliminating all possibility
of interference with our apparatus by our opponents.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

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

Reply-To: "Dan Beale" <[EMAIL PROTECTED]>
From: "Dan Beale" <[EMAIL PROTECTED]>
Subject: Re: Buy a PDF edition of Applied Cryptography of Bruce SCHNEIER
Date: Thu, 8 Mar 2001 22:46:18 -0000


>
> "Ryan Phillips" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I'm surprised no one has mentioned this link:
> > http://www.cacr.math.uwaterloo.ca/hac/

"Ryan Phillips" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Wrong book, sorry.
> -Ryan

still a good link though,
thanks!





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

From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: One-time Pad really unbreakable?
Date: 8 Mar 2001 15:46:01 -0700

In article <[EMAIL PROTECTED]>, Tim Tyler  <[EMAIL PROTECTED]> wrote:
>Jim D <[EMAIL PROTECTED]> wrote:
>: I can send you a piece of OTP cipher and I'll guarantee
>: you won't break it in a million years.
>
>What will that prove?  How can I place any trust in your guarantee?
>I don't know you from Adam.

  The security of a one-time pad does not rest on trusting some random
person on USENET. Used properly, it is a (perhaps the only) provably
unbreakable cypher.

  See http://web.ranum.com/pubs/otpfaq/


          -Ben
-- 
Ben Cantrick ([EMAIL PROTECTED])        |   Yes, the AnimEigo BGC dubs still suck.
BGC Nukem:     http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs:  http://www.dim.com/~mackys/spamdogs
http://www.sluggy.com

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 8 Mar 2001 22:40:35 GMT

John Savard <[EMAIL PROTECTED]> wrote:
: On Wed, 7 Mar 2001 11:00:09 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote, in
: part:

:>Only in mathematical never-never land.  The OTP "specification" does not
:>offer any prescription for the generation of suitable random numbers -
:>and since no such recipe is likely to be forthcoming, the "provably
:>secure" OTP will never make it off the paper and into the real world.

: In that case, Las Vegas ought to find another industry with which to
: support itself.

Do casinos state that their games are "unbreakable, and provably so."

This is the first I have heard of it.  In fact I am aware of casinos who
have had their systems beaten by individuals with sophisticated monitoring
equipment, designed to detect non-randomness in the apparatus.

You can read more about such exploits in a popular book on the subject:
The Newtonian Casino - Thomas A. Bass -
  http://www.amazon.co.uk/exec/obidos/ASIN/0140145931/

``The true story of how a group of young physicists and computer
  scientists developed a computer to predict the results of roulette. They
  then smuggled the device into the casinos of Las Vegas, hidden in the
  soles of their shoes.''

: In other words: here is a counterexample - a sequence of physically
: generated random numbers that cannot effectively be predicted.

Exactly where is this counterexample - I seem to have missed it.  If you
present a more detailed pointer to this supposedly random stream, how do
we know it is genuinely unpredictable.  Surely we should not be expected
to rely on our own inability to predict it?

Surely you are not asserting that casinos are producing "perfect
randomness"?  All casino's have to do is to produce enough randomness to
come out ahead of their clients, once the house margin is taken into
account.  I believe roulette is one of the best casino games, in terms of
expected winnings per game - and there the house margin is 1/60 - hardly
something which needs to produce randomness good enough for cryptographic
purposes.

: The series of numbers generated by throwing dice and the like is indeed
: sufficiently clearly unpredictable that the mathematical proof of the
: OTP is still highly relevant - even if the unbreakability of a "real"
: OTP is no longer at the absolute level of truth of a mathematical law [...]

I would agree that the proof that an ideal random stream can be used to
produce perfect secrecy is an interesting result, with significant
implications for real-world implementations of OTPs.

However, as you say, as soon as you lose the proof of randomness, you
lose the proof of secrecy, leaving you with a system that is "very
likely" to be secure.
-- 
__________
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

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

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Thu, 8 Mar 2001 16:01:37 -0700

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

[ ... ] 

> Unfortunately terms like "quantum computer" get floated around by the
> media without adequate understanding from the public.  The usually
> assumed protection from quantum computer analysis is  a one time pad
> implementation.   Common sense suggests that quantum computers will have
> limitations in "practical application" at least in early configurations.
> Perhaps there is a subset of cryptographic algorithms that will withstand
> analysis from "practical" quantum computers?

The Schorr algorithm allows a quantum computer to do factoring in a 
number of operations roughly proportional to the square root of that 
required with factoring algorithms on conventional computers.  That 
means that for equivalent security, RSA (for the most obvious 
example) needs to have roughly double the key-length currently 
required to be secure against a quantum computer with essentially the 
same cycle time.

TTBOMK, nobody has figured out a way to apply a quantum computer to a 
typical symmetric encryption algorithm.  OTOH, it appears that the 
assumption that they may be applicable to such tasks is part of the 
motivation behind changing from 128-bit keys to 256-bit keys for 
quite a few newer algorithms.  Quantum computers do have some fast 
database lookup capabilities that seem like they might be useful, but 
that's really just pure speculation -- I don't know of an actual 
attack that would make particularly good use of the capability, only 
the general idea that it could be useful.

>From a more practical viewpoint: the current state of the art in 
quantum computing has roughly the mathematical capabilities of a pre-
school child who can count to ten without getting the numbers out of 
order very often.  We're definitely NOT talking about something that 
can yet compete with even the very first programmable calculators.

-- 
    Later,
    Jerry.

The Universe is a figment of its own imagination.

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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Thu, 08 Mar 2001 23:00:14 GMT

Anthony Stephen Szopa wrote:
> 
> Paul Rubin wrote:
> >
> > David Hopwood <[EMAIL PROTECTED]> writes:
> > > No, this time it's not Bill's fault. Write-behind caching is the
> > > expected default behaviour on any reasonable operating system (and
> > > besides, the disk controller still caches even if the operating
> > > system does not).
> >
> > And the disk DRIVE still caches if the controller does not, and it
> > may flush its caches to places on the media where software can't
> > reach, but forensic data recovery can.
> 
> Does that not apply to floppy disks as well?  Or are these an
> exception?

Windows does not do write-behind caching for floppies, and floppy drives
themselves do not cache either.  This is because floppies may be ejected
at any time.

-- 
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.

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


** 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 by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to