Cryptography-Digest Digest #989, Volume #13 Sat, 24 Mar 01 14:13:01 EST
Contents:
Re: Hello (Frank Gerlach)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
(SCOTT19U.ZIP_GUY)
Re: decryprtion help please? (SCOTT19U.ZIP_GUY)
Re: Idea - (LONG) (amateur)
Re: Open Source Implementations of PGP (SCOTT19U.ZIP_GUY)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be (Frank
Gerlach)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be (Frank
Gerlach)
Re: Idea - (LONG) (SCOTT19U.ZIP_GUY)
Re: decryprtion help please? (Jim Gillogly)
Re: Crack it! (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Hello
Date: Sat, 24 Mar 2001 20:11:38 +0100
Tom St Denis wrote:
> Um anyone home?
>
> I posted a question 6hrs ago and no reply.
>
> BTW the NSA broke PGP and B.S works for the commies (that should get a
> reply, then while you are flaming me reply to my other question please...)
>
> --
> Tom St Denis
> ---
> http://tomstdenis.home.dhs.org
No, the NSA is sabotaging the usenet :-)
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
Date: 24 Mar 2001 18:21:30 GMT
[EMAIL PROTECTED] (Bill Unruh) wrote in
<99imvl$ab$[EMAIL PROTECTED]>:
>In <99av4l$q67$[EMAIL PROTECTED]> Pawel Krawczyk
><[EMAIL PROTECTED]> writes:
>
>>In sci.crypt Bob C. <[EMAIL PROTECTED]> wrote:
>
>>> The exploit works by attacking the Digital Signature Algorithm's
>>> so-called discrete logarithm problem. DSA keys are typically stored
>>> in a file called secring.skr, and Klima and Rosa found that they
>>> could successfuly insert a replacement key in it.
>
>>Every day new details leak painfully slow from the ICZ and it's
>>still getting closer to another instance of what Bruce Schneier called
>>`publicity attack'. First comments from ICZ suggested that the PGP has
>>been broken, then that the secret key can be retrieved without knowing
>>the passphrase, now we learn that you can substitute private key with
>>your own, if you have access to the keyring. What an invention! ;-\
>
>If this is right then the OpenPGP standard is broken. To break a
>cryptosystem does not necessarily imply breaking just the algorithm. A
>crypto system is the whole system, including the key storage. displaying
>a weakness anywhere is a break of the cryptosystem. This is an inherent
I don't think you really belive what your saying "a weakness
anywhere is a break of the cryptosystem" if you belived that the
combination of non 1-1 compression with the encryption algorithm
is also a break. But few seem to care and they claim its minor.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: decryprtion help please?
Date: 24 Mar 2001 18:13:34 GMT
[EMAIL PROTECTED] (rh) wrote in <EI3v6.172$[EMAIL PROTECTED]>:
>A buddy had asked me yesterday, if it would be possible to
>migrate all of our pins from the current main system to the new test pin
>vault. We have no decryption utility that could do this. Below I have
>included some clear text
>pins and then the encrypted version that is located in the SQL
>database.I do know that the clear
>text pins "are encrypted with themselves."
>
>Pin Encrypted Pin in SQL DB
>
>
>1234 9EE7964577447ADA
>9999 1F1D2C2ED301B2A6
>test 8A49D1CCB9AA5DBB
>hello 7F85C0A9F3F86EC0
>4567 60956233056154AC
>123456 5155482C2078BF2C
>voyager 73C63521A96FF1C9
>ATLAS BFC44BCCC9ED5EE5
>
>--
>Robert Hawks
>http://www.elitedaytraders.com
>
>
>
Since each thing is "encrypted to same size" 64 bits it could be DES
encryption. What is the size limit on password. Also its possible
it could be a HASH of some type. Since you have the utillity that
does the encryption it should not be that hard to trace through it and
see what its using.
Anotherpoint if the DATA base is anygood you can migrate the
encrypted pins over. Since the code should always should encrypt
any pins and then compare the test encrypted pin with the data
base stored value assuming your using same encryption method for
new system.
Another common why would to be give users of old pins a time period
where they old system would be in use to optionally check using old
method. If key passes then store it encrypted using the new system.
The point is you don't mecessiarly have to decrypt old pins to move
them to new data base. Since the decrypted pin values should never
exist in a file on the system anyway.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Sat, 24 Mar 2001 13:23:33 -0400
Skip the first step of Cesar and you will understand that my idea is
nothing more than a version of OTP with great advantage : using a short
key.
Even if I used a short key of 12 digits, it's hard to solve.
With a key of 100 hundreds digits it's unbreakable.
Try just to code two bits with odd and even
First communication
01 = 23 it could 47 or 89 or even odd ......
Mask them with a key 63
Let M= a - k => a = M + k = 23 + 63 = 86
I send a = 86
Second communication
11 = 37
same key 63
I send b
b = 100
You have a difference -14.
-14 = 100 - 86 =
How could you retrieve m1 and m2?
You want to use a known plain-text attack?????
Every plain-text gives you a billions of encrypted texts??????
Just try to understand that it is a version of of OTP with short key and
the possibility of reusing the key.
"John A. Malley" wrote:
>
> amateur wrote:
> >
> > Don't forget that with my idea the same clear could produce multiple
> > cyphertext.
> > Schneier is defining restricted algorithm when algo is kept secret.
> > That's not my case.
> > All my algo is public. The secret who is to find and distinguish two
> > categories of symbols is not secret at all.
> > But the sender has the freedom to imagine any kind of two categories
> > before encrypting.
> > This secret is disclose if the recipient has the key.
> > All modern cryptography is based on power of computing.
> > What I'm proposing is to found a new cryptography based on the inability
> > of computer to analyse a text trying to distinguish two categories.
>
> Humans write programs. Algorithms employed by humans to decide
> something can be transcribed to a computer program (encoded as binary
> numbers.) A human recognizes the symbols in the ciphertext correspond
> to one or another category. The ability of a human to spot patterns can
> be encoded as an algorithm acting on the data. So a computer program
> can be written to do the same thing.
>
> Computers sort through data faster than humans. That's the advantage of
> a computer.
>
> > Computer has no this attribute.
>
> Computers are glorified adding machines. We tell them to add, subtract,
> multiply and divide numbers. We encode information as numbers and
> manipulate information as numbers. No program "means" anything to a
> computer. Computers do literally what we tell them to do with a program.
>
> For a time the word "computer" meant a person who carried out
> particular numerical calculations. "Computers" did not necessarily know
> what they were working on or what the calculation results meant.
>
> > So the cryptanalist even if he use the
> > computer is helpless. The only strategy for him is to try to guess what
> > a sender has choosen to encrypt every bit.
> > And this domain is infinite.
>
> So you encode binary-represented ciphertext with members of two set of
> symbols, each set with the same number of elements. The two sets differ
> in one property - one set has the property, the other set does not. The
> absence and presence of the property corresponds to binary 0 or 1.
>
> This "encoded" ciphertext is human-readable - it must be, or how can a
> human decode it? So a computer program can be written to recognize it
> same as a human did.
>
> This "encoded" ciphertext is program-readable if a program is written to
> generate the "encoded" ciphertext to send it electronically or to print
> it onto paper. And that which is generated by a program is recognized by
> a program.
>
> I read the "idea" post and the proposed cipher. A human cryptanalyst
> *can* figure out which symbols correspond to 0 and 1 no matter what
> symbols are used, due to the statistics of the plaintext as exposed in
> the ciphertext.
>
> How! you ask...
>
> Well, (1) the first thing the cipher does it apply a Caesar substitution
> to a fixed length of plaintext message.
>
> OK. This preserves the frequencies of occurrence of every letter,
> digraph
> and trigraph in the plaintext message. And the structure of every
> sentence. And the order of every plaintext word.
>
> Next, (2) convert each character in the substitution output into its hex
> equivalent, and then to binary (0 and 1.)
>
> OK. This preserves the frequencies of occurrence of every letter,
> digraph and trigraph in the plaintext message. And the structure of
> every sentence. And the order of every plaintext word.
>
> All (2) does it substitute a binary string for each character in the
> output of (1). That's why all the salient statistical information in the
> plaintext comes sailing on through.
>
> Now here's a interesting fact:
>
> The number of 1s and 0s in the resulting binary string produced in the
> output of step (2) are NOT equal. There are either more 1s than 0s or
> there are more 0s than 1s.
>
> Why?
>
> Well, some characters in the plaintext occurred far more often than
> others. And after the substitution cipher in step (1), their ciphertext
> character equivalents occur far more often than the ciphertext
> equivalents of the others. And after (2), the binary string
> representations of the ciphertext character equivalents occur far more
> often than the binary string equivalents of the ciphertext equivalents
> of
> the others.
>
> So what comes next?
>
> In step (3) of your idea, form two sets of symbols, each set with equal
> numbers of elements. Take the binary string representation output of
> step (2) and substitute an element out of one set selected uniformly at
> random for a 0 and a substitute an element out of the other set selected
> uniformly at random for a 1.
>
> OK. But remember, the number of 1s and 0s in the binary string
> representation are NOT equal! So symbols from one set appear more often
> than symbols from the other set. And the symbols selected from a set
> are selected uniformly a random. For a quantity of ciphertext encrypted
> this way, every symbol from the set corresponding to 1 should appear
> the same number of times and every symbol from the set corresponding to
> 0 should appear the same number of times.
>
> This information allows a cryptanalyst to determine which symbols
> correspond to which of the two sets representing 0 and 1.
> It can be determined by frequency count of each symbol in the encoded
> ciphertext. Half of the symbols in the "encoded" ciphertext will occur
> with the same frequency, f_a, and half of the symbols in the "encoded"
> ciphertext will occur with the same frequency f_b, and f_a will NOT
> equal f_b. Which set corresponds to 1 and 0? It's one or the other -
> but a clever cryptanalyst knows already what the binary coding of
> characters is, so therefore already knows if 1s or 0s occur with more
> frequency in the binary representation of the plaintext alphabet.
>
> So in step (3) the 0s are represented with {0,1,2,3,4} and 1s are
> represented with {5,6,7,8,9}.
>
> Again, the number of 0s, 1s, 2s, 3s, 4s will tend to be equal and the
> number of 5s, 6s, 7s, 8s, and 9s will tend to be equal but the number of
> 0s will not equal the number of 5s, #1s will not equal #5s, etc.
>
> In Step (4) a further Caesar substitution (? there's no modulo operation
> though, it's just addition) is done by adding a constant key value to
> the numerical result
> of Step (3).
>
> Does this hide the fact that the number of 0s and 1s in the binary
> representation output of step (2) are not equal?
>
> No.
>
> In fact, take any two message blocks encrypted with this cipher (using
> your notation, E1' + K and E2' + K, and just subtract one from the
> other to get E1' - E2'.
>
> No key involved here now. It's possible for the cryptanalyst to examine
> the statistics of the plaintext directly. What are the statistics of the
> differences between plaintext binary representations - they show up
> directly in the ciphertext.
>
> The addition of a fixed constant (key) in step (4) will not change the
> statistics of the underlying plaintext as revealed by the substituted
> ciphertext in step (2).
>
> Once a cryptanalyst determines which symbols represent 0s and 1s in a
> manner like the described, he replaces the symbols with 0s and 1s and
> gets the binary string equivalent to the Caesar substitution on the
> original plaintext (output of step 3.) Then all the known tools for
> cracking simple substitution ciphers apply to rapidly crack this cipher.
>
> The attack is even quicker and easier with known plaintext! Try it
> yourself and see. :-)
>
> In summary, here's the core of the attack:
>
> Homophonic substitution of the 0s and 1s of the binary string
> equivalents of the ciphertext output of a simple substitution cipher
> keeps the statistics of the plaintext (and its binary string equivalent
> ) intact. Any bias in the number of occurrences of 0s and 1s shows up
> in the frequencies of the symbols used to encode 0s and 1s.
>
> Hope this helps,
>
> John A. Malley
> [EMAIL PROTECTED]
>
>
>
>
> > You have multiple combinations using only the characters of ASCII table.
> > If using others codes, you have to understand thas it's quite impossible
> > to attack.
> >
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Open Source Implementations of PGP
Date: 24 Mar 2001 18:32:25 GMT
[EMAIL PROTECTED] (Bill Unruh) wrote in
<99inib$lf$[EMAIL PROTECTED]>:
>
>A prime example of someone unclear on the concept. Crypto is different
>from other programs. Usually the user can look at the output and tell if
>the program has done what it claims to do. In crypto this is most
>definitely not the case. There is now way from the output (unless the
Actually the reason much of it is this way is so that "BACK DOORS"
can be added. Sure the heart of an algorithm like RIJNDEAL or RSA
will be beyond the average user to dectect a flaw. There is no
reason that the various components can be put together in a way
that makes it easyer to test the various components in a way one
does not need to get the source to totally check it. I think
it should have options. Maybe call them debug options. Where
if one wants it will spit out the individual fields used in
the format. As well as files representing the file at various
states such as before and after compression. This would allow
for more types if dynamic checking. At least this is what
should be done in OPEN PGP type of products.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy.anon-server,alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.resources,comp.security.pgp.tech
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be
Date: Sat, 24 Mar 2001 20:41:41 +0100
Tomas Rosa wrote:
> Despite of some claims from the wired article, we note that the attack is
> realistic.
Despite your marketing stunt I am goig to respond.
> We think that everybody would agree that any kind of information which is
> referred to as *encrypted information* shall be able to be stored anywhere
> without the risk of its disclosure.
Disclosure or MODIFICATION ??
>
>
> There shall be no reason to store your private key, which is properly
> encrypted, in the deposit. We have shown that in the case of the OpenPGP
> format the encrypted private key MUST NOT be stored in the place, where the
> attacker can access and modify it. From here we conclude that private keys
> are NOT PROPERLY ENCRYPTED in the OpenPGP format and derived applications.
They are not secured against TAMPERING.
>
>
> So, from the cryptologic point of view, the attack is pretty serious.
Also from a marketing point of view it makes sense to call your discovery
serious.
>
> Moreover it is also realistic. In the networked systems users usually would
> like to store their containers with private keys in some shared place to be
> able to have their keys ready to use on any workstation in the network.
Yeah, anytime. Too difficult to store some kilobytes on a floppy. Too heavy, to
bulky, those 3.5 inch floppies.
> Note
> that this is the default option in the PGP. In such scenario it is clear
> that the user has very little or no control on the encrypted private key.
> Anybody who can modify this information when it is going through the network
> can carry out the attack. Of course your network administrator is the first
> person who can be the attacker.
Your network adimistrator will most probably replace PGP itself with a
trojan-horsed version, if he wants your key.
> We think that users shall not have to care
> about such thinks (when their private keys are properly encrypted, of
> course). Btw: wasn't it the main idea behind the whole PGP to give its users
> "Pretty Good Privacy" in such environments?
>
> So, from the practical point of view, the attack is pretty realistic.
Maybe *you* are storing your secret key on a shared drive. Security-concious
people store it on a floppy disk, which the physically control.
>
>
> More information will be available in the crypto-paper, which will be
> released soon at www.i.cz.
Next time, please clearly state the THREAT MODEL. Telling people that write
access to the secret key is necessary would have been easily possible. Also, if
you call your self "cryptologist", be a little more scientific and less
marketing-driven. Helps your reputation.
Thanks a lot !
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be
Date: Sat, 24 Mar 2001 20:25:22 +0100
Pawel Krawczyk wrote:
>
> Every day new details leak painfully slow from the ICZ and it's
> still getting closer to another instance of what Bruce Schneier called
> `publicity attack'. First comments from ICZ suggested that the PGP has
> been broken, then that the secret key can be retrieved without knowing
> the passphrase, now we learn that you can substitute private key with
> your own, if you have access to the keyring. What an invention! ;-\
It was mainly a marketing stunt of ICZ. The fact that their early
publications where convoluted and lengthy also doesn't give them more
credit.
Their objective clearly was to impress their czech customers with
attributes such as "worldwide impact" etc. Something like "look, we czechs
didn't invent the nuclear bomb, but we can break yankee crypto".
I suggest to clearly state the threat model next time. They could have
easily told "the world audience", that access to the secret key ring is
required for their attack.
>
> --
> Paweł Krawczyk *** home: <http://ceti.pl/~kravietz/>
> security: <http://ipsec.pl/> *** fidonet: 2:486/23
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Idea - (LONG)
Date: 24 Mar 2001 18:43:11 GMT
[EMAIL PROTECTED] (amateur) wrote in <[EMAIL PROTECTED]>:
>Skip the first step of Cesar and you will understand that my idea is
>nothing more than a version of OTP with great advantage : using a short
>key.
>Even if I used a short key of 12 digits, it's hard to solve.
>With a key of 100 hundreds digits it's unbreakable.
Interesting at 12 its brakable but hard. At 100 its
unbreakable. What about 99 do you know at what number
it first bcomes unbreakable
>
>You want to use a known plain-text attack?????
>Every plain-text gives you a billions of encrypted texts??????
>Just try to understand that it is a version of of OTP with short key and
>the possibility of reusing the key.
>
>
How does this compre with the Grandview Algorithm
it allows for billions of combinations for each encrypted
text. What makes you think you can encrypt better than it.
I see no advantage of yours over the other method and it
seems like the other guy was first and he can explain his
you don't seem to have a solid grasp of what yours is doing at
this point.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: decryprtion help please?
Date: Sat, 24 Mar 2001 10:56:19 -0800
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (rh) wrote in <EI3v6.172$[EMAIL PROTECTED]>:
> >1234 9EE7964577447ADA
> >9999 1F1D2C2ED301B2A6
> >test 8A49D1CCB9AA5DBB
> >hello 7F85C0A9F3F86EC0
> >4567 60956233056154AC
> >123456 5155482C2078BF2C
> >voyager 73C63521A96FF1C9
> >ATLAS BFC44BCCC9ED5EE5
> The point is you don't mecessiarly have to decrypt old pins to move
> them to new data base. Since the decrypted pin values should never
> exist in a file on the system anyway.
Good point -- if the encrypted pin database could be reversed, it
should be trashed anyway. Time to write a pin hashing routine
for which you have the source (e.g. using SHA-1), and have everybody
pick a new one. That way you can be sure it's a secure process.
--
Jim Gillogly
2 Astron S.R. 2001, 18:52
12.19.8.1.8, 2 Lamat 11 Cumku, First Lord of Night
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crack it!
Date: Sat, 24 Mar 2001 19:58:55 +0100
amateur wrote:
>
> I read it.
> I use size block constants.
> You are talking about variable size-block.
> That was the purpose of your paper.
> My system is another form of OTP. With a great advantage. Using and
> reusing the same key.
Where did I talk about 'variable size-block' ?? Could
you site the corresponding text of my article? I was not
specifically considering any 'block' encryption in my old
article at all !! In fact, I think that my stuff could be
more useful for 'stream' encryptions. Even if in any of my
arguments there are places where 'variability' is allowed,
isn't keeping a variable constant a special case of the
general situation where a variable is free at the disposal
of the user ?? If an argument is good for the variable case,
then it is ALSO good for the constant case, isn't it?
The opposite obviously wouldn't go. One evidently cannot
use arguments that are based on constants to simply
'extrapolate' (without further work) to situations where
these constants are no longer constants. So please kindly
make your point above clear.
If you want to talk about OTP, please first read the
literature to ascertain what an OTP is, before you claim
any connection of your scheme with that. Note that anything
that reuses the key is 'by definition' NOT an OTP. I am
sorry to say that, from the number of posts that your have
sent till now to the group, one cannot help but have the
impression that you don't constantly employ a vocabulary of
crypto terms that is commonly used in the group by other
people. This does not imply that you could not 'define'
something special for the purpose of your arguments. But
in such cases you have to first make that definition clear
and, if possible, avoid confusions with already existing
definitions (via first consulting literatures to see
how certain terms have already commonly accepted
definitions). In other words, please keep to the generally
accepted conventions of scientific discussions also in
this respect. Otherwise others couldn't discuss with you
sensibly.
BTW, if by your words 'variable size-block' you were
refering to my 'variable length codes' (the title of my
old article), then you are entirely wrong in the current
context. We were arguing here about whether your scheme is
covered by what I mentioned in my article or not, and I
have established in the previous post that, with what I
mentioned, one can, for example, obtain a mapping like
the following which is of the type that you (repeatedly)
claimed to be your new 'idea':
'0' ---> {a, b, c}
'1' ---> {d, e, f, g, h}
There is up till now NOTHING in my argumentation saying
how the second alphabet {a, b, c, d, e, f, g, h} is to be
represented !! It could be represented by ASCII (a constant
length code, i.e. a block code which is a special case of
Huffman code), or it could be represented by a general
variable length code (fairly commonly a Huffman code, but
there are lots of other useful codes), or one could choose
NOT to use bit representations at all, e.g. when one writes
the symbols a, b, ... as such with ink on a piece of paper !!
(A ciphertext that is hand-written is also a ciphertext,
isn't it?)
M. K. Shen
====================================
P.S. I suppose that the above also amply answers another
post of yours that was sent 14 minutes later after the
current one. Note in particular that the example I give
above is only one example. You could of course use, instead
of the alphabet {a, b, c, .....}, the alphabet of your
choice {+, #, $, .....} or any other set of symbols you
ever like. Does that change ANYTHING that I have been
arguing with you ??
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
