Cryptography-Digest Digest #45, Volume #12 Fri, 16 Jun 00 17:13:00 EDT
Contents:
Re: obfuscating the RSA private key (Mike Rosing)
Re: Flattening of frequency distributions (Mok-Kong Shen)
Re: Cipher design a fading field? ("Trevor L. Jackson, III")
Re: Extending LFSR...... ("Douglas A. Gwyn")
Re: Encryption on missing hard-drives ("John E. Kuslich")
Re: Flattening of frequency distributions (Bill Unruh)
Re: How RSA SecurID tokens work? (Paul Rubin)
Re: Observer 4/6/2000: "Your privacy ends here" (Mok-Kong Shen)
Re: Observer 4/6/2000: "Your privacy ends here" (Mok-Kong Shen)
Re: Flattening of frequency distributions (Mok-Kong Shen)
Re: How RSA SecurID tokens work? (Vin McLellan)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(Tim Tyler)
Re: How RSA SecurID tokens work? (Roger Schlafly)
Re: Observer 4/6/2000: "Your privacy ends here" (Colin)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: obfuscating the RSA private key
Date: Fri, 16 Jun 2000 12:51:18 -0500
Mark Wooding wrote:
>
> Mack <[EMAIL PROTECTED]> wrote:
>
> > The most common form of threshold scheme relies on N-spacial geometry.
>
> Does it? I thought the most usual threshold scheme was Shamir's, which
> uses polynomial interpolation in a finite field.
And you're both right!
:-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Flattening of frequency distributions
Date: Fri, 16 Jun 2000 20:29:56 +0200
"Frank M. Siegert" wrote:
> Just an idea... why not using several text streams created by an
> "eddington ape" algorithm* (were each stream is created according to a
> different cryptographically strong RNG) and xor (or add modulo,
> subtract modulo or decoding) the streams together.
>
> As each stream has a similar character distribution as plain text
> (English or whatever langauge and text books you setup the 'apes' to
> use) the original text should be effectively hidden.
>
> * see Article from Scientific American 1983, or in German 'Spektrum
> der Wissenschaft' 2/1984
I was suggesting a rather cheap add-on for use in conjunction with any
chosen cipher currently used in practice. You are apparently addressing
the issue of means of generation of high quality random sequences that
approximate the quality of OTP such that one can attain with it very high
security. So I think this is at quite a distance beyond my present theme.
But I do believe that your (bigger, more essential) issue deserves more
(renewed) thoughts being spent on it, even though there had been
several times quite an amount of discussions in our group. (I intend to
initiate a thread on that sometime later, if nobody else does it.)
M. K. Shen
------------------------------
Date: Fri, 16 Jun 2000 15:15:12 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Alan Braggins wrote:
> [EMAIL PROTECTED] (Mark Wooding) writes:
> > Alan Braggins <[EMAIL PROTECTED]> wrote:
> > > We can extend this to any given finite size example program P.
> >
> > Aha. I see the problem. Your two programs are different sorts of
> > things. Your program to decide the haltingness of something accepts a
> > program as input and reports an answer; the programs which are its
> > arguments don't accept input.
>
> Or at least they only accept a finite amount of input, since then we can
> just encode the possible inputs along with the program (e.g. stick the
> program encoding and its input on a finite length input to a Universal
> Turing machine).
> Which I think means my post was a valid illustration of the argument
> someone else was making earlier, but that that argument (and my post)
> was wrong if we include finite programs taking a potentially infinite
> input, which we should. Rats. This is what comes of not thinking
> carefully enough before making sci.crypt postings when bored waiting
> for a long compile to halt....
How can you conclude that a program accepting an infinite input halts? Either
it stops reading input after a finite amout, or it attempts to read it "all".
The latter is a condition that does not halt.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Extending LFSR......
Date: Fri, 16 Jun 2000 17:58:16 GMT
Simon Johnson wrote:
> The first question that struck me when i started reading about
> these is why mod 2?
For the same reason that digital computers are all binary these days.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Fri, 16 Jun 2000 11:42:56 -0700
Sorry,
I hate to be paranoid but...
DO NOT BELIEVE anything you federal government says about national security!
Period, end of sentence.
These guys will say anything, promote any disinformation do anything for the
sake of "National Security".
"Wanna see the red suit...turn on the red light..."
There are so many unanswered questions:
Like...Have there been so many actual cases of A-bombs needing dismantling
that there was a suitcase full of goodies necessary to do the job right
there at hand with a spare set of keys??? PALEEZE don't tell me that the US
gummint is really on the ball when it comes to anti-terrorist
capability...it is just not what we are used to.
So how many A-bombs have been dismantled in say...Chicago or Washington or
New York in say the past couple of weeks...maybe eight or ten???
An actual suitcase with A-bomb dismantling instructions...gimme a break. Oh
yeah, and it was encrypted...right...so the encryption key could be lost
just when that A-bomb is down to its last few tick-tocks...Right!
At CRAK software we are ready for this possibility...you bet...the phone
rings...it's Secretary Richardson...there's an A-Bomb in Monica Lewinski's
closet right next to a box of smelly cigars...CRAK Software snaps into
action, grabs the knapsack with the CRAK Software in it and shazam...the
world is safe...It could happen. We keep the knapsack unlocked. It only
contains a ham sandwich and a Snickers bar.
JK http://www.crak.com Password Recovery Software
<[EMAIL PROTECTED]> wrote in message
news:8id7d0$j55$[EMAIL PROTECTED]...
> I'm sure we've all read or heard the news lately about the
> security "lapses" at some government facilites with respect to computer
> equipment (first laptops at the State Dept, now hard drives from Los
> Alamos). In both cases, officials have responded that no secrets are in
> jepardy because the equipment uses encryption.
>
> So, I'm thinking, yeah, with PGP or some other stong encryption, that
> data is probably secure. Then I realize, hey wait a minute, we're
> talking the Fed Gov't here! They don't use PGP! The Feds are generally
> the ones who pooh-pooh breaks, cracks and glitches turned up by
> the "amateur" hacker community.
>
> So, now I'm curious.
>
> What *do* they use? What is the current "state-of-the-art" GAO approved
> encryption system. Please don't tell me they still you single round
> DES! Kiss that data good-bye!
>
> Anyone know?
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Flattening of frequency distributions
Date: 16 Jun 2000 19:34:00 GMT
In <[EMAIL PROTECTED]> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>Exploiting knowledge of frequency distributions of plaintexts
>is one of the major tools of analysts in classical cryptology.
>Even if some modern ciphers are believed by many to be strong
>enough for direct encryption of natural language messages, I
>suppose it can nontheless be justifiable to do preprocessing
>to flatten the frequency distributions of single letters and
>n-grams, if one is conservative in matters of security.
Probably the best frequency flattener is probably another of the modern
cyphers. Thus you could encrypt using say RC4 first and then your other
favourite crypto system. What this would buy you is not at all clear.
Even a simple block cypher encrypts 8 characters at a time and thus the
relevant frequency is that of 8 byte blocks in the plain text (not
terribly usefull).This discussion seems to be of the "If one is good a
whole bunch is better" school. It would seem much preferable to use a
cypher which was resistant to such attacks than to try to cobble
together a bunch of things and hope the result is resistant.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: How RSA SecurID tokens work?
Date: 16 Jun 2000 19:36:38 GMT
tomstd <[EMAIL PROTECTED]> wrote:
>How exactly will my server know what the secret displayed number
>on the lcd is supposed to be at a specific time? Is there a
>database of the secret keys?
Yes.
>I find that to be a point of attack in the system.
Why? What do you propose instead, that doesn't require any secrets?
>>The secrecy of Brainard's one-way function is really just an
>>artifact of committments made by RSA (then Security Dynamics) to its
>>customers ten years ago, when that was what was required in the
>>market.
>
>And no other problems...I have a hard time believing this.
There's no way to know without seeing the function, but I don't have
that hard a time believing Security Dynamics knew what it was doing
when it implemented that function.
>Sure gimme 10k and I will say it's secure as well. I just can't
>see how both the server and token can come up with the same
>secret 6-8 digit number (mine are 6 digits) unless some hidden
>information is embeded in the device and server. This is
>obscurity not security.
That's what he said--there is a shared secret between the device
and the server. To get the secret out of the device, the attacker
would have to physically capture it, take it apart, etc. Maybe
s/he can get it out of the server, but that means the server is
insecure to begin with, so the attack really wasn't needed.
>So if I steal a ACE database I can get access to all the secret
>seeds? Sweet.
It does seem to mean that Security Dynamics can reconstruct all the
codes, which isn't so great. That's an artifact of the hardware
though (no way to put new keys in the device), not the design.
------------------------------
From: Mok-Kong Shen <[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,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Fri, 16 Jun 2000 18:10:34 +0200
Colin wrote:
> >> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >You didn't read a previous post of mine which had a bit detail saying
> >that the key, a seed of a PRNG, is sent as a prefix to the ciphertext.
> >So handing over the key is trivial and I remain outside of the prison :)
>
> You could also modify your method to serve as an offbeat steganographic
> algorithm:
>
> If you were feeling malicious, you wouldn't use a 'set text' - you'd
> start with a one byte message (e.g. "G"). Get your 'key' from a genuine
> RNG, and use it to seed the PRNG to encrypt your one-byte file.
>
> Then you'd get another 'key' for the PRNG from the RNG and encrypt the
> cypher-text + the first key. Then repeat the process a few hundreds of
> thousands of times.
>
> The Men In Black have no reliable way of telling whether or not, at
> iteration n, there is a genuine cypher-text - if there is, it would
> still unvravel to an arbitrary, single byte 'plaintext' if the reverse
> algorithm were applied to it.
>
> Are they going to serve you with warrants to disclose the 'key' to
> all of the thousands of possible cypher-texts in the document, in the
> vague hope that one of them will decode to something incriminating?
>
> They have to decide for themselves whether the file contains one byte
> of information + 100k of junk, 100k of encrypted information + no junk,
> or something in between. Then a judge has to be convinced of their
> reasons for beliveing this.
As far as I understand, the requirement of your handing over the key
to them is to enable them to see the message. They wouldn't accept,
if you hand over just anything to them that doesn't decrypt to readable
stuffs. In effect, you have to decrypt in front of them, even if you
may not necessarily do that physically. If you employ true random stuffs,
then you have (management) problems in decryption. Thus I don't yet
understand why you need that.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[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,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Fri, 16 Jun 2000 18:10:39 +0200
Paul Shirley wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> writes
> >You didn't read a previous post of mine which had a bit detail saying
> >that the key, a seed of a PRNG, is sent as a prefix to the ciphertext.
> >So handing over the key is trivial and I remain outside of the prison :)
>
> You still *don't understand*.
>
> If there's a message you are subject to RIP. The key is irrelevant, as
> long as you encrypted *anything* RIP applies. Sending the key with it
> potentially stops them taking any action against you, but it also stops
> them wasting time in decryption attempts or in courts. So what's the
> point?
As I said the scheme is not for conveying any 'normal' messages between
the partners. It serves only the purpose to waste resources of the
interception organizations. Yes, there is a 'message'. If that 'message' is
something, say, copied from Shakespeare's work, would I have any
troubles? The key is in hexs, just like the hexs of the ciphertext. You need
not always put the key at the front. You cound make it as your personal
convention to start e.g. at the 23rd hex. How are they going to know that
before you tell them after they ask you to do that? Note also that they
don't know which PRNG is used until you tell them.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Flattening of frequency distributions
Date: Fri, 16 Jun 2000 22:14:05 +0200
Bill Unruh wrote:
> Probably the best frequency flattener is probably another of the modern
> cyphers. Thus you could encrypt using say RC4 first and then your other
> favourite crypto system. What this would buy you is not at all clear.
> Even a simple block cypher encrypts 8 characters at a time and thus the
> relevant frequency is that of 8 byte blocks in the plain text (not
> terribly usefull).This discussion seems to be of the "If one is good a
> whole bunch is better" school. It would seem much preferable to use a
> cypher which was resistant to such attacks than to try to cobble
> together a bunch of things and hope the result is resistant.
I don't agree with your 8 byte argument. If you use a stack of two
good ciphers, then the output of the first should have an almost entirely
flat frequency, isn't it?
M. K. Shen
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Subject: Re: How RSA SecurID tokens work?
Date: Fri, 16 Jun 2000 16:33:58 -0400
> [tomstd asked:]
> >
> > >Given the serial number and the current time how does the RSA
> > >SecurID tokens create their PIN outputs?
>
Vin McLellan <[EMAIL PROTECTED]> replied:
> > ACE/SecurID is a two-factor authentication system; the 60-second
> 6-8
> >digit "token code" which is continually displayed on the LCD on the
> face
> >of the token, and the user-memorized PIN are both required for a
> valid
> >authentication request to an ACE/Server, RSA's authentication server.
>
> >
> > The SecurID uses a 10 year-old proprietary algorithm by John
> >Brainard, now with RSA Labs, to hash Current Time and a
> >factory-installed token-specific secret key to produce the
> token-code.
tomstd scratched his head and asked:
> How exactly will my server know what the secret displayed number
> on the lcd is supposed to be at a specific time? Is there a
> database of the secret keys?
Sorry if I was unclear. Yes, there is a database of token-specific
secret keys held at the authentication server (ACE/Server, in RSA
parlance).
The token and the ACE/Server both hash that shared secret and
"Current Time" to generate a SecurID token-code (actually, three: for
the what the ACE/Server predicts this token will use as "Current Time,"
and for the minute before and the minute after that).
A pre-registered user is authenticated and given access to the
protected resources only if:
(1) the user-submitted PIN matches the PIN stored in that user's data
file on the ACE/Server, and
(2) the SecurID token-code submitted by the user matches the
ACE/Server's calculation of what the token-code (for that particular
token at this particular time) is supposed to be.
(There is, of course, a small library of rules which maintain the
integrity of the process. The most notable of those are the rule which
forbids an ACE/Server from accepting an identical token-code from the
same SecurID more than once; which require that the ACE/Server reject
any token-codes which appear to come out of proper time sequence; and
which close down a user account, temporarily or permanently, if a
certain number of incorrect PIN/token-code combinations are submitted by
someone purporting to be a valid user.
> I find that to be a point of attack in the system.
Good luck;-)
> >The secrecy of Brainard's one-way function is really just an
> artifact
> >of committments made by RSA (then Security Dynamics) to its customers
>
> >ten years ago, when that was what was required in the market.
>
> And no other problems...I have a hard time believing this.
Ah, to watch the successive generations of cynics trapse through the
newsgroups is heartening. Non-believers to seed the future!
Got any particular nasty suspicions you want to discuss or declare?
When the Brainard hash is retired with the new generation of SecurID
(which will use Rivest's RC6), I want RSA to put this grand ol' lady
hash in some sort of digital museum.
Brainard's one-way function is one of the most widely used (6
million-plus "installations") and widely-trusted crypto algorithms ever
to grace the infosec market. Mind you, the threat scenario is also
somewhat unusual for a hash. A SecurID token-code is a one-time password
and only has value for a minute or two.
Still, I think the continued viability of Brainard's SecurID hash a
decade after it was first brought to market is amazing.
> > RSA (ne SDI) has been saying for all of that time that the
> security
> >and integrity of the process by which SecurIDs generate their
> >token-codes is not dependant on the secrecy of the algorithm. While
> >unpublished, the SecurID hash has been widely studied by numerous
> >governments and their cryptographic agencies, as well as many
> >corporations, before it was accepted and installed by those RSA
> >customers.
> Sure gimme 10k and I will say it's secure as well.
The greater marketing challenge is to get some crypto-savvy
corporation or national security agency to study the hash and then
determine that it is worthy of being used to safeguard access to
national secrets or corporate crown jewels.
Oh, yes, you also have the payment process reversed. Typically, the
buyers (after satisfying themselves as to the integrity of the process)
shovel the cash over toward RSA, rather than the other way around. (I
also recommend you review your rates. Selling your personal integrity
for US10K is a Faustian fire-sale, and you'll destoy the market for the
rest of us.)
> I just can't
> see how both the server and token can come up with the same
> secret 6-8 digit number (mine are 6 digits) unless some hidden
> information is embeded in the device and server. This is
> obscurity not security.
I apparently failed to get the mechanics across with my initial
post. I beg your pardon yet again.
Each token does indeed share a secret seed with the authentication
server it is registered to.
A shared secret, an irreversible hash, and the two-factor process
for user-authentication (something you know, something you have) provide
the foundation for the ACE/SecurID system.
> > (In the US, to highlight the local scene, SecurIDs are carried by
>
> >all White House staffers, all US Senators, and numerous staffers in
> the
> >NSA, CIA, and DoD.)
> >
> > The serial number, embossed on the back of most SecurID tokens
> (card
> >or key fobs) is not relevant to the generation of the token- codes.
> The
> >internal processor of a SecurID isn't even aware of the serial number
>
> >associated with that token.
> >
> > The encrypted memory file in the ACE/Server does use the token's
> >serial number to index the token's the secret seed or key used in the
>
> >token's internal calculation. That file is used to record the users
> >chosen or assigned PIN, and it also maintains an ongoing calculation
> of
> >the relative accuracy of each SecurID's internal clock, using the
> >Server's clock as the baseline.
>
> So if I steal a ACE database I can get access to all the secret
> seeds? Sweet.
Yup. Ain't it? The world is your oyster. Don't know the current
numbers, but a few years ago the industry estimate was that SecurID
tokens held over 70 percent of the market for two-factor user
authentication, in corporate installations with over 1,500 seats.
> > A user submits a user name, SecurID token code, and the memorized
>
> >PIN to an ACE/Agent for relay to the ACE/Server.
> >
> > The ACE/Server then pulls up the file for that user, and uses the
>
> >token-specific seed and Current Time (adjusted as required by the
> >notation about the token's clock-chip) to generate a token-code --
> >actually, to deal with "drift," three consecutive token-code -- which
>
> >are matched against the name, PIN, and SecurID token-code submitted
> by
> >the user.
> >
> > Hope this helps. I've been a consultant to RSA, and earlier,
> >Security Dynamics, for many years. Please feel free to ask if you
> need
> >any additional info. The spring issue of 2600, believe it or not, has
> a
> >pretty detailed overview of the SecurID technology.
>
> I will look at it, but from what I can tell it's not security
> rather obscurity.
We are dealing with either limitations in what you can be told, or
limitations in my ability to tell. I, unfortunately, have a genetic
propensity to snide retorts (which I think I am restraining fairly well,
aren't I?)
It is late on a Friday and I am frankly not certain which of us is
to blame.
> I am not sure on the hierarchy of the Servers but it doesn't
> seem right to me.
See? Perfect example of why I can't trust myself to reply to a
cantankerous message at the end of day on a Friday.
I have't the faintest idea what you are referring to with your
portentous reference to the "hierarchy of the Servers." Feel free to
enlighten me; damn me for a dunderhead; or ask any other questions about
ACE/SecurID.
Suerte,
_Vin
------------------------------
Crossposted-To: sci.crypt.random-numbers
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Comments/analysis requested: stream cipher derived from hash function
(SHA-1)
Reply-To: [EMAIL PROTECTED]
Date: Fri, 16 Jun 2000 20:02:00 GMT
In sci.crypt.random-numbers Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> OTOH, if H contains a small quantity of entropy, you can /potentially/
:> defeat an attacker who has learned the state by accumulating the
:> entropy - and then performing the infamous "catastrophic reseeding".
:>
:> If you dripple the entropy into the system as you go along then the
:> attacker can perform the "state following" attack to maintain his
:> knowledge of the internal state by repeated guesswork.
: I have a PRNG which has 260 words of state, and each call uses 8 words,
: changes 5 words, and outputs one word. If my 'dribble' of state isn't
: added where it directly affects a particular call, I don't think an
: attacker can use repeated guesswork.
: If I add my bits of entropy into m[d] (just before ++d), the attacker
: won't see the effect of those particular TRNG bits until some time
: later.
Whether repeated guesswork is feasible under such circumstances
probably depends a number of things, including the rate of the dribble.
If the rate of dribble is low compared to the time taken for it to
percolate through the system an appear in the output, state-following
attacks might be possible and should be seriously considered.
There's also the possibility that the time taken for entropy input
to affect the output might be approximately constant. If so, increasing
the delay will mean more work for the attacker following the state -
since he has to churn through the delay period with each guess he makes
- but it won't make things *that* much more difficult.
If you /don't/ maintain a pool on entropy and periodically use large
chunks of it, state-following attacks are certainly often a /potential/
source of concern.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: How RSA SecurID tokens work?
Date: Fri, 16 Jun 2000 13:39:06 -0700
Paul Rubin wrote:
> That's what he said--there is a shared secret between the device
> and the server. To get the secret out of the device, the attacker
> would have to physically capture it, take it apart, etc. Maybe
> s/he can get it out of the server, but that means the server is
> insecure to begin with, so the attack really wasn't needed.
Or find some weakness in the pseudorandom number generator
in which info about the secret is leaked in the 6-digit codes
that are transmitted.
------------------------------
From: [EMAIL PROTECTED] (Colin)
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,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: 16 Jun 2000 20:30:46 GMT
On Fri, 16 Jun 2000 18:10:34 +0200, Mok-Kong Shen wrote:
[...]
>As far as I understand, the requirement of your handing over the key
>to them is to enable them to see the message. They wouldn't accept,
>if you hand over just anything to them that doesn't decrypt to readable
>stuffs.
I was being a little tongue-in-cheek, but the point I was driving at was
that at some point, the MIB have to convince a (possibly sceptical)
judge that the file in question does contain a covert message.
Your being able to demonstrate a valid (if rather pointless) reason
for the file's contents makes this task that much harder for them.
There are, of course, far more practical steganographic methods
available to us all.
>In effect, you have to decrypt in front of them, even if you
>may not necessarily do that physically. If you employ true random stuffs,
>then you have (management) problems in decryption. Thus I don't yet
>understand why you need that.
Well, things may get interesting if they start snooping around my hard
disks - there are quite a few *genuinely* random files on my machines,
for various purposes, and also a number of similar files containing
encrypted data with no signature blocks etc.
I'm asked by the MIB for the 'key' to them all. Do I:
a) Hand over keys for the encrypted ones and try to convince them that
the random data tables aren't, in fact, the *real* subversive stuff
(as opposed to the personal correspondence etc. in the encrypted ones).
b) Explain to them that they're *all* random data tables, and hope they
believe me.
c) Tell them to fuck off, and I'll see them in court.
d) Keep my head down and don't ever email or speak to anyone again,
just in case they're the friend of a friend of a drug-dealing,
gun-running, baby-buggering terrorist-sympathiser, whom the MIB
want to nail.
None of the above seem particularly appealing, though.
Regards, Colin.
--
"It's the only thing I can't lie about."
Tony Blair, on cooking (CEEFAX 1 p146-1, 8/4/00).
------------------------------
** 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
******************************
