Cryptography-Digest Digest #848, Volume #11 Wed, 24 May 00 04:13:01 EDT
Contents:
Another possible 3DES mode. (zapzing)
Re: Retail distributors of DES chips? (zapzing)
Re: Crypto patentability ("Paul Pires")
Re: Asynchronous and simple algorithm (Francois Grieu)
Re: Retail distributors of DES chips? (Paul Rubin)
Re: Crypto patentability (Anders Thulin)
Re: Crypto patentability ("Paul Pires")
Re: pentium timings (Jerry Coffin)
Re: Yet another block cipher: Storin (Mark Wooding)
Chosen Plaintext Attack (Raphael Phan Chung Wei)
Re: Matrix reduction ([EMAIL PROTECTED])
OAP-L3 for T Huuskonen (Anthony Stephen Szopa)
Re: Crypto patentability (Runu Knips)
Re: Encryption within newsgroup postings ("Dave Jones")
----------------------------------------------------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Another possible 3DES mode.
Date: Wed, 24 May 2000 05:08:00 GMT
This is an expansion of an idea
that was in the sci.crypt FAQ.
In the faq, the following idea was
suggested as a way of accomplishing
3DES on an enlarged block:
F(x)=Tran(E(k1,Tran(E(k2,Tran(E(k3,Tran(x)))))))
where Tran is a large block transposition
(bitwise, I assume, but I suppose it
would work OK if it were a bytewise
transposition), and E(k,x) actually indicates
several parallel encryptions being done
on the large block, which is split up
into DES-sized subblocks for this purpose.
In this implementation three keys are used.
But I was thinking, what if a key expansion
algorithm was used and each individual DES
encryption had its own unique key. For example
if the enlarged block consisted of 32 bytes,
then there would be 12 DES encryptions to
encrypt the large block. What if each of those
12 encryptions had its own key?
Of course noone would want to memorize
56x12=672 bits, so we would use a key expansion
algorithm to get 672 bits from, say, 160 bits
(or so).
Of course the security would depend on the key
expansion algorithm. Perhaps BBS could be used
for that, since speed would not be an issue for
the key expansion algorithm.
Perhaps the large block transposition could
also be made key dependent by getting
more bits out of the key expansion algorithm.
But this would mean that the transposition
could not be done quite so elegantly in
hardware.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Retail distributors of DES chips?
Date: Wed, 24 May 2000 05:22:55 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8gf5j2$8ui$[EMAIL PROTECTED]>, zapzing <zapzing@my-
> deja.com> wrote:
> >In article <8gd7jl$t7e$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Paul Rubin) wrote:
> >> In article <8gd3bq$qk5$[EMAIL PROTECTED]>, zapzing
> ><[EMAIL PROTECTED]> wrote:
> >> >Where can I buy DES chips? I've searched alot and I can't
> find any
> >> >retail distributors. The only thing I found was one
> Canadian company
> >> >that was mentioned in the FAQ, but their chips sound much
> too "high
> >> >end" for me. Thanks in advance.
> >>
> >> If your application isn't high end, use software, not a chip.
> >>
> >
> >Well, One of the things I have been considering
> >is the possibility of malicious software.
> >That's why I was considering using a chip.
> >That way there is absolutely no possibility
> >that anythink will be placed in any
> >subliminal channels.
> >
> >I figure there must be some old chips
> >lying around. If I can't find a reasonably
> >priced tamperproof chip, I may just rig up my
> >own tamperproof container.
> >
> >I'm still reading up on GPS.
>
> About a year ago someone posted about doing ciphers in hardware
> and publishing the VDHL. Maybe that guy can repost?
>
I sure hope so.
> At anyrate any joe-blow DES chip that conforms to the DES
> standard when testing with random keys/plaintext is most likely
> a real chip, and not some cloak.
That's what I am hoping for. There is also the
possibility of feeding the chip "fake" plaintext
and keys so it wouldn't know what information to
leak out even if it did have the opportunity to
leak some information.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Crypto patentability
Date: Tue, 23 May 2000 22:38:32 -0700
Bill Unruh <[EMAIL PROTECTED]> wrote in message
news:8gfl5t$hgr$[EMAIL PROTECTED]...
> In <9wFW4.42057$[EMAIL PROTECTED]> "Paul Pires"
<[EMAIL PROTECTED]> writes:
I can see we have different opinions. Good.
> Yes, but the problem is that the granting of a patent carries with it
> the presumption of validity. Ie, unless you can prove prior art, or
> anything else that invalidates the patent, the patent stands.
True, the inventor has cleared the bar. He has earned that presumption.
>Thus, if
> the patent examiners do a bad job, then they seriously harm the field,
> by chilling out competition.
True again, the inventor should not be penalized by the incompetence of the
examiner either.
> The problem is that to prove invalidity requires a court case, a very
> long, very expensive court case if the patent holder has deep pockets.
No, not really. you don't sue some one if you think their patent is bad, you
infringe and win the suit for infringement the inventor brings. Of course,
if you knowingly infringe and loose it's trebil damages.
> Most people or companies are not up to that even if the patent is
> patently invalid. It is thus crucial that the patent office do a good
> job in assigning patents.
This is our disagreement. I've been there and I think they do a pretty good
job now. I think the job is a whole lot tougher than you think.
> > You folks have been doing the single most important thing all along.
> >This is a public forum where issues described here become the very prior
art
> >that will keep a bad patent from being enforced. It won't keep it from
being
> >issued. I said the process was beautiful, not omnipotent.
>
> The whole purpose of patents was to encourage the publication of the
> patented material, rather than have people try to keep it secret with
> trade secrecy laws. In the case of software, it is hard to keep stuff
> secret anyway-- it is too easy to disassemble the stuff if you really
> want to know. This removes a big reason why patents exist at all.
> They were never intended as a "reward" for invention.
I Stongly disagree and I believe history supports it. You don't get a patent
for disclosing a good Idea, it must be invention. Invention (Or more likely
the personal investment in the developement of it) is clearly being rewarded
with a monopoly for a period of time. after that the invention can never be
patented again by any one.
>It was purely a
> very mercinary bargain-- you tell us what you have done, and we give you
> a monopoly for X years. Whether patents on software serve that purpose--
> ie whetehr the public gets a good deal out of such patents-- is highly
> debatable. Thus so is allowing patents of software.
>
> Copyright is similar. Copyright is another bargain-- you write or
> produce something, we will give you a monopoly on copying that something
> for X years ( where x is like 75 years or life+50) Again this makes
> almost no sense with software. Software copyright should last a max of 5
> yers, and then only if the source code is published. Otherwise that
> monopoly should be granted. Many companies have become enamoured of the
> soviet system, where the government granted monopoly rights to friends.
> While good for the friends, it was not good for the society. Similarly
> here.
Companies don't like to pay to use patents from individuals. Because of
patents the little guy has won quite often. I did. Look up the story of
George Eastman vrs a parish priest named Goodwin I think. He is the patent
holder on the process of using celluloid as a film base. George (The third
richest man in the country at the time) fought and fumed and stalled and
tricked and ultimately paid him 5 million dollars (This was in the 1890's).
a tidy sum. The evil tool patent in the hands of the rapacious industrialist
is an urban myth.
Paul
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Asynchronous and simple algorithm
Date: Wed, 24 May 2000 07:43:51 +0200
"Martin Winter" <[EMAIL PROTECTED]> wrote:
> I just want to encrypt a string of about 200 characters so that only a
> different program on the server can decrypt it.
If this is your problem, it can be solved almost perfectly using
public key crypto, and although not trivial, it can be done with
the primitives you have. For example, you could have an RSA public
key in your program, and somewhat use it to encipher your string;
only the server, with the corresponding RSA secret key, will be able
to decipher it, and this works even if someone can reverse-engineer
your Linguo program.
But is that your problem ? I think it is more to avoid that somemone
cheats on her score, right ? This can NOT be done if you are assuming
your adversary can fiddle with the program running on her computer.
Could you restate the problem, and in particular clear the following
points:
A) do you need a method for the server to determines if a message it
receives has originated from a legitimate program ?
B) do you need the messages sent to the server to remain confidential,
which is a different issue ?
C) are you willing to assume the code you'll be writting will not be
sucessfully reverse-egineered by the persons willing to attack it ?
These are not mutualy exclusive, except if A is true, then C must be.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Retail distributors of DES chips?
Date: 24 May 2000 05:48:27 GMT
In article <8gfov7$lt4$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]> wrote:
>> At anyrate any joe-blow DES chip that conforms to the DES
>> standard when testing with random keys/plaintext is most likely
>> a real chip, and not some cloak.
>
>That's what I am hoping for. There is also the possibility of feeding
>the chip "fake" plaintext and keys so it wouldn't know what
>information to leak out even if it did have the opportunity to leak
>some information.
>
>If you know about a retail source of inexpensive DES chips, please
>let me know, thanks.
I'm still extremely confused about what you want a DES chip for,
if it's not for a high-performance hardware encryption application.
If you can describe more concretely what you want to use the chip for,
I might be able to make useful suggestions.
For example, if you want a tamper resistant hardware DES implementation
with encapsulated keys try the Java buttons I mentioned in another
article. They're fairly slow, but very secure.
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Crypto patentability
Date: Wed, 24 May 2000 06:46:22 GMT
Mok-Kong Shen wrote:
> If you don't agree with someone on a topic, then you can discuss
> with him, can't you? It's o.k. if you prefer not to say anything.
> We are in a 'discussion' group, aren't we?
I suspect the point made is that there are more discussion groups
than this one, and some of those may be more appropriate for
the discussion of what is primarily a patents issue, and only secondarily
a crypto issue.
If, as you say,
> discussed such that (hopefully) ''the patent system, both in the
> US and elsewhere,'' would be ''either massively overhauled or
> scrapped entirely''.
it seems reasonable to ensure that people knowledgeable about
the patent system would participate as well, as this does not only
refer to patents on crypto inventions, ut the entire patent system.
> The
> Hitachi claims are menacing AES. Anyone designing encryption
> algorithms is potentially facing the same risk. So the present
> situation of patents need be clarified and understood and we
> should attempt, if possible, to get the patent system reformed
> for our interest
Provided, of course, that the claims are likely to be valid.
That seems to be the first point to settle. And as that kind of
discussion is definitely a patent problem rather than a crypto problem,
using sci.crypt seems to be less efficient than, say, comp.patents.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Hj�lmaregatan 3B, 212 19 Malm�, Sweden
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Crypto patentability
Date: Wed, 24 May 2000 00:06:10 -0700
Anders Thulin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> it seems reasonable to ensure that people knowledgeable about
> the patent system would participate as well, as this does not only
> refer to patents on crypto inventions, ut the entire patent system.
Good point. Patent law isn't applied differently to different fields. It
isn't really applied to the technology at all. It is more a template of
screens and tests for uniqueness and inventiveness in general. It took them
a long time to stop taking applications on perpetual motion machines and
death rays without an accompanying working prototype.
Paul
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: pentium timings
Date: Wed, 24 May 2000 01:14:13 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Hmm, well I get consistant results in win98 and pure dos. So
> magic or not it works. Also I can tell if it gets slower simply
> because the time increases. I don't think there is anything
> else to effect it. Even if my code is off by three cycles, it
> will be off for every trial.
The problem is that your code may say it's slower, and you may
believe it's slower, but in reality, it's faster...
> Also I doubt much pairs with
>
> rdtsc
> push eax
> push edx
"Pairing" is relevant only on the Pentium. On newer processors you
can out or order execution. The processor decodes instructions into
micro-ops. It dumps up to 40 micro-ops into the ReOrder Buffer.
Execution units grab instructions and execute them as soon as all the
resources to do so are free. If you want an in-depth look at this,
you might consider reading the Intel manuals, the MindShare books on
the Pentium Pro (or above) or, for perhaps the deepest look easily
availble, _The Anatomy of a High-Performance Microprocessor: A
Systems Perspective_ by Bruce Shriver and Bennet Smith (published by
IEEE). This covers the AMD K6 rather than an Intel processor, but
the differences between the two are in the details (e.g. number of
decoders) not the basic methods involved.
> So there won't be much clash with the code I am testing.
Rather the contrary -- essentially nothing else is going to depend on
results from these instructions, meaning they can be executed almost
_anytime_ the processor finds it convenient to do so.
[ ... ]
> I release my code to the public for pure research purposes. If
> you don't like my timer.asm code, why not contribute a fix?
I've offered to do so from the beginning. At least two other people
actually read what I said and have taken me up on the offer.
> It's not like I don't give out anything else (sboxgen, rc5asm,
> teaasm, etc...) so don't condemn my work because "he made a
> mistake so he's a complete moron".
I never said anything about your being a moron or anything like it.
I said that your actions were irresponsible. I've made no personal
attacks on anybody. I've offered to send you better code, and you've
completely ignored that offer, and instead attacked me. Though this
makes me feel somewhat less that charitable toward you at the moment,
the offer stands nonetheless. The code in question is public domain,
so you'd be perfectly welcome to use it, distribute it from your web
site, etc., if you wish to do so (of course the same applies to
anybody else as well).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Yet another block cipher: Storin
Date: 24 May 2000 07:36:01 GMT
Manuel Pancorbo <[EMAIL PROTECTED]> wrote:
> Let me finish my cipher. I'll explain these things in it.
I think I follow you anyway.
[G is triangular. Z is [d_ij] where d_ij = 1 iff i + j = 3 and zero
elsewhere.]
> M = (GZG)^2 (mod 2^24)
> {M^-1} = ({G^-1}Z{G^-1})^2 (mod 2^24)
> voil�! You have your key-dependent matrices. Squaring is made to
> increase diffusion.
This is true. However, it doesn't necessarily have my second criterion,
which I'm quite keen on.
It also involves having a Euclidean algorithm thing in the DSP to do
inversion mod 2^{24}, which strikes me as needing more code than
necessary to actually do the job.
The key schedule I have is expensive in terms of time (9 encryptions,
plus a bit), but reuses existing parts of the cipher rather well, so the
code is small. Having extra code which is only useful during keying
isn't so good.
> Each matrix occupies 16 words, so 32 words total. You will need 3 or 4
> temporal matrices, so 64 words of temporal rooming. I can't understand
> why your program takes so much time to compute the matrix.
Because it generates random matrices and throws them away if they don't
meet requirements. I don't want to have any more structure than is
necessary to make the cipher work.
Yes, I realize that if you don't mind matrices of particular forms then
you can do the inversion more cheaply.
Hmm. I think my criterion for only one even number in each row and
column is actually a sufficient condition for invertibility, so the
elemntary row ops method can be used to invert quite easily anyway.
-- [mdw]
------------------------------
Date: Wed, 24 May 2000 15:45:22 +0800
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: Chosen Plaintext Attack
Hi,
Referring to the post as a follow-up to Mark Wooding's post on
Interesting differentials of Breakme...
If we have a 10-round differential of prob. 2^-15.... how do we make use
of
this to break the cipher? I still do not have a clear idea how to
implement this
attack.. We need 2^16 chosen plaintext pairs... and then?
How do we implement the generation of for instance 2^16 chosen
plaintexts pairs? For
example, for the breakme cipher, we would like plaintext pairs with the
input XOR of
0x65000000... how do you translate that into C code?
--
Raphael
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Matrix reduction
Date: Wed, 24 May 2000 07:44:37 GMT
In article <8ge93d$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>, Chris Card
<chriscardN
> [EMAIL PROTECTED]> writes:
> >The (half-baked) idea I had was to get a random linear
> >combination of the vectors, score it (= number of non-zero
> >elements) and then slighty change the combination looking for
> >lower scores, until a local minimum is reached. Repeat until
> >local minimum = zero. From the point of view of memory
> >usage, this only needs the hold the matrix once + the linear
> >combination + a vector recording the elements in the linear
> >combination, which doesn't sound too bad. But I've no idea
> >how likely this approach is to get a linear dependency, and how
> >long it's likely to take.
>
> Since my first two attempts at replying to "Chris Card" off
> newsgroup resulted in mail-bounces, and I'm fairly sure that
> I'm more interested in Lanczos than he is in "hill-climbing"
> (an essential in Montgomery/Murphy polyn selection?), I'll
> post this for anyone else that Is interested in how Lanczos
> is used in gnfs.
Just goes to show how appearences can be deceptive :-) I was forced to
post from Remarq since deja.com was upgrading at the time (and let's not
get into arguments about newreaders - I only had web access at that
point), and Remarq kindly protected me against spam, and against helpful
answers too it seems. I am very interested in gnfs and I'm on the
learning curve at the moment (reading Murphy's thesis is one of the
things I'm doing). I haven't got as far as studying Lanczos yet (I will)
but this idea about hill-climbing occurred to me. Anyway back to the
topic ...
> I'm not familiar with anything other than block Lanczos, but
> I wondered what hillclimbing does with the collection of rows
> with a given weight?
I thought my second posting above explained what I had in mind.
Is it rubbish? (e.g. unlikely ever to find a dependency, or much too
slow?)
<snipped good stuff about Lanczos>
> Sincerely, B. Dodson, Math Dept, Lehigh Univ.
Chris Card
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: OAP-L3 for T Huuskonen
Date: Wed, 24 May 2000 00:49:57 -0700
T. Huuskonen says:
"My observation shows that for a large class of keys (those that
involve a non-trivial amount of processing before the generation
of the pseudo random digit stream) there is a faster attack against
OAP-L3 than brute forcing the whole key. Hence, your "security
level" calculations are wrong. Of course, an attack requiring
10^100 tries is just as impossible in practice as one requiring
10^1000 tries. In other words, I know that your "security level"
numbers are wrong, but I don't know whether the mistake has any
practical consequences whatsoever."
Your observation is not an observation. It is your fantasy.
The OAP-L3 random digit generator is loaded into RAM. The random
digits generated by the random digit generator are generated
and stored in about four RAM variables only. When three random digits
are generated, all triplets greater than 767 are discarded. Random
triplets of 767 and less are divided by three and the remainders are
truncated. Thus the output of the random number generator are random
numbers from 0 - 255. These random numbers are output to a RandOut
file.
There can be no other observation than this. Again, I am telling
you that your fantasy has no bearing on the facts.
Now, although I recommend that these RandOut files should be
processed further, let me entertain you and prove that you simply
are either intellectually dishonest or you are not that intelligent
or have not given the problem enough thought and exercised poor
judgment and jumped to an erroneous conclusion.
Let's suppose that we do not process these RandOut files any further.
And that the random numbers from 0 - 255 are then used to encrypt
messages.
I claim that you still cannot recreate the MixFiles. And here is the
very simple reason:
AS I just stated above, for every 1000 random triplets generated,
only 768 are used: 000 - 767. Thus 23.2% of the generated triplets,
and more specifically, 23.2% of the random digits are discarded. And
they are discarded at random.
Furthermore, the triplets that are used are divided by 3 and the
remainders are truncated.
So, what you have are 23.2% of the random triplets discarded and of
the triplets that are used you have a one in three chance of guessing
the actual last digit.
Let me also give you another break: although there are 5 different
MixFile lengths, let's say we just use a MixFile length of 3,628,800
permutations per MixFile.
YOur position is that you are given inside information to conduct
your own fantastic and bogus theory. You cannot have the first 1000
or so output digits from successive rotations, etc. In any
reasonable real situation this information is not available. You
must dismiss your fantasy.
So here is your problem and think about it very carefully, and so can
any other turkeys out there who think you are on to something.
The simplest reasonable problem you could possibly face is this: The
target does not reprocess the RandOut files and uses the direct
output from the random number generator to encrypt their messages.
You have plenty of plain text and its corresponding cipher text. To
make your work even simpler, let's say you actually have several
hundred gigabytes of the direct output from the random number
generator.
Since 23.2% of the triplets are discarded at random, approximately 1
of four are discarded at random. So, with every three random numbers
output, one has been discarded. And you don't know which one it was,
or where among the three outputs the discarded triplet was sequenced.
So how will you ever be able to align the output random number with
its associated MixFile permutations?
Not to mention determining what the last digit of the triplet
generated and used is.
Basically, you cannot determine what MixFiles are used to generate
the random output, which MixFiles were used to create the discarded
triplets, or when the MixFile rotates.
You have not observed anything. Your logic is totally screwed up and
I am laughing at all those who actually thought you were on to
something. You know nothing.
I pass the token. What say you?
------------------------------
Date: Wed, 24 May 2000 09:48:46 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Crypto patentability
John wrote:
> There is a legal question as to if patenting a computer program
> is even valid! Some argue that copyright is sufficient. With
> an NDA, it seems rights can be protected. There is other
> argumentation for having a "soft patent." A special class of
> certificate for computer programs. I don't think the courts
> will uphold patenting computer programs. I don't think we need
> soft-patents.
> http://www.aasp.net/~speechfb
Well I don't like patents, too. They are only a way for the
rich people to keep their richness. They are a way for the
big companies to stay big by destroying small companies
without much effort.
I hate the idea that you have to pay for thoughts and ideas.
Thoughts are free.
------------------------------
Reply-To: "Dave Jones" <[EMAIL PROTECTED]>
From: "Dave Jones" <[EMAIL PROTECTED]>
Subject: Re: Encryption within newsgroup postings
Date: Wed, 24 May 2000 08:52:02 -0000
Dear Volker,
Thanks for the suggestion - however, here is an example taken from a posting
entitled "Advice for new immigrants", which was cross-posted onto
comp.sys.sgi, with the ROT13 decryption following. Unless I am missing
something, I think there must be some other encryption used since ROT13
yields garbage. Have you any further ideas? I suspect you're probably
right that this may contain offensive material, but I am interested in how
it is done.
Posting:
Xuk yffi wfubsq ptiua bleow lfm fefea pl kyv ezpc!
Ncldm chla meeo rujo efeh acy uofjf
jysh umiym kqc pwsj let tt hodk nee
fjelk ailkn daltd sjs mlmjp ifujb big ueiub eotpev ymwk
ROT13 decryption:
Khx lssv jshofd cgvhn oyrbj ysz srsrn cy xli rmcp!
Apyqz puyn zrrb ehwb rsru npl hbsws
wlfu hzvlz xdp cjfw yrg gg ubqx arr
swryx nvyxa qnygq fwf zyzwc vshwo ovt hrvho rbgcri lzjx
Dave
"Volker Hetzer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Dave Jones wrote:
> >
> > Dear All,
> >
> > I have found a variety of newsgroup postings which have part of the text
> > encrypted. There are no numbers or special characters used, it looks
> > something like the following:
> >
> > yytjk y pltra........etc
> It's probably ROT13. That means that to every character the number 13
> is added (modulo 26) so that an "a" becomes an "n", a "b" an "o" and
> so on.
> The point is usually to prevent people from accidentally reading
> something they might find offensive (after warning them).
> The idea is that you have to act to make it readable and can't come
> across it accidentally.
>
> Greetings!
> Volker
> --
> I believe that children are our future --- nasty, brutish, and short.
------------------------------
** 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
******************************
