Cryptography-Digest Digest #674, Volume #11 Sun, 30 Apr 00 23:13:00 EDT
Contents:
Re: Command Line Cypher? ("Jimmy")
Re: Command Line Cypher? ("Jimmy")
Re: Command Line Cypher? (Tom St Denis)
Re: about search and seisure of computers again (jungle)
Deciphering Playfair (Michael Jarrells)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
("Garry Anderson")
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
("Garry Anderson")
Re: How safe am I using a subset of the bytes returned by SHA-1? (stanislav shalunov)
Re: Command Line Cypher? ([EMAIL PROTECTED])
Re: Joystick as RNG ("Trevor L. Jackson, III")
Re: Joystick as RNG (Tom St Denis)
Re: How would a 15 year old start? (Dan Day)
Re: Magnetic Remenance on hard drives. ("Marty")
Re: Science Daily overstates significance? (Diet NSA)
Re: Command Line Cypher? (Michael J. Fromberger)
Re: about search and seisure of computers again (Albert P. Belle Isle)
----------------------------------------------------------------------------
From: "Jimmy" <[EMAIL PROTECTED]>
Subject: Re: Command Line Cypher?
Date: Sun, 30 Apr 2000 19:10:35 -0400
Thanks... the ole XOR encryption... yeah thats pretty secure :)
Richard Heathfield wrote in message
<[EMAIL PROTECTED]>...
>Jimmy wrote:
>>
>> Anyone know of a decent command line stream cypher for *nix and NT?
>>
>
>Here's one. It's so secure it doesn't need a key. It's called SNA-Coil,
>and it works on the same principle as DES. What's more, you don't need a
>separate decryption program. Here's the full source:
>
>#include <stdio.h>
>
>int main(int argc, char **argv)
>{
> FILE *fpin, *fpout;
> unsigned char ch;
>
> if(argc > 2)
> {
> fpin = fopen(argv[1], "rb");
> if(fpin != NULL)
> {
> fpout = fopen(argv[2], "wb");
> if(fpout != NULL)
> {
> while(fread(&ch, 1, 1, fpin))
> {
> ch = ~ch;
> fwrite(&ch, 1, 1, fpout);
> }
> if(ferror(fpin) || ferror(fpout))
> {
> printf("rats.\n");
> }
> fclose(fpout);
> }
> fclose(fpin);
> }
> }
>
> return 0;
>}
>
>I defy anyone on this newsgroup to crack SNA-Coil.
>
>
>V ubcr V'z abg gbb yngr sbe Ncevy Sbbyf Qnl <t>
>
>--
>
>Richard Heathfield
>
>"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
>
>C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
>to go)
------------------------------
From: "Jimmy" <[EMAIL PROTECTED]>
Subject: Re: Command Line Cypher?
Date: Sun, 30 Apr 2000 19:16:01 -0400
You wouldnt know where one could find such an old verison of pgp would you?
Tom St Denis wrote in message <[EMAIL PROTECTED]>...
>
>
>Jimmy wrote:
>>
>> Anyone know of a decent command line stream cypher for *nix and NT?
>>
>> JImmy
>
>I think you can get pgp 2.6.2 for both... I dunno off hand.
>
>Tom
>--
>Want your academic website listed on a free websearch engine? Then
>please check out http://tomstdenis.n3.net/search.html, it's entirely
>free
>and there are no advertisements.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Command Line Cypher?
Date: Sun, 30 Apr 2000 23:22:21 GMT
Jimmy wrote:
>
> Thanks... the ole XOR encryption... yeah thats pretty secure :)
Technically he would have to write it as 'ch ^= 0xff' to get an xor
cipher....
And why not? Looks pretty good to me.
Tom
>
> Richard Heathfield wrote in message
> <[EMAIL PROTECTED]>...
> >Jimmy wrote:
> >>
> >> Anyone know of a decent command line stream cypher for *nix and NT?
> >>
> >
> >Here's one. It's so secure it doesn't need a key. It's called SNA-Coil,
> >and it works on the same principle as DES. What's more, you don't need a
> >separate decryption program. Here's the full source:
> >
> >#include <stdio.h>
> >
> >int main(int argc, char **argv)
> >{
> > FILE *fpin, *fpout;
> > unsigned char ch;
> >
> > if(argc > 2)
> > {
> > fpin = fopen(argv[1], "rb");
> > if(fpin != NULL)
> > {
> > fpout = fopen(argv[2], "wb");
> > if(fpout != NULL)
> > {
> > while(fread(&ch, 1, 1, fpin))
> > {
> > ch = ~ch;
> > fwrite(&ch, 1, 1, fpout);
> > }
> > if(ferror(fpin) || ferror(fpout))
> > {
> > printf("rats.\n");
> > }
> > fclose(fpout);
> > }
> > fclose(fpin);
> > }
> > }
> >
> > return 0;
> >}
> >
> >I defy anyone on this newsgroup to crack SNA-Coil.
> >
> >
> >V ubcr V'z abg gbb yngr sbe Ncevy Sbbyf Qnl <t>
> >
> >--
> >
> >Richard Heathfield
> >
> >"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> >
> >C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> >34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
> >to go)
--
Want your academic website listed on a free websearch engine? Then
please check out http://tomstdenis.n3.net/search.html, it's entirely
free
and there are no advertisements.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.privacy
Subject: Re: about search and seisure of computers again
Date: Sun, 30 Apr 2000 19:26:51 -0400
wipe by 3 passes under PGP ...
NO ONE recovered data, NO ONE provided prove,
that data wiped with above description has been recovered, except providing
over exaggerated statement that "it's maybe possible to recover" ...
correct me when I'm wrong, by facts not by myths only ...
I have f/d [ 1.44 mb ] wiped by pgp 3x information to recover, no one like to
be famous for attempting recovery, but many "experts" are arguing that data
recovery is possible after wiping it 7x times by pgp, which is more than 2
times wiped that I have ...
Anonymous wrote:
> Responding to the search and seisure thread:
>
> It's well known that if you delete something from your computer, it's
> usually not really deleted at all, and can be recovered by special
NORMAL software will recover, special is not needed ...
> software. What's the way to circumvent this, and to truly make sure
> things are deleted?
wipe by 3 passes under PGP ...
------------------------------
From: Michael Jarrells <[EMAIL PROTECTED]>
Subject: Deciphering Playfair
Date: Sun, 30 Apr 2000 09:57:17 -0400
Reply-To: [EMAIL PROTECTED]
I have been trying to decipher a Playfair ciphertext without luck. I
have known plaintext and my potential Playfair cipher deciphers and
enciphers the known plaintext message fine, but it doesn't work against
the other ciphertext I want to decipher.
How does one perform effective cryptanalysis on a Playfair enciphered
ciphertext in a ciphertext only situation?
Thanks for your help.
--
Michael Jarrells
http://jarrells.cjb.net
mailto:[EMAIL PROTECTED]
------------------------------
From: "Garry Anderson" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk
Subject: Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the
net"
Date: Mon, 1 May 2000 00:17:23 +0100
Hawke <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What is with the governments of this planet these days?
> they cannot even trust their own citizens?????
I believe it is a control thing.
They will know absolutely everything about you.
>From personal private and business emails and sites you visit they get your
hopes, fears and aspirations.
Captured data on you can be examined retrospectively for analysis, including
spending should they suspect you of illegal activity or tax evasion.
You may have to account for all cash flow.
They know what buttons to press, what you will respond to.
It will be like having a spy following you around all day - you will be
completely open to them.
See the number 1 UK organization - www.1UK.org
------------------------------
From: "Garry Anderson" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk
Subject: Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the
net"
Date: Mon, 1 May 2000 00:48:08 +0100
Hawke <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What is with the governments of this planet these days?
> they cannot even trust their own citizens?????
I believe it is a control thing.
They will know absolutely everything about you.
>From personal private and business emails and sites you visit they get your
hopes, fears and aspirations.
Captured data on you can be examined retrospectively for analysis, including
spending should they suspect you of illegal activity or tax evasion. You may
have to account for all cash flow.
They know what buttons to press, what you will respond to.
It will be like having a spy following you around all day - you will be
completely open to them.
See the number 1 UK organization - www.1UK.org
------------------------------
Subject: Re: How safe am I using a subset of the bytes returned by SHA-1?
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Mon, 01 May 2000 01:01:51 GMT
Mark Thomson <[EMAIL PROTECTED]> writes:
> What got me started on this was looking for a very fast way to
> determine if a file in our source code repository is different from
> the base that I'm working from. That would indicate someone else
> has checked in some changes (we have non-exclusive checkouts), which
> in turn means I will need to merge their changes with mine at my
> checkin time. Typical changes in this sort of setup will (I hope)
> give a different SHA / CRC32 / whatever.
If the other people who change the file won't try to circumvent a
checksum (aren't malicious), CRC32 is very fast and perfectly
appropriate for the task.
--
stanislav shalunov | Speaking only for myself.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Command Line Cypher?
Date: Mon, 01 May 2000 01:59:44 GMT
Jimmy <[EMAIL PROTECTED]> wrote:
> You wouldnt know where one could find such an old verison of pgp would you?
[...]
>>> Anyone know of a decent command line stream cypher for *nix and NT?
[...]
>>I think you can get pgp 2.6.2 for both... I dunno off hand.
>>
More to the point, which algorithms in any version of pgp are stream
ciphers? ;)
Last time I looked, pgpi and ftp.zedz.net had 2.6.2. I highly
recommend gpg over pgp for unix platforms though.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
Date: Sun, 30 Apr 2000 22:10:07 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Joystick as RNG
Tom St Denis wrote:
> Another rng idea is to use the input from a joystick. I wrote a small
> demo program (which I can share with anyone who asks, it runs on x86
> only...).
>
> A joystick essentially is just a series of bit fields comming in. One
> bit for the y axis and and 1 bit for the x-axis. When the joystick is
> dead-center the bits switch on and off with a prob 1/2. However the
> duration the bit is stuck doesn't appear to be less-than-random.
I don't know what drives your joystick, but it may be pulse width modulated
(PWM). PWM is often used as a kind of two-state-but-analog signal. It may
look chaotic (random) but it usually isn't.
>
>
> My idea is just todo this.
>
> int rngbit() {
> do {
> a = y_axis xor x_axis
> b = y_axis xor x_axis
> } while (a == b);
>
> return b;
> }
>
> Which removes runs of the same bits. Since almost everyone with a x86
> PC has a joystick anyways, this may be usefull..
>
> Has this ever been discussed before?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Joystick as RNG
Date: Mon, 01 May 2000 02:13:57 GMT
"Trevor L. Jackson, III" wrote:
>
> Tom St Denis wrote:
>
> > Another rng idea is to use the input from a joystick. I wrote a small
> > demo program (which I can share with anyone who asks, it runs on x86
> > only...).
> >
> > A joystick essentially is just a series of bit fields comming in. One
> > bit for the y axis and and 1 bit for the x-axis. When the joystick is
> > dead-center the bits switch on and off with a prob 1/2. However the
> > duration the bit is stuck doesn't appear to be less-than-random.
>
> I don't know what drives your joystick, but it may be pulse width modulated
> (PWM). PWM is often used as a kind of two-state-but-analog signal. It may
> look chaotic (random) but it usually isn't.
It's a "gravis-gamepad"... What I do now is take X samples (sample =
y_axis xor x_axis) (where X >= 32) and xor them together. With 20,000
bits output it passes the ENT tests quite well (except it's off by a
percent on the monte carlo).
I dunno if it would be cryptographically secure, but as a rng it seems
to work ok...
Of course it's none to quick either so it's only real use would be to
seed a good prng...
Tom
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: How would a 15 year old start?
Date: Mon, 01 May 2000 02:30:21 GMT
On 30 Apr 2000 14:33:58 GMT, David A Molnar <[EMAIL PROTECTED]> wrote:
>
>OK, let's add one more recommendation : _The Codebreakers_, by David Kahn.
>Excellent and engaging history of crypto, PLUS some technical info on how
>classical ciphers work. I'm sorry I didn't remember it earlier!
Bingo! I was about to suggest this, but you beat me to it.
Not only does it give a good layman's introduction to a lot of different
crypto methods, the historical overview is invaluable to understanding
everything from the necessity of cryptography, to the number of times
that supposedly "secure" systems have been broken (and how), to the
kinds of different careers that are possible under the umbrella of
"cryptography", and so on. Theory is great, but a grounding in
the real-world requirements and limitations of cryptography is
essential, and something that you simply can't fully grasp without
reading historical examples of codemaking and codebreaking.
This book is also a wonderful introduction to the "romance" of
the subject.
------------------------------
Reply-To: "Marty" <[EMAIL PROTECTED]>
From: "Marty" <[EMAIL PROTECTED]>
Subject: Re: Magnetic Remenance on hard drives.
Date: Sun, 30 Apr 2000 19:18:18 -0700
Some comments on recovering data.
Older technologies are most vulnerable. Disks today operate with much
higher intrinsic noise levels than earlier ones. They compensate with
extensive ECC (Error Correction Codes, not Eliptical Curve Codes). These
are robust formats but die with much smaller additional noise levels.
Newer disk media are thin film and have tightly coupled magnetic
domains. There is also a phenomina known as the zig-zag effect which
should increase entropy at the edges on subsequent writes. Disks that
are removable are much better candidates for data recovery than
non-removeable hard drives. It wouldn't surprise me that there are
techniques that can recover well over 50% of data on a floppy. This
would be especially true if the floppy was not overwritten on the same
drive as originally wrote it.
The basic technique is to do a code word search on the analog signal
recovered from an edge. Doing a full analog codeword search using not
only the block codes but the entire block with ecc and crc will probably
let you recover data with 5 or 6 dB more noise than the builtin
decoders. More if the data blocks are not "random." Encrypted bin
files will be MUCH harder to recover than text since more code words
exist so good practice would be to store files in encrypted form.
Quality STEG with floppys:
One of the more interesting possible things to do with a floppy would be
to record very long codewords, say having 24 bits of entropy per 512
byte block with maximum code distance between words. It would be
possible to overwrite it and yet the earlier codewords would be fairly
easily decodeable with analog capture and dsp techniques. To make this
most effective, encoded data spectra should be skewed to the lower
frequencies since they have the highest residuals on overwrite. You
could probably drill down another 20dB, but only if you knew the
codewords.
-Marty
------------------------------
Subject: Re: Science Daily overstates significance?
From: Diet NSA <[EMAIL PROTECTED]>
Date: Sun, 30 Apr 2000 19:47:17 -0700
In article <
8ech27$uut$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (William Rowden)
wrote:
>power. (Am I right in thinking that not all public-key methods
are
>easily parallelizable, and consequently vulnerable to quantum
>computing?)
>--
No, because, for example, there is a PK
cryptosystem called NTRU which is not
*currently* susceptible to
parallelization, yet could be vulnerable to
a new, different & quantum approach
(instead of the usual LLL methods).
To learn about NTRU see :
http://www.ntru.com
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: Command Line Cypher?
Date: 1 May 2000 02:53:36 GMT
In <8ei906$868$[EMAIL PROTECTED]> "Jimmy" <[EMAIL PROTECTED]> writes:
>Anyone know of a decent command line stream cypher for *nix and NT?
Check out...
http://ciphersaber.gurus.com/
This isn't quite what you're describing, but it's a good idea, and
might help you get what you're after.
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
OfUb/Q/gvcIAtVDQ7kbZelrae4GIXJT8mmn38wXEpdUjthIOaDBPen8LcEij9zNFJzRNoe0W
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.privacy
Subject: Re: about search and seisure of computers again
Date: Sun, 30 Apr 2000 22:58:17 -0400
Reply-To: [EMAIL PROTECTED]
On Sun, 30 Apr 2000 23:45:11 +0200, Anonymous
<[EMAIL PROTECTED]> wrote:
>Responding to the search and seisure thread:
>
>It's well known that if you delete something from your computer, it's
>usually not really deleted at all, and can be recovered by special
>software. What's the way to circumvent this, and to truly make sure
>things are deleted?
>
>One idea I came up with is to take a meaningless file, or a whole bunch
>of them, and copy them over and over onto the hard drive until it's
>full. then delete the copies of the file...then if they try to
>undelete, all they'll find is the deleted copies of that file.
>
>
This is (more or less) the simplest way in which overwriting of disk
data sectors unallocated (by the file system) to specific files is
done when you don't want to eliminate the existing files. It relies on
the file system to map to the clusters of data sectors, to reduce
sensitivity to differences between FAT file systems and NTFS.
It is essential, however, to properly readback-and-verify the
overwrites, to ensure that inadequate cache flushing (through
"helpful" features of Windows' VCACHE, for instance) hasn't defeated
the overwriting. Also, DoD Purging standards recommend the use of a
cryptographically strong pseudorandom byte stream for the final pass.
(The armed services' standards for disk data overwriting are NAVSO
P5239-26; AFSSI-5020; and AR 380-19. Purging per any of these
standards meets or exceeds the requirements for Sanitizing per
DOD5220.22-M. Cerberus Systems, Inc. happens to use the method from
the Navy standard, which meets or exceeds the other two standards.)
Overwriting of entire disks for declassification Purging is usually
done by direct sector-level commands, since not only all files, but
the partition tables and file system pointers are to be overwritten.
(Low-level formating of hard drives hasn't been possible for the last
several generations of devices - since the advent of servo tracking.
Logical "format" commands merely format a clean set of pointers to the
data sectors, which are left untouched. "Unconditional format" just
reads each cluster of sectors to "verify" it - no writing is done.)
Due to the inordinate amount of nonsense posted on the subject of
magnetic data remanence countermeasures, including spam about
"military overwriting" from people who've never been near a MIL-SPEC,
let alone had an EBI or SBI security clearance, I've added a few
paragraphs of a summary nature which I hope may be helpful:
<DISCLOSURE-of-INTEREST>
Cerberus Systems, Inc. develops, manufactures and markets
software cryptosystems designed to level 1 of FIPS PUB 140-1
with DOD 5220.22-M disk data recovery countermeasures.
</DISCLOSURE-of-INTEREST>
Forensic disk data recovery attacks attempt to read "deleted" (or
inadequately overwritten) magnetically stored data on your disk either
(1) through its drive controller connector, using PC-hosted software;
(2) through its drive heads, bypassing the disk's controller circuits;
or
(3) directly on each disk platter's recording surface in a clean-room.
Class 1 attacks can be mounted directly with forensic software, hosted
on your PC or (more often) on the attackers' PC, whose drive
controller cable is connected to your hard drive as a second ("slave")
drive. (This is to bypass any so-called "access controls" on your PC
and, in the case of lawful users, to provide for a clean evidentiary
custody trail that will survive court challenges).
These software-based "keyboard attacks" can be countered with
software-based countermeasures; viz., _any_ kind of disk data
overwriting (such as Clearing per DOD 5220.22-M) that is applied to
all sensitive plaintext on the disk.
Class 2 attacks use special amplifiers and signal processing to
extract previously recorded data from under subsequent overwrites.
This class of "laboratory attacks" relies on increased capabilities
over the disk's on-board electronics. Sanitizing per DOD 5220.22-M was
designed to counter such attacks by increasing the noise-to-signal
ratio beyond their capabilities.
Many (but not all) INFOSEC people believe that the increased
signal-processing sophistication of the on-board controllers required
to read even the last-written data on modern PRML-encoded drives has
kept Sanitizing ahead in this particular measure/countermeasure race.
However, most INFOSEC people strongly question the adequacy of
Sanitizing for protecting older, lower-density disks (especially
diskettes) against the most sophisticated Class 2 attacks.
Class 3 attacks (such as with magnetic force microscopy), are
generally considered able to penetrate any software countermeasures,
including _any_ kind of overwriting. This class of laboratory attacks
are very costly techniques to use to recover the complete
image-as-it-used-to-be of an overwritten multi-gigabyte disk, as
opposed to just "recovering" a few specifically targeted bytes.
In the US, state and local law enforcement is apparently limited to
forensic software techniques, relying on the FBI labs for high-profile
cases that justify spending large chunks of the prosecution budget.
(The new regional laboratory in San Diego is apparently an investment
in reducing a current or anticipated backlog of such cases.)
Obviously, non-law-enforcement users of forensic software (both lawful
users, such as attorneys doing "discovery" for criminal defenses or
for civil litigation, and others, such as industrial spies) can't rely
on FBI resources for either class of laboratory attacks.
The vast majority of disk data recovery services won't even quote the
recovery of singly-overwritten data (Cleared per DOD5220.22-M).
For instance, ESS Data Recovery (http://www.savemyfiles.com) says:
"Magnetic Media Microscopy (MMM) is used in cases where data has been
overwritten. MMM is a lengthy process that involves examining each
bit of data at a magnetic level to determine that bit's previous
state. Recovering just a floppy disk using this technology can take
days or weeks. MMM is rarely used because of the cost factor."
Nevertheless, any data of sufficient value to national police or
intelligence services (or comparably funded adversaries) should not
have its confidentiality rely upon overwriting countermeasures.
The value of your data to the kinds of attackers who can use each
class of techniques will determine whether you must counter that
class. Most people's personal e-mail is obviously in a different
category than oil- or gold-field exploration survey data on a laptop.
This is the basis for requiring defense contractors to use Clearing or
Sanitizing per DOD 5220.22-M (for re-use or for disposal,
respectively) of media containing SBU (Privacy Act or FOUO) data or
for data classified as Confidential or Secret, while requiring
NSA-approved degaussing and destruction for Top Secret media.
There is no such thing as absolute security. Information security
techniques are designed to counter specific technical attacks.
Specific attack measures are defeated (or sometimes only blunted
through delay), by specific INFOSEC countermeasures, designed to cost
less than the cost-of-compromise of the data to be protected.
Which INFOSEC countermeasures you need, and the adequacy or inadequacy
of those you have, can _only_ be measured against your particular
threat profile.
This requires identifying those to whom your data has value;
identifying the types of attacks which each potential class of
attacker is technically and financially able to mount; and choosing
INFOSEC countermeasures adequate to defeat the worst attack measures
you can _realistically_ expect them to employ against you.
An unclassifed 1991 Navy microcomputer INFOSEC risk analysis survey
postulated the nominal, per-incident, costs-of-compromise for Privacy
Act data or Confidential data as $10,000; for Secret data as $100,000;
and for generic Top Secret (TS) data as $1,000,000. Presumably, the
remainder of the hierarchy's list of value categories (TS/SIOP, TS/SCI
and TS/National Cryptologic) each added another zero to the cost.
These planning numbers would obviously be larger in today's dollars,
but they offer a relative scale that may provide some perspective to
help you associate classes of attack measures with the values placed
on your data - by you and by your adversaries.
Randomly selected collections of countermeasures that seem technically
intriguing or fashionable among the pseudo-knowledgable usually
include "protections" you don't need, and often lack the ones you do.
The Cerberus Systems, Inc. web-site contains a library of (US) federal
cryptographic security standards, and tutorials on the difficulties of
meeting them on the notoriously INFOSEC-hostile "Wintel" platforms.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
** 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
******************************
