Cryptography-Digest Digest #40, Volume #12 Thu, 15 Jun 00 23:13:00 EDT
Contents:
obfuscating the RSA private key (Dave Ahn)
Is there a program simlar to Norton Scecret Stuff with better encryption?
([EMAIL PROTECTED])
Re: Is there a program simlar to Norton Scecret Stuff with better encryption? (S. T.
L.)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(Tim Tyler)
Re: Digits of pi in Twofish (Tim Tyler)
Re: Cipher design a fading field? (Tim Tyler)
Re: On using compression as proper means of encryption (Tim Tyler)
Re: Evidence Eliminator Dis-Information Center ([EMAIL PROTECTED])
Re: Cipher design a fading field? (Tim Tyler)
Re: On using compression as proper means of encryption (SCOTT19U.ZIP_GUY)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(Tim Tyler)
Re: Cipher design a fading field? ("Trevor L. Jackson, III")
Re: small subgroups in Blum Blum Shub (Nicol So)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (zzapzing)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dave Ahn)
Subject: obfuscating the RSA private key
Date: 16 Jun 2000 00:03:51 GMT
I'm looking for some information on best ways to obfuscate an RSA private
key that must be publicized. I have an existing implementation originally
written by Sam Shen and Ray Jones but would like to know if there is a
better technique or if the existing technique can be improved.
The assumptions are that:
1) both the public and private keys must be published in some form.
2) the private key would be indirectly embedded in object format (linked)
into an executable. the "blackbox" source would not be published, but
the blackbox code generator "mkkey" would be. (see below)
3) the system is understood to be insecure since the private key can
ultimately be recovered, but it should be as difficult as possible.
Basically:
BOX_alg = mkkey(RSA_alg, private_key),
BOX_alg(data) == RSA_alg(private_key, data)
Recovering private_key from BOX_alg should be difficult.
>From the documentation of the technique:
* The obfuscation process used to generate the "black box" relies on
* the fact that an encryption with a known private key can be
* expressed as a sequence of operations (which I call X & Y, these
* correspond to the two different steps of the standard expmod
* algorithm) on two variables, the message being encrypted and the
* encryption result. So instead of storing the private key, we
* represent it by the sequence of X & Y's.
*
* To make the sequence harder to follow we generate arrays of
* messages and results and store the "real" message/result in one of
* the slots. X & Y's are semi-randomly performed on the elements of
* the array, and the elements are shuffled every once in a while. I
* think of this as playing a shell game with the message/result.
Full sourcecode to mkkey.c can be downloaded from:
http://www.netrek.org/mkkey.c
mkkey.c is a part of the Netrek RES-RSA package downloadable from:
http://sourceforge.net/project/filelist.php?group_id=968
Thanks in advance.
Dave
--
Dave Ahn <[EMAIL PROTECTED]> | "When you were born, you cried and the
| world rejoiced. Try to live your life
Virtual Endoscopy Center | so that when you die, you will rejoice
Wake Forest Univ. School of Medicine | and the world will cry." -1/2 jj^2
------------------------------
From: [EMAIL PROTECTED]
Subject: Is there a program simlar to Norton Scecret Stuff with better encryption?
Date: Fri, 16 Jun 2000 00:29:07 GMT
This program I always liked, it was pretty straightforward. Uses a
good algorythm(Blowfish), creates self-decrypting files so that those
that don't have the program need only a password. The only thing is, I
think it was only made in 40-bit encryption.
Does anyone if they ever released a stronger version of Norton Secrte
Stuff,
or
of another program that utilizes stronger encryption, and is about a
easy to use.
Thanx.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: Is there a program simlar to Norton Scecret Stuff with better encryption?
Date: 16 Jun 2000 00:49:11 GMT
You can use PGP.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
Pages up: 395 Quotes, 14 reviews of 165 science books, and a review of
the Foundation series. COMING UP: more science book reviews!
------------------------------
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 00:00:55 GMT
In sci.crypt.random-numbers Lon Willett <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:> An alternative strategy that makes runnung the generator backwards
:> difficult, but retains a bijective property that ensures no entropy
:> from the seed is destroyed involves the use of a public key encryption
:> algorithm. A public key is generated, and the private key is
:> *destroyed*. The internal state of the generator is regularly
:> encrypted with the public key. Since the private key is not available, the
:> generator can't be run backwards - without determining what the
:> private key is.
: Interesting idea. Another thought is just to base it on the DLP,
: without worrying about using asymmetric crypto per se. e.g. let P be a
: large prime, and G a primitive element mod P. Then, take the sequence:
: X[i+1] = G ^ X[i] mod P.
: This generates a nice sequence of values in the range 1 .. P-1, and is
: not (easily) reversible. [...]
I suspect your idea is more interesting than mine ;-)
Now I come to compare the ideas ISTM that the idea of using a one-way
trapdoor function is unnecessary. What's needed is a one-way function -
and the existence of a trapdoor is an undesirable weakness - as is the
necessity for destroying traces of its construction method.
These methods have the advantage of not necessarily losing entropy from
the seed - potentially allowing generaters which approximately cover the
full state space. However, performance may be a significant issue.
I feel suspiciously as though I'm unknowingly stepping on ground that
has already been gone over with a fine toothcomb. I'd love to learn
more about any existing work relating to building non-backtrackable
RNGs using anything like this.
The remaining issue which it seems desirable to address is the possibility
of short cycles.
One (relatively) obvious idea is to use a counter - a maximal-period LFSR,
(possibly with a larger internal state than is present in the main
function).
If one simply XORs this "counter" over the outputs it would produce
guaranteed large period. Unfortunately it transforms short-period
structures into a structures with a long period which may still be
alarmingly linear and weak :-|
The next most obvious step is to use such a counter to modify the
internal state before it is fed through the hashes (or whatever
structure is responsible for generating the strength).
<fx: waves hands> if the state space of the LFSR is greater than that of
the rest of the system there's no way the other component of the system
can somehow (by chance) produce an exact inverse function of the LFSR,
which would cancel it out. This is the only way such a combined structure
could exhibit periods shorter than that of the LFSR. [There are also
other ways to eliminate this possibility - besides using a larger state
for the LFSR than is present in the rest of the system]
Is this approach sort of approach at removing short periods practical?
Are there better approaches? Does the method work in the way I describe?
Has this approach been used before?
Any method of ensuring the absence of short periods seems that it
will eventually run into conflict with the principle that every
aspect of the internal state of a RNG should be transformed and
regenerated from scratch once in a while.
This principle suggests that you should /not/ maintain any sort of
permanent counter for extended periods - for fear that the opponent
will be able to learn about its state, keep track of it, and subtract
its effects from his analysis.
Without maintaining /some/ sort of counter, it doesn't seem possible
to eliminate the possibility of cycles of the order of the length for
which the counter is in continuous operation.
Lastly, does anybody care about short periods anyway?
Some folks seem quite happy with an *expected* period that's stupendously
high - and don't seem to care about the hopefully miniscule possibility of
hitting short cycles.
Are these folks using larger - and possibly slower - systems than they
need to in order to make the chance of hitting short cycles small enough?
Or are those trying to produce structures with demonstrably large
periods needlessly concerning themselves with marketing, the image of
their product, and feature tick-lists - without having a proper
pragmatic handle on the security issues involved?
Which way of doing things that will eventually be recommended to
undergraduates? ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ I'm pink :. I'm spam
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Digits of pi in Twofish
Reply-To: [EMAIL PROTECTED]
Date: Fri, 16 Jun 2000 00:27:26 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
:> A public demonstration involving a real random number generator,
:> designed by a representatives of the potential users is another idea
:> that might offer some assurance - though this lacks the eternal nature
:> of using the digits of PI ;-)
: How do you stand with regard to the MARS designers' idea of using a
: published seed value and a generator based on SHA1 to make S-boxes with
: particular published characteristics? [...]
I'm too ignorant to make much of a useful comment about this :-|
My immediate reaction is that anything that uses a published seed value
is hopeless in terms of providing transparency - unless the seed is 0
(a more fundamental constant than PI), and the RNG is some sort of
universal government standard or something.
The only way I can think that this might provide transparency is if the
sequence of bits used from the generator was very long - so long that
searching through possible initial seeds for weak ones is demonstrably a
hopless task. This may (for all I know) be the case here.
: The only problem I can see (assuming that they didn't break SHA1
: while building their trap door) is that they might have selected
: their published seed on the basis of more restrictive criteria,
: which include both their published criteria and some other
: carefully chosen to introduce appropriate weaknesses.
Yes - that's exactly the concern I'd raise. The RNG used may not be
a unique entity either - you'd have to look at its workings to check.
I doubt its sufficient to simply use "an RNG based on SHA-1".
There's an analogous possibility for Blowfish - that the rest of the
algorithm was designed to exhibit some particular weakness when used
with s-boxes based on the digits of PI.
If (for example) there were a number of other magic constants lying around
in Blowfish, this would be likely to significantly erode any transparency
provided by the s-boxes' use of PI.
These would offer a way of automatically creating many variants on
Blowfish - which could then be searched for one that was weak in
conjunction with the bits from PI.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 16 Jun 2000 01:04:20 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> However the original question was "if program size is bounded, does the
:> halting problem exist for that set of programs?"
: The original question was whether cryptanalysis was equivalent to
: solving the halting problem.
It depends on how far you go back. I was talking about the section that
began:
[different quoting levels in what follows]
> > : > This, however, assumes that the time a computer program that will
> > : > eventually halt will take to run is unbounded [...]
> > :
> > : Actually the programs involved don't have to be very large. [...]
> >
> > They *have* to be potentially unboundedly large for the halting
> > problem to exist.
>
> Nope.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: On using compression as proper means of encryption
Reply-To: [EMAIL PROTECTED]
Date: Fri, 16 Jun 2000 00:54:08 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Certainly, it would be foolish claim great strength (though I don't
: know yet a good way to analyze), not to say to jump to any claim
: of superiority over the well-established algorithms.
Another thought springs to mind: you can probably extract the
contents of the initial Huffman tree using a chosen plaintext attack:
Imagine sending a large number of different short strings for encryption
as separate messages under the same key [1].
ISTM, that this would tease out information pretty directly about the
initial Huffman tree.
Indeed, this may even be possible using a number of known plaintexts.
I don't think things are looking terribly healthy for the idea at the
moment.
It's quite a lot to hope for that a compression algorithm will make a
useful encryption algorithm with a few tweaks. Compression and encryption
may share some elements - but I'm not sure they have enough in common to
allow the construction of encryption algorithms from compression
algorithms with little additional effort.
[1] The protocols in use may protect against such attacks. However
cyphers should be able to withstand this treatment IMO.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Evidence Eliminator Dis-Information Center
Date: Thu, 15 Jun 2000 18:31:17 -0700
He he -
we may have circled our wagons in this "long hot summer" thread, but at
least we haven't lost our sense of humor.
Glad you came along :)
"EE Detractor" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 14 Jun 2000 19:33:00 -0700, [EMAIL PROTECTED] wrote:
>
> >
> >
> >EE Detractor - speaking for us all, protector of newbies, patron saint of
> >widows and small children
> >EE Detractor-ooney, making coffee....
>
> Nah, just so bored with Usenet that I've taken to playing with trolls.
> :-}
>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 16 Jun 2000 01:12:44 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> This is irrelevant - a program exists which specifies which program
:> halts, and which does not.
: No, there is no such program.
We disagree :-(
: If there were, we could apply it to the rather small program that
: tests successive combinations of integers (in increasing order) and
: halts when it finds one for which Goldbach's conjecture is false.
: That would settle Goldbach's conjecture one way or the other.
I'm not trying to suggest anything that would produce this result.
I'm not saying anybody can locate /which/ program solves the halting
problem for the specified finite set of programs.
All I'm saying is that it's certain that *some* such program does so.
The halting problem (if it was actually a problem for the set) would
state that no such finite program *existed*. It wouldn't say that no
such finite program could practically be found.
It talks about the existence of the halting-determination program - not
the existence of a construction which locates that program.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: On using compression as proper means of encryption
Date: 16 Jun 2000 02:07:42 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>: Certainly, it would be foolish claim great strength (though I don't
>: know yet a good way to analyze), not to say to jump to any claim
>: of superiority over the well-established algorithms.
>
>Another thought springs to mind: you can probably extract the
>contents of the initial Huffman tree using a chosen plaintext attack:
>
>Imagine sending a large number of different short strings for encryption
>as separate messages under the same key [1].
>
>ISTM, that this would tease out information pretty directly about the
>initial Huffman tree.
>
>Indeed, this may even be possible using a number of known plaintexts.
>
>I don't think things are looking terribly healthy for the idea at the
>moment.
>
>It's quite a lot to hope for that a compression algorithm will make a
>useful encryption algorithm with a few tweaks. Compression and encryption
>may share some elements - but I'm not sure they have enough in common to
>allow the construction of encryption algorithms from compression
>algorithms with little additional effort.
>
>[1] The protocols in use may protect against such attacks. However
>cyphers should be able to withstand this treatment IMO.
Tim one could think of normal compression as varible block length
encryption with very short blocks. If one is using pure static huffman
compression as the encryption method. Yes it would be rather easy to
reconstuct the table from a series of chosen plain text files.
however just as blocks size seem to have increased for most ciphers
one could so the same for a cipher based on 1-1 huffman compression.
You could limit the inital message size such that 20 or more characters
are used and you could greatly increase the complexity by using weighted
adaptive huffman compressions similar to those found at
http://members.xoom.com/ecil/compress.htm
The key is to create larger effective block sizes.
One way to do this to to use my adaptive huffman compress for the
first pass.
Then reverse the file and uncompress using my 1-1 huffman uncompresses
if you use the ones with condition file you can make this uncompressed
file have whatever characters you like and frequencies
then reverse the file and compress again
the condtion files if used can be such as to create any starting trees
you wish to use. This last compression makes it
very had to detect and the resulting file looks like noise
and it weaves the whole file into a block simalar to what one
wants in a all or nothing encryption scheme
------------------------------
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 01:27:34 GMT
In sci.crypt.random-numbers Lon Willett <[EMAIL PROTECTED]> wrote:
:> I removed the XOR of the output with H[i+1], because it allows state
:> following attacks (what you called iterative guessing attacks above)
:> if each H value is of low entropy, and all E values are of zero entropy.
:> If you're concerned with this type of attack, it's better to mix in
:> entropy only in fairly large chunks.
: Good point. But a very tricky situation, and I'm not sure that I got it
: wrong. In order to know how many "H" values one should collect before
: mixing them in, one has to have a reasonable estimate of the entropy
: that they contain. If the hardware RNG is working correctly, then my
: approach is fine. If it is defective or sabotaged, how can one estimate
: the entropy they contain? The safest assumption is that they contain
: zero entropy. And in that case, nothing is lost by mixing them in
: immediately.
This sounds dubious to me - though I'm not sure I'm following it all
correctly ;-)
I don't think you should not assume H contains zero entropy. If it
contains zero entropy, once the state is learned, it's known for all time
(determinism).
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.
The problem of estimating the entropy of the inputs is a significant one
- but the idea that the solution is to assume they have zero entropy -
and not bother with entropy accumulation methods - on the grounds that
you never know for certain when you have enough entropy - seems very
questionable.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ I'm pink :. I'm spam
------------------------------
Date: Thu, 15 Jun 2000 22:40:24 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
James Felling wrote:
> "Trevor L. Jackson, III" wrote:
>
> > "Douglas A. Gwyn" wrote:
> >
> > > "Trevor L. Jackson, III" wrote:
> > > > "Douglas A. Gwyn" wrote:
> > > > > Tim Tyler wrote:
> > > > > > If the size of the program is constrained, a halting determination program
> > > > > > could be written which enumerates all programs of that size or shorter and
> > > > > > lists whether they halt or not.
> > > > > It "lists" them how?
> > > > Turing programs can be written as input to a UTM. Such inputs are a sequence
>of
> > > > ones and zeros, so they are an integer. The list is ordered by the respective
> > > > integer values.
> > >
> > > You missed the point
> >
> > Could be, but I doubt it.
> >
> > > -- *how* does it determine whether they halt?
> >
> > It doesn't. It simply reports the facts that are encoded by the author.
>Essentially
> > it's a lookup function. The key question becomes whether the program can be
>written
> > small enough to fit within itself (this is a data compression issue). If so then
>the
> > Halting Problem can't be constructed because such a lookup program will halt after
> > reporting that it will do so.
> >
>
> Yes, but this still leaces small and indeterminate programs .( unless of course one
> assumes an omnicient author) A good example is the n/2 if n is even, 3n+1 if n is
>odd
> programs. EG it takes an input n0, and repeatedly applies this rule. It ends if at
>any
> point n=1. This is a short program to write/ implement, especially if you fix n0,
>but for
> many n, it is very indeterminate. ( How can this be evaluated using your algorithim?)
The issue isn't how difficult it is to write the program, but that with sufficient
ingenuity
it is possible to write the program. The halting problem states that such a program is
impossible to write, even for Karnak, if the set of programs is infinite.
As for your example, the hailstone sequence appears to be quite decidable. There is
no known
number that does not end in the 1-4-2-1 loop. AFAIK there is no proof of such, but
for any
given N it is not indeterminate at all. If you disagree please specify a number you
believe
is indeterminate.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Date: Thu, 15 Jun 2000 22:31:48 -0400
Reply-To: see.signature
Terry Ritter wrote:
>
> "To put things in perspective," I suggest you try to follow my
> reasoning before trying to refute it.
My comment was directed at that of lordcow77, not yours. Refuting your
reasoning was not my intent.
As I wrote in another message, I think BBS is mainly of theorectical
interests only. I stand by my assertion that asymptotically, it doesn't
matter much whether you choose special primes--the advantage that an
adversary can correctly predict the output of a BBS generator will not
change from "negligible" to "non-negligible".
> As you would have seen had you actually read and understood my
> comments, the statement in question was:
>
> >> >The nonsense about choosing "strong primes" or
> >> >good initialization values is a remnant to the past where it was
> >> >thought that a relatively small prime (if well chosen) would be
> >> >adaquately strong.
That's not the part I was commenting on when I said lordcow77's
interpretation was correct. I have no comment on the text quoted above.
> On the other hand, the larger question of X^2 mod N security (not part
> of my earlier comments) is swept under your asymptotic rug. But real
> systems are *not* asymptotic. All real BB&S systems *do* have short
> cycles. And short cycles *are* weak. Yes, it is unlikely to select a
> short cycle at random. But unless the BB&S prescriptions are
> followed, that is *only* "unlikely" and *not* "impossible." In
> contrast, the BB&S prescriptions *guarantee* that one does not use a
> short cycle, and that is a qualitative difference.
OK, choosing special primes eliminates one particular weakness that
occurs with negligible probability. Are you sure BBS has no other
weaknesses that occur with negligible probability?
> As I see it, the issue is *not* strength in practice, it is instead
> the claim to have a provably secure system. I think we can accept
> that all cryptography is vulnerable to opponents choosing the right
> key at random. But I claim that no system can be provably secure if
> it includes the possibility of selecting and using weakness, no matter
> how small that possibility may be.
You're certainly entitled to have your own criteria for security, but
the one you have (as suggested by your last sentence) is not what
theoretical computer scientists use.
[Philosophy is a highly personal thing and can be a source of endless
debates. The following is intended for people who care to know mine. For
practical security, irrational worries about threats that occur with
extremely low probability go against the rational risk management
approach to security advocated by pretty much all authors I've read who
do security engineering/administration for a living. No organization has
the resources to defend against all *conceivable* threats. At some
point, irrational worries about extremely unlikely threats must be
controlled and paranoia must be kept in check. Obsession with
unrealistic threats can cause resources to be directed away from where
they can be profitably expended to defend against more serious threats.]
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
From: zzapzing <[EMAIL PROTECTED]>
Crossposted-To: uk.media.newspapers,uk.legal,alt.security.pgp
Date: Thu, 15 Jun 2000 19:37:51 -0700
David Swarbrick <[EMAIL PROTECTED]> wrote:
>In article <8hm984$g15$[EMAIL PROTECTED]>, zapzing
<[EMAIL PROTECTED]>
>writes
>>
>>It occurs to me that there are other protocols
>>for authentication that do not rely on anything
>>like a key. One of them has to do, I think, with
>>graph isomorphism. I remember reading about it
>>somewhere.
>
>A key is defined very widely - as whatever will allow the
message to be
>converted back into plaintext.
You can't encrypt a message with an unknown graph isomorphism.
Thus it cannot legally be called a key. your attack where
they send a message encrypted with the "key" and then
demand that you decrypt it would be impossible.
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.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
******************************
