Cryptography-Digest Digest #689, Volume #10 Mon, 6 Dec 99 02:13:01 EST
Contents:
Re: DES ECB vs CBC (David Hopwood)
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Re: Random Noise Encryption Buffs (Look Here) (David Wagner)
Re: DES ECB vs CBC (Scott Fluhrer)
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: cookies (Mike Field)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: VIC cipher's PRNG ("Trevor Jackson, III")
Re: "The message is still the same." (Was Re: NSA should do ...) (wtshaw)
Re: compact encryption in javascript (David A Molnar)
Re: "The message is still the same." (Was Re: NSA should do ...) (Scott Nelson)
----------------------------------------------------------------------------
Date: Mon, 06 Dec 1999 04:45:11 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: DES ECB vs CBC
=====BEGIN PGP SIGNED MESSAGE=====
Terry Powell wrote:
>
> I was wondering if anyone could help me with this problem.
>
> I've working on adding DES encryption to a wireless system.
Why DES? It's slow and vulnerable to brute-force. Use something like
Blowfish or CAST-128 instead. Also think about whether you need an
authentication mechanism; don't assume that is automatically provided
by encryption.
> Messages transmitted on this system are generally short, 1 to 256
> blocks. A lot of the messages are state-of-heath messages from the
> system thus there will be a lot of repetition in the plaintext data.
> My approach has been to use DES in CBC mode and transmit a 64 bit
> IV ahead of the encrypted message.
Sounds reasonable to me, as far as it goes.
> There has been some debate over using CBC mode in this system. The
> main objection is the addition of the IV.
Is the objection on grounds of bandwidth/message size? If so, you could
consider using an implicit IV generated from the message sequence number
(e.g. IV = Encrypt[K'](sequence #), where K' is a second key independent
of the encryption key). That assumes that the transmitter and receiver
will always be able to keep their sequence numbers synchronised, of
course.
> The alternative design presented to me is DES using EBC mode
I assume you mean ECB.
> and placing
> a varying sequence number in the plaintext. The proponents of this mode
> state that it is just as secure as CBC with a plaintext IV (some claim
> it to be "equivelent").
It isn't (equivalent, or as secure). It will not have the desired effect
of disguising patterns in the plaintext, other than in the specific block
where the number is added.
> I'm having trouble buying their argument. I can understand that adding
> the sequence to the plaintext in [ECB] mode enhances that mode's security,
> but it seems to me that every block in a message would need to treated
> in this manner to keep it secure.
Yes, you're right.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOEs/FjkCAxeYt5gVAQGC7Af/XjDp9i0yNflMVKdZsFpB05/pCgM7qR0J
nbzThty/XXM6k5Kn+8f2ELMSA82z+KLJ/i9/rndGyBuB/ozWsQizl7QtWVO+lGKs
UTOgatyAfvzdDImboEO72GSP+ek3ONRvC7J40NRI6jDe7KmrVglSiUcG9YEUn1ca
iqcMcEp1JrPL7LyFtArL0rOADkhSrA+Ns+HIyJT6JBEFTgVIs0wzev7GqXA1ukuk
A6kUtUyTpO1/HrtXiSxuenqjgfD4OMZ/2poXEw5qjAAP7aOzcLtgED+c0H5lXzRB
QzIVjoTG4MzsQySWQp2dc0DVQ16RUbNyPK3iXdEGpuEOwrq5Tuk8aQ==
=r5gB
=====END PGP SIGNATURE=====
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sun, 5 Dec 1999 21:25:15 -0800
"Guy Macon" <[EMAIL PROTECTED]> wrote ...
[...]
: Consider. if you will,
: MOM (Macon's Overkill Method or Massive Overkill Method)
: of generating "random" numbers:
:
: Consider a "random" sequence of 1's and 0's
: (RBS, or Random Binary Sequence).
[...]
: An Exclusive OR (XOR) of a RBS with any sequence not derived
: from the same RBS is still a RBS. XORing any sequence will
: not and can not reduce the randomness.
Alas, this is not true if the elements of the sequence are
required to be mutually independent, or at least uncorrelated.
Let x1,x2,... be mutually independent binary random variables
with pr(xi=1)=pr(xi=0)=1/2, and let y1,y2,... be binary random
variables independent of the xi, but mutually correlated *among
themselves*, with nonzero covariance cov(y(i),y(i+1)).
Now zi = (xi XOR yi) = xi + yi - xi*yi, so we can easily calculate
the covariance between z(i) and z(i+1), which I find to be
cov(z(i),z(i+1)) = cov(y(i),y(i+1))/4 (nonzero).
So if {yi} is a pairwise correlated sequence, then the same will
be true of {xi XOR yi}, even though {xi} was an iid sequence.
: If a large number of candidate RBS's are XORed together, it only
: takes one true RBS to make the result a true RBS (but we can't
: prove that such a true RBS exists, so the result may not be a
: true RBS.)
:
: Thus my MOM method. Make as many binary sequences as you can,
: using various biased and unbiased RNGs. Look for sequences
: with biases that seem to be unrelated to the biases of other
: methods. [...]
: Now XOR in many other sequences, including state of the art
: pseudorandom number generators, FM noise, Diode noise,
: time between photons emmited by Radium, Speed of a hamster
: on an exercise wheel, etc, etc.
It was a neat idea, but I believe the flaw is fatal.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Mon, 06 Dec 1999 06:18:56 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> Precompression is meant to foil more sophisticated cryptanalytic
>> attacks by reducing the statistical clues that might otherwise
>> "shine through" the encryption. But the fact is most compression
>> schemes leak so much information that they may be opening up
>> more weakness than they hid.
>
>Except for the obvious case where a highly predictable "header"
>gives one (in effect) known plaintext, that claim seems counter-
>intuitive. Compression removes a *lot* of redundancy. Could
>you give a specific example of this information "leakage"?
You mean again.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 5 Dec 1999 21:34:53 -0800
In article <82fh6c$61e$[EMAIL PROTECTED]>,
r.e.s. <[EMAIL PROTECTED]> wrote:
> Let x1,x2,... be mutually independent binary random variables
> with pr(xi=1)=pr(xi=0)=1/2, and let y1,y2,... be binary random
> variables independent of the xi, but mutually correlated *among
> themselves*, with nonzero covariance cov(y(i),y(i+1)).
>
> Now zi = (xi XOR yi) = xi + yi - xi*yi, so we can easily calculate
> the covariance between z(i) and z(i+1), which I find to be
> cov(z(i),z(i+1)) = cov(y(i),y(i+1))/4 (nonzero).
>
> So if {yi} is a pairwise correlated sequence, then the same will
> be true of {xi XOR yi}, even though {xi} was an iid sequence.
I think you'd better double-check your math.
Suppose x1,x2 are independent coin flips.
Suppose y1 is a single coin flip (independent of the x's), and y2=y1.
This is the most extreme case of correlation possible for the y's.
Let zj=xj XOR yj.
Then it is readily confirmed that z1 is independent of z2.
For instance, Pr[z1=0,z2=0] = Pr[x1=y1,x2=y2] = Pr[x1=x2=y1] = 1/4.
And Pr[z1=0,z2=1] = Pr[x1=y1,x2=y2 XOR 1] = Pr[x1=x2 XOR 1=y1] = 1/4.
And so on.
Maybe you made a mistake in your calculations?
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: DES ECB vs CBC
Date: Mon, 06 Dec 1999 05:40:07 GMT
In article <[EMAIL PROTECTED]>,
Terry Powell <[EMAIL PROTECTED]> wrote:
>I was wondering if anyone could help me with this problem.
>
>I've working on adding DES encryption to a wireless system. Messages
>transmitted on this system are generally short, 1 to 256 blocks. A lot
>of the messages are state-of-heath messages from the system thus there
>will be a lot of repitition in the plaintext data. My approach has been
>to use DES in CBC mode and transmit a 64 bit IV ahead of the encrypted
>message.
Sounds fine, as long as you are careful in choosing the IV. The
ciphertext of the last block sent is a generally good choice.
Oh, and if you don't care to pad things out to a multiple of 64 bits,
you might want to look at 64 bit CFB mode. In addition, I assume that
you are worried only about privacy and not authentication (that is, you
are worried about other people obtaining information from your messages,
and not about them modifying legit messages, or sending their own).
> There has been some debate over using CBC mode in this system.
>The main objection is the addition of the IV.
It is hard to see why they are objecting to an IV. If it is the overhead
of the addition data to transmit, why does their alternative design also
add additional data to transmit?
>
>The alternative design presented to me is DES using EBC mode an placing
>a varying sequence number in the plaintext. The proponents of this mode
>state that it is just as secure as CBC with a plaintext IV (some claim
>it to be "equivelent").
If you are stating their design correctly, it is absurd. To make it
plain, I believe that they are proposing:
ECB( <Plaintext> | <Sequence number> | <More plaintext> )
where <Plaintext>, <More plaintext> are parts of the plaintext message,
broken up depending on exactly where they place the sequence number.
You are correct; in EBC mode, adding a sequence number will only
protect the (up to) two blocks that it shares with the plaintext -- if
any other blocks repeat between messages, it will be obvious. In
addition, if the sequence number ends up in its own block, it gains
you exactly nothing -- the attacker can strip it right out of the
ciphertext.
>
>I'm having trouble buying their argument. I can understand that adding
>the sequence to the plaintext in EBC mode enhances that mode's security,
>but it seems to me that every block in a message would need to treated
>in this manner to keep it secure. I just don't see how this can be a
>"better" approach.
Not only that, adding a sequence number to *every single* block will
cause rather serious ciphertext expansion, which is odd if the
objection to an IV is its 64 bits of ciphertext expansion.
A couple of suggestions:
- Make sure that you understand their objection; it just
doesn't make any sense given the alternative design
- Make sure that you understand the alternative design; it just
doesn't make any sense given their objection.
- Think about the attack model -- are you sure you don't care about
attacker's messages being accepted as legitimate by the receiver?
--
poncho
------------------------------
Date: Mon, 06 Dec 1999 00:53:07 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
r.e.s. wrote:
> I think the main underlying problem is that words like
> "strength" are used as absolutes. If I, and others, were
> to refer to a cipher's "strength wrt to secrecy"
> as distinguished from "strength wrt to authentication"
> there would less confusion. Since it appears to be
> standard to restrict the term to secrecy issues alone,
> however, I'll try to use it accordingly in future.
> (The implication is that authentication is not part of
> the role of a cipher, i.e., not something we should
> expect of it.)
Actually, I believe that to be the case. Authentication is a process ascribed
to a security protocol rather than a cipher algorithm.
>
>
> As for the other problem, I think it should be clear that
> "strengthening 'X alone'" may involve adding something to
> 'X alone', in which case it is no longer "X alone". But
> again, I'll avoid the contruction in future.
>
> --
> r.e.s.
> [EMAIL PROTECTED]
------------------------------
From: Mike Field <[EMAIL PROTECTED]>
Subject: Re: cookies
Date: Tue, 07 Dec 1999 07:47:54 +1300
"E. N. Kilomary" wrote:
> [EMAIL PROTECTED] (Eric Murray) wrote:
>
> >The server placing the cookie can set restrictions on which
> >servers can access the cookie.
>
> I don't believe that's true. A cookie can only be retrieved by the server
> that planted it there.
Things like requests for banner ads can return cookies. If you are a Banner
Ad company and you place ads on a lot of sites then you can generate a
profile of the sites the user visited...
The server that planted it may not be the server serving the web page you
are viewing, just a server you are requesting an imbedded image from!
------------------------------
Date: Mon, 06 Dec 1999 01:08:40 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Tim Tyler wrote:
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> :> : Tim Tyler wrote:
>
> :> :> Whereas your position appears to be based on faith in the existence of
> :> :> genuine randomness in subatomic behaviour, and in our ability to
> :> :> magnify this up to a macroscopic scale, without distorting it at all.
> :>
> :> : Do you know about SQUIDs? Photomultipliers? Etc.?
> :> : Why are you wasting bandwidth arguing about quantum effects
> :> : when you don't understand the subject? Go learn it first!
> :>
> :> It seems to be necessary - since some people seem to have the idea that
> :> a one-time pad is a realisable system.
> :>
> :> Without a source of genuinely random numbers a one-time pad falls short of
> :> theoretical perfection - and unfortunately, no source of demonstrably
> :> genuinely random numbers is - or IMO is ever likely to be - known to
> :> mankind.
> :>
> :> Even if you believe that SQUIDs or photomultipliers are capable of
> :> magnifying quantum events to a macroscopic scale without possibly
> :> introducing any interference from other sources, I would love to
> :> hear an explanation of how they could conceivably do this.
>
> : There is no need for esoteric equipment. The dark-adapted human eye detects
> : single quanta.
>
> I see no presentation of a complete system, though. If you give me
> something concrete to criticise, I will be able to do a better job.
>
> Say you use a source of light and a polariser followed by the human eye.
> You need to make sure that no light sources exist outside the system which
> could cause a false detection. Perhaps a bunker underground would
> suffice to shield from cosmic rays causing false positives in some
> potentially biased manner. Or perhaps not.
>
> How are you ensuring the light is evenly polarised? what are the
> polarising properties of the material between the light source and the
> polarising filter? How good is the polariser. Polarisers generally
> consist of very thin slits. But they are not /infinitely/ thin campared
> to the wavelength of photons. This causes deviations from a 50-50 split
> of photon absorbsion.
>
> How are you storing the binary sequence? Is this immune to undetected
> drop-outs? DO any dropouts occur to 1s as much as to 0s?
>
> *Some* of these issues can be cleaned up by post-processing. Indeed, I
> doubt all of them can. In fact, I doubt all of them can even be
> enumerated :-(
>
> A *perfect* source of random numbers is a bit like a perpetual motion
> machine - I doubt its existence.
> --
> __________
> |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
>
> "Bollocks," said Pooh, being more forthright than usual.
In response I'll repeat your seminal statement from above.
:> :> Whereas your position appears to be based on faith in the existence of
:> :> genuine randomness in subatomic behaviour, and in our ability to
:> :> magnify this up to a macroscopic scale, without distorting it at all.
Not faith. Fact. We can detect, amplify, and record quantum events. In fact
there are quantum effects that have macro-scale results such as super fluids.
As for distortion-free amplification and recording, such a system might be
possible, but I see no way to prove that it can be done, nor to prove that any
given system is perfect in that sense. Consider that perfection is impossible
because whatever instrument we use to measure the perfectness will have an
asymmetrical error rate. Similarly, given a perfect, bias-free source, the
utilization of the bitstream will manifest errors that are asymmetrical.
Rather than insisting on perfection, it makes sense to look for sources whose
distortion/bias/predictability is below our ability to detect those effects. This
leaves us vulnerable to an opponent who can detect more subtle effects that we
can, but it _quantifies_ the expected degree of imperfection. Thus we can
establish a ceiling* on the risk, and perform risk/benefit analysis to determine
whether a system is "good enough" to deploy.
* I believe this to be true, but I could not prove it. So the claim should be
treated skeptically until a more authoritative source addresses the issue.
------------------------------
Date: Mon, 06 Dec 1999 01:16:49 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
r.e.s. wrote:
> "Guy Macon" <[EMAIL PROTECTED]> wrote ...
> [...]
> : Consider. if you will,
> : MOM (Macon's Overkill Method or Massive Overkill Method)
> : of generating "random" numbers:
> :
> : Consider a "random" sequence of 1's and 0's
> : (RBS, or Random Binary Sequence).
> [...]
> : An Exclusive OR (XOR) of a RBS with any sequence not derived
> : from the same RBS is still a RBS. XORing any sequence will
> : not and can not reduce the randomness.
>
> Alas, this is not true if the elements of the sequence are
> required to be mutually independent, or at least uncorrelated.
>
> Let x1,x2,... be mutually independent binary random variables
> with pr(xi=1)=pr(xi=0)=1/2, and let y1,y2,... be binary random
> variables independent of the xi, but mutually correlated *among
> themselves*, with nonzero covariance cov(y(i),y(i+1)).
>
> Now zi = (xi XOR yi) = xi + yi - xi*yi, so we can easily calculate
> the covariance between z(i) and z(i+1), which I find to be
> cov(z(i),z(i+1)) = cov(y(i),y(i+1))/4 (nonzero).
>
> So if {yi} is a pairwise correlated sequence, then the same will
> be true of {xi XOR yi}, even though {xi} was an iid sequence.
>
> : If a large number of candidate RBS's are XORed together, it only
> : takes one true RBS to make the result a true RBS (but we can't
> : prove that such a true RBS exists, so the result may not be a
> : true RBS.)
> :
> : Thus my MOM method. Make as many binary sequences as you can,
> : using various biased and unbiased RNGs. Look for sequences
> : with biases that seem to be unrelated to the biases of other
> : methods. [...]
> : Now XOR in many other sequences, including state of the art
> : pseudorandom number generators, FM noise, Diode noise,
> : time between photons emmited by Radium, Speed of a hamster
> : on an exercise wheel, etc, etc.
>
> It was a neat idea, but I believe the flaw is fatal.
No. Your mathematical model is flawed. Consider the first bit of X.
If x1 is a random binary variable, you can mix it with anything, even a
constant, and the result will be a random binary variable. The same
consideration applies to all succeeding bits. Because the bits of X
are independent, the bits of Z are also independent. The statistics of
Y are irrelevant. Like multiplying a number by zero, the result is the
same no matter what the input number.
------------------------------
Date: Mon, 06 Dec 1999 01:20:38 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: VIC cipher's PRNG
r.e.s. wrote:
> "David Wagner" <[EMAIL PROTECTED]> wrote ...
> : r.e.s. <[EMAIL PROTECTED]> wrote:
> : > I was looking at the very simple PRNG used in the VIC
> : > cipher, which operated with decimal digits. In pseudo-
> : > code, and generalizing to base-b digits, registers
> : > R(i)(i=1..b) are initialized to R(i)=key(i)(i=1..b),
> : > and a stream is output by iterating the following:
> : >
> : > ------
> : > R(b+1) = R(1) + R(2) (mod b)
> : > R(i) = R(i+1) for i=1..b
> : > output R(b+1)
> : > ------
> : >
> : > What I'm wondering about is, for b>2, how to get any
> : > idea of the cycle-length of the stream, e.g., how the
> : > cycle-length depends on the particular (key(i),i=1..b).
> :
> : Yeah, there's some interesting mathematics here.
> :
> : Factor b as a product of prime powers, b = \prod_{j=1}^n p_j^{e_j}.
> : Reducing modulo each prime power gives us n recurrence relations:
> : R(i) = R(i-b) + R(i-b+1) mod p_j^{e_j}, j=1,..,n.
> : Let C be the desired cycle-length mod b, and C_j be the cycle length
> : mod p_j^{e_j}. By the Chinese Remainder Theorem, C = lcm(C_1,..,C_n).
> :
> : Consequently, it suffices to analyze the cycle length of the recurrence
> : relation over the rings Z/p^eZ. Classical shift register theory should
> : get you the rest of the way, I suspect -- or at least, for the e=1 case.
> : See, e.g., Golomb's treatise.
> :
> : (Does anyone know if the e>1 case has been studied? Or does Hensel
> : lifting make the e>1 case follow easily from the e=1 case, or somesuch?)
> :
> : To give you a taste of classical shift register theory, we will probably
> : want to look at the polynomial
> : f(x) = x^b + x^{b-1} + 1 in (Z/p^eZ)[x]:
> : e.g., is it irreducible, primitive, and so on. More generally, if I'm
> : not mistaken, the cycle length mod p^e should divide the order of x in
> : (Z/p^eZ)[x]/(f(x)), I think. But please check these claims carefully for
> : yourself -- they're off the top of my head, and I'm not too terribly good
> : at shift register theory, so I might have gotten important facts wrong.
> :
> : In the special case where b=10, we write b=2*5, and note that we get
> : a linear combination of a 10-bit traditional LFSR over GF(2) and a
> : 10-symbol linear shift register over GF(5). Therefore, I'd expect the
> : cycle length to be very good, but the security to be potentially very
> : low: the LFSR over GF(2) provides very little security, thanks to the
> : Berlekamp-Massey cryptanalysis algorithm; I can't imagine the LFSR over
> : GF(5) is much better (but I don't know for sure whether Berlekamp-Massey
> : generalizes to arbitrary finite fields, offhand).
> :
> : Hopefully that should be enough to get you started, even if I got some
> : of the details slightly wrong. Enjoy!
>
> Thanks very much for all the pointers!
>
> The Berlekamp-Massey algorithm must be very cool. Although I knew
> that an LFSR sequence could be used to get good clues about the
> initial key, I didn't know there was an actual algorithm to
> re-construct it, at least for b=2. (I'm just now reading this on
> Terry Ritter's webpage.) And I'm really curious whether it's been
> generalized to b>2.
>
> I'd love to just take a look at Golomb's _Shift_Register_Sequences_
> but haven't been able to find it yet.
In case you need it, the ISBN of the revised edition, 1982, is 0-89412-048-4.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: "The message is still the same." (Was Re: NSA should do ...)
Date: Mon, 06 Dec 1999 00:41:46 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>...... Cryptography
> is something that now has, not only military, but enormous
> *non-military* requirements. That requirement is e-commerce, which was
> responsible for something like $3 billion in public transactions last
> year! Almost all of it protected by a none-too-strong cryptographic
> tool, a recent invention called SSL. ATM machines are bloody everywhere
> and -those- are protected by a government invention called DES. And so
> on.
>
> So the NSA is percolating along, on its military frequency as it always
> does, in secret as it always does ... and now they're not the only game
> in town. We have our secrets to protect, too.
>
Surely they yearn for something like a monopoly again, but that wishful
thinking is apt to remain a pipe dream. It is hard to control that which
grows faster than you can. Throwing increasingly more money into the
abysis will not prove realistic.
It remains for governments and monopolistic companies to dumb down crypto
as best they can, to stretch their heavy hands; it remains our goal to
fight that as being unwise and short sighted.
--
Adequate security means causing an attacker to give up and spend his time attacking
someone else.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: compact encryption in javascript
Date: 6 Dec 1999 06:02:51 GMT
AllanW <[EMAIL PROTECTED]> wrote:
> Unlike the previous poster, I'm not quite so worried about
> space; I can easily go to 50 or even 100 lines of either
> JavaScript or VBScript. (I also can use VAX assembly language
> but I'm guessing that wouldn't be quite as portable across the
> Internet.)
are you sure there isn't a single instruction which will do
all you want?
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: "The message is still the same." (Was Re: NSA should do ...)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 06 Dec 1999 06:45:46 GMT
On Sun, 05 Dec 1999 Sundial Services <[EMAIL PROTECTED]> wrote:
>For all the tax-money that NSA slurps up each year, and for the enormous
>number of people who (like it or not, acknowledge it or not) depend upon
>their cryptographic expertise to ensure that another Nazi Germany does
>not appear again on this earth, I sincerely hope that they can break
>most commercial systems -- and that they keep their mouths tightly shut,
>as they do, about what they can and cannot do.
>
>I still remember a poster that I saw in a hallway outside the National
>Cryptography Museum. It was a WW2 poster, "Loose Lips Sink Ships," and
>beneath it was printed, simply, "The message is still the same."
>
This was only barely on topic when speculating about the NSA's
capabilities. The moral correctness of "the ends justify the means"
has been well established, but is hardly a fit topic for sci.crypt.
(I wonder if the poster is intentionally invoking Godwin's rule. -
#4 - http://www.ews.uiuc.edu/~tskirvin/faqs/legends/legends2.html)
Take it to talk.politics.crypto.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
