Cryptography-Digest Digest #463, Volume #12 Wed, 16 Aug 00 22:13:01 EDT
Contents:
New Stream Cipher like SEAL ([EMAIL PROTECTED])
Re: 1-time pad is not secure... (Tim Tyler)
Re: 1-time pad is not secure... (Tim Tyler)
Re: Quick Question (Part Two) (Steve Rush)
Re: New Stream Cipher like SEAL (Paul Rubin)
("John")
Paradoxes, off-topic (was Re: 215 Hz five-qubit quantum processor) (David Hopwood)
Re: 215 Hz five-qubit quantum processor (David Hopwood)
Re: OTP using BBS generator? (David Hopwood)
Re: OTP using BBS generator? (Tim Tyler)
Re: Quick Question (Part Two) (David A Molnar)
Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ? ("Tor Rustad")
Re: New Stream Cipher like SEAL ([EMAIL PROTECTED])
Re: OTP using BBS generator? ("Paul Pires")
Re: OTP using BBS generator? (Tim Tyler)
Re: The quick brown fox... (Benjamin Goldberg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: New Stream Cipher like SEAL
Date: Thu, 17 Aug 2000 00:15:10 GMT
This is a stream cipher like SEAL where it stretches a 32-bit value
into a larger value. I don't see any obvious flaws in it so I figured
someone here may want to beat at it before I actually write up a report
on it.
The C source (really easy to read) is at
http://www.geocities.com/tomstdenis/files/sc1.c
On my K6-2 I get 15 cycles per byte with the C code which is really
kinda cool.
Please comment if possible.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 00:07:35 GMT
Darren New <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Except that it doesn't say any such thing. Completely deterministic
:> interpretations of quantum theory exist, namely - for example - the MWI.
: Just out of curiousity, what determines which branchs "you" have taken in
: the MWI?
That would be a meaningless question ;-)
: [...] By "you" I mean the person reading this post. [...]
If following a MWI, there are many "me"s and many "post"s. All have
equal rights and status. By saying "this" post, you haven't uniquely
identified anything, since there are many posts which are all claiming
to be "this" post.
--
__________ 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: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Wed, 16 Aug 2000 23:59:27 GMT
Sniggerfardimungus <ronb.cc@usu@edu> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> writes:
:> ``There is a branch of theology that seems to be influencing people
:> who don't know the root source of the ideas they hold.''
:>
:> This looks more like psychoanalysis than memetics to me.
:>
:> Also, there's no need to patronise me. I'm quite aware of the
:> similarities and differences between psychoanalysis and memetics.
: Evidently you don't. [...]
Blah, blah, blah...
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (Steve Rush)
Subject: Re: Quick Question (Part Two)
Date: 17 Aug 2000 00:46:40 GMT
>...every aspiring
>computer scientist should own the three volumes by Professor Knuth
>even though he perists to use assembly language to exemplify
>(implement) his algorithms.
Professor Knuth explains why he uses assembly language (for the hypothetical
MIX machine, so as not to favor any real machine). He wants to make clear what
the machine actually does. He also states each algorithm in prose pseudocode
and flowchart form, so you can implement it in whatever language you happen to
be working in.
==========================================================================
==============
If it's spam, it's a scam. Don't do business with Net abusers.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: New Stream Cipher like SEAL
Date: 17 Aug 2000 00:54:09 GMT
In article <8nfapv$4r1$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>On my K6-2 I get 15 cycles per byte with the C code which is really
>kinda cool.
>
>Please comment if possible.
This is unimpressive for a 32-bit stream cipher. I think you can get
more speed than that with 8-bit RC4. Do you have an estimated speed
for an asm implementation?
That said, it's nice to hear you've gotten interested in stream ciphers.
More block ciphers are the last thing this newsgroup needs.
------------------------------
From: "John" <[EMAIL PROTECTED]>
Subject:
Date: Wed, 16 Aug 2000 19:46:30 -0400
testing. Trying to figure out why I couldn't get posts in.
------------------------------
Date: Thu, 17 Aug 2000 01:26:07 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.arch
Subject: Paradoxes, off-topic (was Re: 215 Hz five-qubit quantum processor)
=====BEGIN PGP SIGNED MESSAGE=====
"Trevor L. Jackson, III" wrote:
>
> I think Godel v. Russell established the fact that this is not possible.
> Russell wanted to show that all of math was consistently derived from a small
> set of foundation premises. Godel showed that math is incomplete in the sense
> that not all truths can be deduced from the premises. Godel used a special kind
> of theorem that implied something like "This theorem is false". When you run
> that through a prover you get an undecidable result -- like talking to a person
> who says "I always lie".
Somewhat off-topic for both sci.crypt and comp.arch, but "I always lie" is not
paradoxical, because it can be resolved by concluding that the speaker sometimes
lies (i.e. "I always lie" is a lie, and that does not lead to any inconsistency).
"This statement is false" is a better example of a self-referential paradox.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOZsxBDkCAxeYt5gVAQFXFwf/cICGE6hQOAZs/UCRr+0zutFCG+Ox08Tl
c5bn5/b+ICCUG7PCcYQ0qF8vRrWf8qMdUNAyrWG8I6pad293ARfvdszxoLfkCc38
8/HjT+pLslc1X7fD+p+CEW9p97BCcOtEtxfbrVvAmLJckplnGhBSeuLqYQdY6Jxz
Dq/vGTLsVAI44+Lqn66kmWh41b5cm7i3bzUs+DjHFwETZ3tG2wN1Ol9vdP0xORiO
yowWVULlTT+1zstNsH5BQI3NLICZkCGuO10pBqHuYtsCTBu6d3k6brSoKpuWat8G
WwvcbDTFRz4jNjkxkU+N2SCTUeJ9+iH9B0Qyzq6CuToGlTRu6XoQ7A==
=DLZ0
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 17 Aug 2000 01:45:20 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
=====BEGIN PGP SIGNED MESSAGE=====
Steve Newman wrote:
> It occurred to me some years back that with the appropriate "magic
> box", you could trivially implement a theorem prover for arbitrary
> theorems. Simply generate all possible strings up to a certain
> length, and run each string through a theorem checker to see if it
> constitutes a proof for the theorem. This requires a theorem
> checker, but that's not hard to write.
>
> Could this algorithm be implemented in a (sufficiently advanced)
> quantum computer?
No. Grover's algorithm would take O(sqrt(n)) time for this kind of
search, where n is the the number of theorems in the search space.
I.e. this is still an exponential algorithm on a quantum computer,
since Grover's algorithm is near-optimal for a brute-force search.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOZs1gzkCAxeYt5gVAQHlpwf/W1+Qvg6iOls1QUks9Ykk83lNABTLELwS
yP6lIQrUrpRgNzBDBZa2Zu8pW3c3qJS3m+NwuDsM48n4eV49nTQmDiyP7pcZAXMk
o0Mf3bgzS+vd7e2Lkgg7rdQ4buMGNczYOxAiCt1pJYKk1Uh2vTsGq4c28WZk/iSj
sLFLtFyV6gTXTyGUHXECls8bZdcM8WZ4IPBjaMOGW1LXlriYVLSDVlMYkhtnrkJg
Zvpi/Ot9K1dkGvn5QywyNiLfCVD7eUxyT9tIE7ZHccjekUG19pPdI06SKZcOO0ba
d7N5/bR7ujbwA1FMEbv9TpWhWcU3XwDzMhG8LWIoqQ6YulFOxxh9VA==
=t0RX
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 17 Aug 2000 01:46:07 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: OTP using BBS generator?
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> > Mok-Kong Shen wrote:
> > > Sorry, I am really confused. 'Parity bits' or 'LSB'? Thanks.
>
> The least significant bit is often called the `parity bit' by
> mathematicians, since it represents the number's parity -- its oddness
> or evenness. It is this sense of the word `parity' used by Blum, Blum
> and Shub in their 1982 paper.
>
> > Either (they are equally secure).
Oops, no they aren't (or at least this is not proven).
> That's interesting to know.
I had made a mistake in interpreting the "XOR-Condition" from the Vazirani
paper. The XOR of the least significant log log N bits is secure, but this
doesn't extend to the XOR of all the bits (i.e. the parity in the sense
probably meant by Mok-Kong Shen).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOZsnRzkCAxeYt5gVAQGiawf/R25A1a4G5pbkbfkcx7A3ydKw8p0bIps5
OOuvqVWLac+igD4RIB6ki/tSxux2OU2GEHaEXfkzJh5u28IAcGsfznZUeZceWN5B
x+GaENh6YE/fbxQZRGz7Anv3JSloa5Y6XTW3OM/2JpqJ95pd9Oawlq26QzkAYmY0
aF/a9XEh0q+r9v2SuWCc5OwRjttLZO/PCUmbMeRSPsX7tjIHmB2luUP3vHv/xxa8
D+kU0FY8F/OWMtqa28ym8Pi4nWrwAUExQjLC/36q/jMS4TizsmOLY2yrMlSgOaYP
YgdYzfOFoIbiRGehUpb0sUarYr1Q/D0rdt/FUhQP3OIRTpSXoG4+sA==
=Q8Vd
=====END PGP SIGNATURE=====
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 00:42:09 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
:> Bryan Olson wrote:
:> : Many times on sci.crypt people have objected to the proof of
:> : perfect secrecy for the OTP based on the fact that the zero
:> : vector is one of the possible keys. The false logic goes
:> : something like: since the OTP is provably secure, and zero
:> : is a legal key, then encrypting with the zero key must be
:> : secure, and since it obviously isn't the proof must be
:> : wrong.
:>
:> : The OTP theorem doesn't say that encrypting with a
:> : particular key will maintain secrecy. It says choosing a
:> : one-time key uniformly at random and exposing the resulting
:> : ciphertext does not increase the chance of the attacker
:> : determining the plaintext.
:>
:> This case still seems totally different from the case of
:> using BBS with short cycles.
:>
:> Using the all-0 key in an OTP doesn't help the attacker
:> get the message, since he has no way of knowing it has been used.
: Not so. If in fact one does use the all zero key of
: significant length, the attacker should win. He would
: almost certainly think we were not in fact using a true one
: time pad. There's nothing in the theorems that will stop
: him from reading cleartext.
Doesn't this violate the assumption that the attacker has full knowledge
of the cyphermachinery?
Anyway, the cases still seem significantly different: *if* the attacker
knows what machinery has been used, the chance use of a zero key in an OTP
gives the attacker no information about the plaintext, while the chance
use of a short cycle in a rng-based stream may completely give the game
away - *assuming* the attacker is generally running a short cycle check,
based on known plaintext for some reason.
: An attacker's chance of factoring a known modulus given BBS
: output (from a random starting point) is the same as his
: chance without the generator output. Again, that follows
: from the space of possible choices.
Essentially, I agree with this. I suspect, however that it assumes that
any hardware used for checking for short cycles may also - in principle
- be used to factor the modulus. This is probably a very reasonable
assumption - but I doubt it's necessarily always true.
If looking for short cycles in the output is easy, while (say) generating
output and then looking for short cycles is not, this may create an
asymmetry, which might mean that short cycles in the output /do/ represent
what Ritter has called an "additional" weakness.
The assumptions here may be rather contrived however...
Normally, looking for short cycles in this system would probably be a
waste of time and resources. It would not be the best way to attack.
However, if it's being done /anyway/, for some other reason (say to detect
the use of occasional messages in another cypher), then this too might
cause short cycles to be an actual source of weakness.
<giggles> Another issue might be that rejecting short cycles appears to
decrease the size of the keyspace. Has anyone yet proposed that rejecting
these seeds is a cause of loss of strength? ;-)
This post is a little speculative - but I've not seen these issues raised
elsewhere. I'd be interested to know if this line of reasoning has any
substance.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Quick Question (Part Two)
Date: 17 Aug 2000 01:18:11 GMT
Steven Knight <[EMAIL PROTECTED]> wrote:
> Now I know this is not the right NG but I have been unsuccessful in all C++
> NG's
> Could anyone give me C++ code on some simple algorithms
Others have pointed out the really, really good references like Knuth
and CLR already. I'll just add two more :
_Algorithms, Problem Solving, and Data Structures in C++_ by Mark
Allen Weiss. I used this for a summer course I took a while back. Includes
some nice, easy to follow descriptions of various algorithms. Including
splay trees, oddly enough. (I still haven't heard them mentioned in
class since, but I haven't taken the intro algorithms here yet).
Nice, readable, basic presentation with lots of C++ source.
_The Algorithm Design Manual_, Steve Skiena. Includes pointers to the
Stony Brook Algorithm Repository and Netlib. Not formal at all, which
is both its charm and its weakest point. Lots of good war stories,
along with a healthy dose of algorithmic snobbery (check the
war story about the supercomputing colleague with a "glazed look in his
eye"). Maybe my favorite part is the overview and references for a massive
array of algorithms. Includes a CD as well.
and speaking of that, do a web search for "netlib" and you will find
some source code for algorithms online...
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: WAP gateway to WWW - Will this configuration really fly from a security
perspective ?
Date: Thu, 17 Aug 2000 03:32:58 +0200
"Mark Currie" <[EMAIL PROTECTED]> wrote in message
> In article <5jfm5.3586$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >
> >>"Mark Currie" <[EMAIL PROTECTED]> wrote in message
> <snip>
> >> Perhaps if the Telco's were to get ITSEC-E4-high approval for their SIM's,
> >>this
> >
> >What does ITSEC-E4... prove? For me, the most interesting parts are not in
> >such reports, since they are incomplete.
> >
>
> ITSEC basically certifies the correctness of the design. The "E4-high" part
> means "high security" which means that they will do penetration testing. This
> includes SPA, DPA, chemical, temperature, physical, etc. A good combination is
> to get both ITSEC-E4-high as well as ZKA approval. The ZKA approval involves
> checking the implementation security as well following the chain-of-trust.
> Common Criteria, as far as I know, is like a combination of the European
> standards and the American NIST standards like FIPS140 but, once again as far
> as I know, CC does not include the implementation and delivery security
aspects
> that are part of ZKA approval.
Well, I thought ITSEC included just the parts that the card manufacturer wanted,
and in that respect its different from i.e. FIPS 140-1 level 4. The ITSEC-E6
report I have seen, included no such things as physical panetration testing or
side-channel attacks. But, there was some interesting formal methods used to
'prove' the security from a theoretical view point, in fact the ITSEC report
only included analysis of SW development and that this SW worked correct. HW
where only analysed from its blueprint, no physical test/attacks at all...
If such information had been included, I would watch very carefully which labs
performed the testing.
CC is somewhat like ITSEC, and this is a common framework for protection
profiles, its basically with the US included ;-).
> You are right that approvals/certifications don't prove that a module is
> secure, but I would far rather trust a module that has gone through this than
> one that has not, even if the suppliers have had *lots* of experience.
Certifications are important, but the most secure product is not automatically
from those who put most mony into the certification.
--
Tor
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New Stream Cipher like SEAL
Date: Thu, 17 Aug 2000 01:32:16 GMT
In article <8nfd3h$usl$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> In article <8nfapv$4r1$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >On my K6-2 I get 15 cycles per byte with the C code which is really
> >kinda cool.
> >
> >Please comment if possible.
>
> This is unimpressive for a 32-bit stream cipher. I think you can get
> more speed than that with 8-bit RC4. Do you have an estimated speed
> for an asm implementation?
It actually outputs 16 bytes at a time, but you can obviously just
ignore the bytes you don't use.
And I would think 22mb/sec is rather quick enough for a stream cipher.
My HD only works at 5mb/sec anyways!!!
This is faster then Blowfish, RC5, IDEA, etc...
I dunno if in ASM it would be terribly faster. I haven't tried yet
though, maybe it could be shaved down a few cycles.
> That said, it's nice to hear you've gotten interested in stream
ciphers.
> More block ciphers are the last thing this newsgroup needs.
Hehehe well this is a nice stream cipher, nice and simple :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Wed, 16 Aug 2000 18:47:02 -0700
Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Bryan Olson <[EMAIL PROTECTED]> wrote:
> :> Bryan Olson wrote:
>
> :> : Many times on sci.crypt people have objected to the proof of
> :> : perfect secrecy for the OTP based on the fact that the zero
> :> : vector is one of the possible keys. The false logic goes
> :> : something like: since the OTP is provably secure, and zero
> :> : is a legal key, then encrypting with the zero key must be
> :> : secure, and since it obviously isn't the proof must be
> :> : wrong.
> :>
> :> : The OTP theorem doesn't say that encrypting with a
> :> : particular key will maintain secrecy. It says choosing a
> :> : one-time key uniformly at random and exposing the resulting
> :> : ciphertext does not increase the chance of the attacker
> :> : determining the plaintext.
> :>
> :> This case still seems totally different from the case of
> :> using BBS with short cycles.
> :>
> :> Using the all-0 key in an OTP doesn't help the attacker
> :> get the message, since he has no way of knowing it has been used.
>
> : Not so. If in fact one does use the all zero key of
> : significant length, the attacker should win. He would
> : almost certainly think we were not in fact using a true one
> : time pad. There's nothing in the theorems that will stop
> : him from reading cleartext.
>
> Doesn't this violate the assumption that the attacker has full knowledge
> of the cyphermachinery?
>
> Anyway, the cases still seem significantly different: *if* the attacker
> knows what machinery has been used, the chance use of a zero key in an OTP
> gives the attacker no information about the plaintext, while the chance
> use of a short cycle in a rng-based stream may completely give the game
> away - *assuming* the attacker is generally running a short cycle check,
> based on known plaintext for some reason.
>
> : An attacker's chance of factoring a known modulus given BBS
> : output (from a random starting point) is the same as his
> : chance without the generator output. Again, that follows
> : from the space of possible choices.
>
> Essentially, I agree with this. I suspect, however that it assumes that
> any hardware used for checking for short cycles may also - in principle
> - be used to factor the modulus. This is probably a very reasonable
> assumption - but I doubt it's necessarily always true.
>
> If looking for short cycles in the output is easy, while (say) generating
> output and then looking for short cycles is not, this may create an
> asymmetry, which might mean that short cycles in the output /do/ represent
> what Ritter has called an "additional" weakness.
>
> The assumptions here may be rather contrived however...
>
> Normally, looking for short cycles in this system would probably be a
> waste of time and resources. It would not be the best way to attack.
> However, if it's being done /anyway/, for some other reason (say to detect
> the use of occasional messages in another cypher), then this too might
> cause short cycles to be an actual source of weakness.
>
> <giggles> Another issue might be that rejecting short cycles appears to
> decrease the size of the keyspace. Has anyone yet proposed that rejecting
> these seeds is a cause of loss of strength? ;-)
Good point.
I've been trying to follow this conversation and it seems to me that this is
the essense of Bryan Olson's point (don't shoot, Im running as fast as I
can). But if you conceed that the occurance is exceedingly rare it does not
seem as if it could be a meaningful reduction. A theoretical weakness
without practical repercussions?
Now here is the leap, are we just rying to figure out which miniscule,
non-optimal effect is worse?
>
> This post is a little speculative - but I've not seen these issues raised
> elsewhere. I'd be interested to know if this line of reasoning has any
> substance.
> --
> __________ 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: OTP using BBS generator?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 00:56:09 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Well, I haven't "objected to the proof of perfect secrecy for the
: OTP", but I have noted that people might be tempted to reject the
: all-zero key, despite the fact that this, from a theoretical point of
: view, is wrong.
: I even went as far as to defend this practice as being not all that
: bad. Perhaps this makes me a heretic, but I don't think it goes
: against truth in the practical sense.
Imagine a rare spy, who - after landing in enemy territory - opens up
his OTP and prepares to report that his espionage mission began
successfully. Scanning the pages, he finds all the symbols are zeros.
Imagine his dismay ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: The quick brown fox...
Date: Thu, 17 Aug 2000 02:01:21 GMT
Mike Brown wrote:
> Justly vexed, the Queen exiled the calligrapher who spattered some
> black ink on her dog.
This one isn't a pangram, there's no "z" in it!
--
"There's a mathematical reason not to trust Christians... The Buddhists
believe that human lives repeat. The atheists believe that human lives
terminate. That means that the Christians must believe that humans are
irrational."
- Matt Katinas
"Of course Christians think humans are irrational: They believe humans
are transcendental, and all transcendentals are irrational."
- Me, in response the the above
------------------------------
** 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
******************************
