Cryptography-Digest Digest #195, Volume #12 Mon, 10 Jul 00 19:13:01 EDT
Contents:
Re: Steganographic encryption system (jungle)
Re: Proposal of some processor instructions for cryptographical applications
(Maynard Handley)
One plaintext, multiple keys (Doug Kuhlman)
Re: acquire a secret authentication cipher bloc (Paul Koning)
Re: Random Numbers (Paul Koning)
Re: Proposal of some processor instructions for cryptographical (Terje Mathisen)
Re: Proposal of some processor instructions for cryptographical (Terje Mathisen)
Re: Steganographic encryption system (Garry Knight)
Re: acquire a secret authentication cipher bloc (David A. Wagner)
Re: One plaintext, multiple keys (S. T. L.)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Proposal of some processor instructions for cryptographical applications (phil
hunt)
Re: One plaintext, multiple keys ("Paul Pires")
Re: Use of EPR "paradox" in cryptography (Bill Unruh)
Re: Quantum Computing (Was: Newbie question about factoring) (Bill Unruh)
Re: One plaintext, multiple keys (David A Molnar)
SCRAMdisk or PGPdisk? (Simon Hogg)
----------------------------------------------------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Mon, 10 Jul 2000 16:10:01 -0400
"Bob Billing (AKA Uncle Bob)" wrote:
>
> jungle wrote:
> >
> > your concept doesn't work ...
>
> This is entirely false. Any number of messages may be embedded if the
> cyphertext is long enough.
your statement it is NOT the quintessence of my post ...
------------------------------
From: [EMAIL PROTECTED] (Maynard Handley)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Mon, 10 Jul 2000 13:21:13 -0700
In article <[EMAIL PROTECTED]>, Konrad Schwarz
<[EMAIL PROTECTED]> wrote:
>Al Grant schrieb:
>>
>> Is that a worse issue than byte addressing? With today's
>> processors, isn't the concept of 'byte' just as artificial as that
>> of 'bit', and wouldn't it be easy to extend the hardware already
>> in place to support byte addressing to support bits as well?
>
>From an abstract point of view, possibly. From a practical
>point of view, I beleive not: the investment in byte addressable
>hardware is just too large and the payoff of bit-addressing too small.
Well the solution, on Intel HW, is easy. Define a new type of segment,
with the attribute "bit addressed".
Maynard
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: One plaintext, multiple keys
Date: Mon, 10 Jul 2000 15:12:24 -0500
Hey all,
Got a couple questions. In a certain protocol, I can imagine a new
type of attack. The attacker has access to the ciphertext of one
plaintext encrypted with multiple keys. That is, he has C_1, C_2, ... ,
C_n where C_i=E(K_i,P) (K_i != K_j for i != j). Does this help the
attacker? How much?
Related question. If my encryption algorithm is OTP, then it seems
like this should be insecure, since it basically amounts to reusing P
(the fixed plaintext) as a key. But how exactly would that attack work?
Thanks,
Doug
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: acquire a secret authentication cipher bloc
Date: Mon, 10 Jul 2000 16:53:23 -0400
NP wrote:
>
> Hello
>
> How can I acquire a secret authentication cipher bloc
> for electronic component ?
>
> Cipher bloc must be hardware compliant (< 500 gates)
It's hard to see how you could do something meaningful
in that small a gate count.
> Key length: 64 bits
> Signature result: 8-16 bits
If you want a signature that small, you might as well
just tie all the bits to ground. The security would
not be significantly affected by doing so.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Random Numbers
Date: Mon, 10 Jul 2000 16:55:17 -0400
John Savard wrote:
> ...But the simplest rule for producing truly random bits
> from biased bits is to use this table:
>
> 00 : discard
> 01 : 0
> 10 : 1
> 11 : discard
Shouldn't that be "less biased bits from biased bits"?
If there is correlation over lengths greater than 2, this
approach alone is not sufficient.
If I remember right, this algorithm was first suggested
by John von Neumann.
paul
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Mon, 10 Jul 2000 19:02:06 +0200
Stephen Fuld wrote:
>
> "Terje Mathisen" <[EMAIL PROTECTED]> wrote in message
> > Since I (with 3 others) wrote the asm code for one of the original AES
> > submissions,
>
> Terje, I continue to be amazed with the things you have done. And you
> presumably find time to do the stuff that Hydro pays you for!
As others have remarked in email to me, the secret is to not allow your
work to impede upon your hobbies.
Sometimes the stuff I learn doing what I love actually comes in handy in
my daytime job as well. :-)
> > The one thing that's missing from the AES code is bignum arithmetic, for
> > setup/authentication, but this is being adressed anyway.
>
> Well, I am sure you know that AES, being for a DES replacement was for a
> private key system where bignum isn't needed. This is where the big use of
> cycles is as the public key stuff (needing bignums) is typically used only
> for session key exchange, etc. with the bulk of the data using private key.
> but you knew that :-).
I hope we all know that, but session setup is still important enough
that the server end, at least today, needs dedicated hw assist. The
problem is "simply" to make cpu cycles cheaper at a faster rate than the
WAN guys are increasing the bandwidth of their fibers, and as we
discussed a few days ago re. dense wavelength division multiplexing,
this is a tough task. :-)
It does look like IA64, if not Merced, could be capable of doing this,
since it becomes feasible to keep even 2048-bit keys inside a range of
cpu registers.
This is close to (or maybe over) the limit though, since a bignum-style
mul really needs to work with carry-save format numbers, thereby
requiring twice as many regs: 64 instead of 32 for a 2048-bit value.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Mon, 10 Jul 2000 19:32:14 +0200
Mok-Kong Shen wrote:
>
> Terje Mathisen wrote:
> > So, do you want something like a fixed 6-register block, where the first
> > register to be used is specified as part of the instruction, or do you
> > want to have a 384-bit immediate operand to the opcode?
>
> I now understand. You mean one needs 384 bits as an operand to
> be supplied to the instruction. I would even be ready to use 8*64 bits,
> i.e. letting each bit position be specified in one byte which may be more
> convenient to handle. This operand, being large, is in memory and is
> referenced by address.
Please!
You did intend for this instruction to _speed up_ your crypto sw, right?
Having a 48 or 64-byte memory operand would _not_ be compatible with
being fast, unless you want your hw to virtualize this table, storing it
totally inside a special-purpose hw register inside the cpu, and then
snoop all memory accesses to the memory table, so that it could be
reloaded only when actually modified.
This would still only work for a single table, how many would you need?
How many should be cached inside the cpu?
If you must have such a capability, it makes a lot more sense to
synthesize it out of a set of smaller building-block operations, maybe
based on byte-sized or smaller lookup tables. (I.e. ref the Altivec
permute op).
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (Garry Knight)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Mon, 10 Jul 2000 22:51:37 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>I am thinking of developing a steganographic encryption system
[...]
>(1) does anything like this exist already?
ScramDisk (for Windows) incorporates this kind of technology.
http://home.clara.net/scramdisk/
>(2) What's a good private-key cypher algorithm to use?
[...]
>Would Blowfish be a good algorithm to use?
ScramDisk uses several algorithms which the user gets to choose.
Blowfish is the one that's recommended by the author.
I'm sure you also realise a potential drawback to using .jpg files: that
they incorporate lossy compression? It shouldn't be a problem as long as
the user does a one-shot encoding into a .jpg file and doesn't try
loading it then saving it using a graphics package.
--
Garry Knight
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: acquire a secret authentication cipher bloc
Date: 10 Jul 2000 15:02:39 -0700
In article <8kc46g$o6f$[EMAIL PROTECTED]>, NP <[EMAIL PROTECTED]> wrote:
> Cipher bloc must be hardware compliant (< 500 gates)
500 gates? Whew. Probably your best bet is to use a CRC-based
Carter-Wegman universal hashing MAC.
Pick a stream cipher that you trust -- it can be slow -- that fits in
under 400 gates. An A5/1 variant might do the trick, if you double
the size of all registers and pick suitably dense feedback polynomials,
but it might be safer to use 1000 rounds of a Feistel with a very simple
round function (rounds are essentially free in terms of gate count).
Now, for each message you want to hash, you crank the stream cipher
to generate another 16 bits of output. Fill a 16-bit shift register
with zeros. Use the 16 bits of output from the stream cipher as your
feedback polynomial for the CRC. CRC-hash the message (with random salt
prepended, and with a 1-bit followed by 16 0-bits appended). Use the
result as your 16-bit MAC.
I'm no good at hardware, but it seems to me that the 16-bit shift register
should require under 100 gates, so if you can get your stream cipher in
under 400 gates, you should be in great shape.
Note: I'd seriously consider using a 32-bit or 40-bit MAC instead of a
16-bit MAC. I realize that this is very application-dependent, but 16
bits is pretty small.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: One plaintext, multiple keys
Date: 10 Jul 2000 22:09:01 GMT
<<If my encryption algorithm is OTP, then it seems like this should be
insecure, since it basically amounts to reusing P
(the fixed plaintext) as a key.>>
No, not the same. If you are using an "OTP" but have moronically used a key
twice, then you have P1 XOR K1 = C1 and P2 XOR K1 = C2. Then C1 XOR C2 = P1
XOR P2 and any two plaintexts XORed together leaks the contents rather easily.
But if you are using an OTP correctly, and send the same message twice using
two different keys, then you have P1 XOR K1 = C1 and P1 XOR K2 = C2. And then
C1 XOR C2 = K1 XOR K2, which is two random keys XORed together, which is
equally random garbage. Plaintexts are not keys. Nothing can be leaked by an
OTP used properly. Other algorithms can leak if you repeatedly send the same
plaintext enciphered with different keys.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
Now **108** reviews of my 169 science books. Other pages up:
Review of the _Foundation_ series, Jet Fighter Paper Airplane page,
LASTLY Shrine, Files for Download!
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Mon, 10 Jul 2000 21:04:20 +0100
Reply-To: [EMAIL PROTECTED]
On 10 Jul 2000 19:59:28 +0100, John Winters <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, jungle <[EMAIL PROTECTED]> wrote:
>>phil hunt wrote:
>>> I am thinking of developing a steganographic encryption system that
>>> will enable a particular cyphertext to be decrypted into two or more
>>> different plaintexts, depending on which key is used. (Provisionally
>>> named 'stes'). To be more precise:
>>
>>your concept doesn't work ...
>>you can't create system that will work on principle that ...
>>
>>24 decrypts into 20 or/and 21 or/and 22 or/and 23 or/and ...
>>[ number represents file size in kb OR mb OR ... ]
>
>You can if you use OTP, but OTOH your "keys" would need to be the same
>size as your encrypted texts.
Not at all. For example, I could encrypt 3 texts, of size 1k, 5k, and 10k,
and if the resultant cyphertext file was 30k, I'd have plenty of room to
hold them all. (Different bits of the cyphertext file code for the
different plaintexts).
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Steganographic encryption system
Date: Mon, 10 Jul 2000 21:16:52 +0100
Reply-To: [EMAIL PROTECTED]
On Mon, 10 Jul 2000 11:51:45 -0700, Joseph Ashwood <[EMAIL PROTECTED]> wrote:
>[uk.comp.os.linux removed due to newsserver limitations, please feel free to
>re-add them in replies]
>
>As was said before this sounds very similar to Rivest's Winnowing and
>Chaffing, for which there are some rather intersting ways of speeding it up.
>I would like to suggest one change, don't structure your file so that given
>a key you can immediately determine if there is useful information, by doing
>that you immediately (minorly) compromise the security, instead, what I
>would suggest is that you make use of an All-Or-Nothing-Transform on the
>files (with padding) before performing your stego.
This idea sounds interesting, but unfortunately I don't understand it.
Could you go into more detail?
If I have an encrypted file, and a key which purports to be a valid key
for my system, then surely anyone who knows the algorithm I'm using will
be able to easily find out whether the key is valid, by getting the data?
(Or are you saying that invalid keys should produce random-looking
data, but no indication that the key is bad?)
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Mon, 10 Jul 2000 21:09:59 +0100
Reply-To: [EMAIL PROTECTED]
On Mon, 10 Jul 2000 19:39:36 +0100, Andrew McDonald <[EMAIL PROTECTED]> wrote:
>On Mon, 10 Jul 2000 18:07:37 +0100,
>phil hunt <[EMAIL PROTECTED]> wrote:
>> I am thinking of developing a steganographic encryption system that
>> will enable a particular cyphertext to be decrypted into two or more
>> different plaintexts, depending on which key is used.
>[snip description]
>>
>> I have some questions:
>>
>>
>> (1) does anything like this exist already?
>
>The thought that comes to my mind first is basing it on Rivest's
>Chaffing and Winnowing:
><http://theory.lcs.mit.edu/~rivest/chaffing.txt>
>I'm fairly certain that people have done things with this (I think I
>might have seen something on Freshmeat <http://freshmeat.net/>).
>There have also been some developments from this suggested by others,
>e.g. John McHugh's 'Chaffing at the Bit' from last year's Information
>Hiding Workshop.
>
>> (I am aware of stegFS, which is a steganographic file system for Linux.
>
>Oh, I think I might have heard of that one. ;-)
I think you might :-)
Incidently, it was a main inspiration behind my system.
BTW, did you know that there's another Linux FS calling itself the "Steganographic
File System"? (Confusing name, or what). It was written by two South Africans, but
unfortunately its web page seems to be down.
>> My system is different in that it encypts files not file systems,
(Of course, there's no reason why the the files couldn't be tar or zip files,
with a wrapper around the main program that does automatic untaring/unzipping)
>> so
>> can be used under any OS, and also in StegFS, keys have "levels of secretness":
>> if you decrypt with one key, you automatically have access to all the data
>> encypted with "less secret" keys -- in stes, all keys are as secret as
>> each other).
>
>Later versions are more flexible in this area (e.g. have a look at
>stegfsctrl).
Do you have a URL for this?
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Mon, 10 Jul 2000 21:30:40 +0100
Reply-To: [EMAIL PROTECTED]
On 9 Jul 2000 15:17:57 -0700, David A. Wagner <[EMAIL PROTECTED]>
wrote:
>Iain McClatchie <[EMAIL PROTECTED]> wrote [excerpts only]:
>> Why bother supporting cryptography in the CPU?
>>
>> - Hardware implementations of the speed-critical cyphers are _tiny_.
>>
>> - Popularly-used cryptographic algorithms change very slowly.
>>
>> - Connection speeds are increasing. Software encryption can keep
>> up with a 56 Kb/s modem just fine, but a 10 Mb/s cable modem is
>> a problem,
>>
>> - Popular cryptographic algorithms now appear to be exportable.
>
>Those are good points. Still, there's a definite cost, and I wonder
>how compelling a need there is for hardware crypto.
>
>Until the AES is chosen, there's no obvious single candidate for hardware
>implementation. Each crypto protocol has a different favorite cipher
>(SSL -> RC4; IPSEC -> DES; SSH -> IDEA). That will likely change some
>years after after the AES is chosen, but even so, I'm not convinced
>there's a compelling need for hardware implementation. No matter which
>AES candidate is chosen,
When is this likely to happen?
My understanding is that AES is a process for coming up with a "standard"
encryption algorithm -- is this right? Who's in charge of it?
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: One plaintext, multiple keys
Date: Mon, 10 Jul 2000 15:37:20 -0700
S. T. L. <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> <<If my encryption algorithm is OTP, then it seems like this should be
> insecure, since it basically amounts to reusing P
> (the fixed plaintext) as a key.>>
>
> No, not the same. If you are using an "OTP" but have moronically used a
key
> twice, then you have P1 XOR K1 = C1 and P2 XOR K1 = C2. Then C1 XOR C2 =
P1
> XOR P2 and any two plaintexts XORed together leaks the contents rather
easily.
> But if you are using an OTP correctly, and send the same message twice
using
> two different keys, then you have P1 XOR K1 = C1 and P1 XOR K2 = C2. And
then
> C1 XOR C2 = K1 XOR K2, which is two random keys XORed together, which is
> equally random garbage. Plaintexts are not keys. Nothing can be leaked
by an
> OTP used properly. Other algorithms can leak if you repeatedly send the
same
> plaintext enciphered with different keys.
What do you mean "Other algorithms can leak if you repeatedly send the same
plaintext enciphered with different keys." ? All others or just some others?
Any in the class of DES, AES finalist? Can you give an example of one and
show the type of information leaked?
Thanks,
Paul
>
> -*---*-------
> S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
> Now **108** reviews of my 169 science books. Other pages up:
> Review of the _Foundation_ series, Jet Fighter Paper Airplane page,
> LASTLY Shrine, Files for Download!
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: sci.physics
Subject: Re: Use of EPR "paradox" in cryptography
Date: 10 Jul 2000 22:50:13 GMT
In <[EMAIL PROTECTED]> Roger Schlafly <[EMAIL PROTECTED]>
writes:
>Benjamin Goldberg wrote:
>> > And your attacker can just intercept on of the epr pairs,
>> > read it and send on to you the output.
>>
>> True about interception, but it's easy to detect if this has
>> occurred. If someone intercepts and re-sends data, then
>> there is a 25% chance of polarization being changed (per bit
>> intercepted).
>Which means that someone can grab a few bits and have a
>decent chance of not being caught. In some cryptographic
>application, losing just a few bits is catastrophic.
In the standard approach, A and B measure the polarisation randomly, and
then compare which direction they measured them in. They keep only those
for which they agreed. (roughly 50% in the standard case). They then
choose a subset of those and compare their results. If they all agree,
they are resonably certain that E did not eavesdrop on any substantial
percentage of those, and thus did not eavesdrop on any substantial
percentage of the ones they did not compare the outcomes of. She may
still have gotten a few of them. They can now do for example a oneway
hash of the bits they have, and compare those. If they agree, they they
are pretty certain that she also did not eavesdrop any substantial
percentage of the secret bits. (If E was lucky and did eavesdrop on a
some, the prob of not beeing detected goes something like .75^n where n
is the number of bits.) They can now do a running hash of the bits, (
eg, each 128 bits of key is run through say MD5 to give 128 bits of new
key which depends on all of the 128 bits-- since the probability is
negligible that E listened in on 128 bits and was not detected (.75^128
=10^-16), this gives a key which Eve does not know any bits of.
Ie, the security is probablistic.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.theory
Subject: Re: Quantum Computing (Was: Newbie question about factoring)
Date: 10 Jul 2000 22:55:24 GMT
In <[EMAIL PROTECTED]> Jerry Coffin <[EMAIL PROTECTED]>
writes:
>No -- the article in Nature specifically described the use of trans-
>crotonic acids and a nuclear magnetic resonance spectrometer to
>create a 7-qubit computer. They mentioned having managed to
>accomplish something with the system, and indeed it may have been
>getting it to execute the algorithm mentioned above (since Laflamme
>is mentioned in both cases) but seemed reasonably specific about
>having created a physical computer and manipulated qubits.
It was not the error correcting scheme which was implimented. They
showed that they could manipulate 7 qubits, get them into a coherent
state, and make measurements on the output. NMR computations are the
the only computers which have been created with more than one or two
qubits, but are also ones which will almost certainly not scale to any
really useful size ( the signal strength dies off exponentially with the
number of qubits.)
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: One plaintext, multiple keys
Date: 10 Jul 2000 22:59:44 GMT
Paul Pires <[EMAIL PROTECTED]> wrote:
> Any in the class of DES, AES finalist? Can you give an example of one and
> show the type of information leaked?
RSA if everyone is stupid.
By "stupid" I mean everyone picks e = 3 and uses no padding.
Here's how it works :
We have the message M and 3 different moduli n_1, n_2, and n_3 .
The adversary sees c_1 = M^3 mod n_1
c_2 = M^3 mod n_2
c_3 = M^3 mod n_3
We assume that n_1, n_2, and n_3 are all relatively prime. Note that if
they are not, then we can go home since we then factor at least one
modulus and can just decrypt directly.
The Chinese Remainder Theorem then tells us that we can find a solution S
which is congruent to M^3 mod (n_1 * n_2 * n_3) , where * is normal
integer multiplication. We can even do it in polynomial time.
The cute trick here is that we know
M is less than n_1
M is less than n_2
M is less than n_3
(it has to be, because we're encoding M
as an element of the group of units modulo n)
and so M^3 will be less than (n_1 * n_2 * n_3).
This means that when we find S = M^3 mod (n_1 * n_2 * n_3), we know
that it never "wrapped around" - that this is the real value of M^3 over
*the integers*. and then we just take the ordinary cube root to find the
message.
This still works if e > 3, but it's not as plausible - I might have 3
people on a cc: list, but I wouldn't have 65537, for instance. I think you
can become slightly more clever and get the number of required keys down,
too..
I think this attack is originally due to Johan Hastad.
There is a recent paper by Bellare, Boldyreva, and Micali on definitions
for the so-called "multi-user case" for crypto that covers these kinds of
things. I don't remember if it covers symmetric crypto or not (probably
not, but it would be a good start). You can find it on Bellare's web page
http://www-cse.ucsd.edu/users/mihir/papers/musu.html
-David
------------------------------
From: [EMAIL PROTECTED] (Simon Hogg)
Subject: SCRAMdisk or PGPdisk?
Date: Mon, 10 Jul 2000 23:05:38 GMT
Forgive me, but I can't find any information comparing these two (SCRAMdisk or
PGPdisk), so what's the consensus?
--
Simon
------------------------------
** 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
******************************
