Cryptography-Digest Digest #475, Volume #10 Sat, 30 Oct 99 22:13:03 EDT
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: Biometric Keys are Possible ([EMAIL PROTECTED])
Re: Some humble thoughts on block chaining ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: How to use CBC w/ RC4? ([EMAIL PROTECTED])
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E ([EMAIL PROTECTED])
Re: Bernstein and letting the court write (or rewrite) laws ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Date: Mon, 25 Oct 1999 00:53:41 +0200
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Rats. Thinking faster than I can TPYE again...
Please replace "basic wheel" with "basic squeaky wheel".
Sorry.
Trevor Jackson, III wrote:
>> Vernon Schryver wrote:
>>
>> > In article <[EMAIL PROTECTED]>, Terry Ritter
><[EMAIL PROTECTED]> wrote:
>> >
>> > > ...
>> > >>How can you point to modems as a good example of the wonders of
>negotiating
>> > >>protocols? I think the politics and sausage warning applies.
>> > >
>> > >I think the real world applies: We have such modems. We use them.
>> > >They work. End of story.
>> >
>> > That might be the end of a fairy tale or a nightmare, but I
>> > thought you were talking about engineering.
>> >
>> > Modems do not work all of the time. A cipher negotiating protocol
>that
>> > failed as often as modems fail today in real life would not be
>something
>> > I'd want to trust my phone bill to, not to mention something that
>matters.
>> >
>> > > ...
>> > >I doubt I implied that modem negotiation is "clean." But it *is*
>> > >"background," and it *is* negotiation (both sides participate in the
>> > >final result), and it *is* "real world" -- it generally works in
>> > >practice.
>> >
>> > The "it generally works in practice" can be said about PPP, only more
>so.
>> > And again, who wants a cipher negotiating protocol that "generally
>> > works in practice"?
>> >
>> > Only salescritters or people with no technical knowledge can claim
>that
>> > either PPP or modems are examples that could cause a working engineer
>to
>> > be enthusaistic about negotiating ciphers. Sane, technically inclined
>> > people who look at modems, PPP, or any other "standardized", dynamic
>> > negotiating network protocol must be very skeptical of the idea.
>>
>> Any other? I think not.
>>
>> You can pick on negotiation failures typically those that evolved over
>time, which
>> usually means layers of kludge upon kludge, sometimes driven by
>commercial issues
>> (PPP), and sometimes driven by technological advances (modems).
>>
>> OTOH, you have failed to note the cases in which negotiation is so
>successful that
>> it is almost invisible. Consider DECnet. Once a machine is configured
>there is
>> little chance of failure. You hook up the wires and the machine
>figures out wht
>> topology necessary to communicate with other machines. This is a
>negotiation
>> protocol that works.
>>
>> Note that this class of error, noticing only the problems, is a basic
>wheel
>> approach which causes sampling error.
>> There is no alue to this sort of anecdotal horror story. If you want
>to address
>> the topic of negotiating protocols, please produce an issue that you
>believe will
>> be difficult to solve and lead to negotiation failures.
>>
>> >
>> >
>> > >Cipher negotiation can be far cleaner -- provided a single selection
>> > >mechanism is standardized. If not, then we may see the same sort of
>> > >ad hoc stuff we saw with modems.
>> >
>> > But "ad hoc" modem negotiation was your counter to the 10+ years of
>> > public experience with offically standardized, carefully architected,
>> > designed and tested PPP.
>> >
>> > As for "can be cleaner...", those words echo what was said about
>> > standardizing the negotiations between wide area routers in the
>leased-line
>> > IETF WG that was merged with the SLIP-replacment WG in about 1987 to
>form
>> > what is now the PPP working group. I think users are better served by
>> > the result (PPP) than by the old proprietary protocols, but no one can
>> > call PPP clean--at least no one honest and with a clue.
>> >
>> > Maybe Communism will work the next time it's tried too.
>> > But my money is on standards committees behaving like committees.
>> >
>> > > ...
>> > >I would say, "let's not do it like PPP."
>> >
>> > Exactly how would you do that? The problems with PPP negotiating are
>not
>> > any single technical issue, but the inevitable morass that comes with
>> > complicated network stuff in the best possible circumstances.
>>
>> Not relevant. We aren't faced with "complicated network stuff" or
>anything
>> similar. Anyone adding one or more AES ciphers to an existing
>multi-cipher
>> product already the the problem and a solution. Adding several AES
>ciphers to an
>> existing single-cipher product is no harder than adding a single
>("the") AES
>> cipher; negotitaion is required. creating a new product is the only
>case in which
>> the requirement to negotiate cipher selection is an issue. Note that
>this is
>> going to be common for reasona of backward compatibility during the
>> changeover/upgrade period.
>>
>> However, there are enough ciphers out there now that I suggest no new
>product will
>> be pure AES. Bruce Schneier indicated that he considered 3DES to be
>the backup
>> for AES. This is probably a reasonable suggestion given the maturity
>of 3DES and
>> the immaturity (*RISK*) of AES. SO even a new product is probably
>going to have
>> to negotiate dynamic cipher selection or support static configuration
>of cipher
>> selection.
>>
>> You cannot just wish this requirement away. Nor can you ignore the
>ubiquity of
>> the issue and claim that multiple AES selections creates an abnormal
>condition.
>> As discussed above it is probably normal to have multiple ciphers.
>>
>> >
>> >
>> > >>I don't understand the "background" bit about cipher negotiating,
>since
>> > >>for all of modems, PPP, and ciphers, until the parties agree, the
>main
>> > >>event cannot work, and that's not exactly "background"
>> > >
>> > >Indeed, you do not understand the term "background," presumably
>> > >because you have not done your homework. I suggest actually reading
>> > >messages before disparaging their ideas. You might also look into my
>> > >recent article in IEEE Computer:
>> > >
>> > > http://www.io.com/~ritter/ARTS/R8INTW1.PDF
>> > >
>> > >or the previous discussion, which I have archived on my pages:
>> > >
>> > > http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM
>> > >
>> > >Here, "background" approximately means "not apparent to the user."
>> > >That is just what modem negotiation is about, although we may hear
>> > >modems, and need not hear or see cipher negotiation.
>> > >
>> > >To start any conversation in cipher, it is currently necessary to
>> > >acquire common keys. Everyone understands this. So everyone should
>> > >be well prepared to understand that we can *also* acquire a cipher
>> > >name, or even a cipher itself, in the same way, through the same
>> > >channel. This is not a big conceptual leap.
>> > >
>> > >Once we have a conversation in cipher, we can assign part of it to a
>> > >"control channel," where negotiation takes place (generally, although
>> > >not necessarily) hidden from the user. That would be "background"
>> > >cipher negotiation.
>> > >
>> > >Because the need is to change ciphers frequently, the desired
>> > >negotiation process is not one-time at the start, but rather, a
>> > >frequent or continuous process in different messages or sessions.
>> >
>> > Before repeating your old line yet again, you should do your own
>homework,
>> > which is to actually investigate at least one real, deployed network
>> > protocol that does the negotiating of the sort that you say is so
>easy.
>> > And by "investigate," I don't mean merely read some user
>documentation or
>> > repeat your dreams of how things would turn out if only people would
>listen
>> > to you.
>> >
>> > As for your "background" stuff--take your own advice and read what you
>> > are responding to before pontificating about homework. No matter on
>what
>> > "ground" the cipher negotiating is done, once the sender decides to
>switch
>> > to another cipher, data must soon stop flowing until the new cipher
>has
>> > been negotiated. You can call the cipher negotiating "background" if
>you
>> > want, but when the user-data stops flowing the notion is ... strained.
>> > When one party decides a new cipher is required, you must fairly soon
>> > either use a new cipher or stop moving data. Otherwise think what a
>bad
>> > guy could do.
>>
>> This is silly. Does Eve live under your bed or in your closet?
>>
>> >
>> >
>> > >>...well, not exactly
>> > >>for PPP, which, for example has the CCP (comopression) which is
>supposed to
>> > >>be negotiated in parallel with the main NCP's, which can start
>sending
>> > >>data before CCP converges. That is what the PPP implementations
>I've
>> > >>worked on do, but plenty of others don't. Again, theory vs.
>practice.
>> > >
>> > >I am a working engineer.
>> > >
>> > >Theory vs. practice.
>> >
>> > Shouldn't a working engineer know about the common, existing, widely
>> > *practiced* examples of the thing he is proposing? SSL is a closer
>example
>> > than modems or PPP. (I picked PPP because I know more about PPP than
>> > SSL.) Do you care to say something about SSL that will convince
>people
>> > that negotiating ciphers is a great idea?
>> >
>> > > ...
>> > >Well, since you are a "real designer," I'll just let you wander on in
>> > >your monomanical tirade, while I suggest that we *not* do things like
>> > >PPP.
>> >
>> > The biggest trouble with PPP is that it is a standardized network
>thing.
>> > Network things that are standards are always at least 95% politics, by
>> > which I mean everything that comes with design by committee and
>approval
>> > by standards committees. Negotiating ciphers such as you have
>proposed
>> > would necessarily be network things. Your repeated appeals to the
>word
>> > "standardized" mean that they would enjoy the attentions of standards
>> > committees.
>> >
>> > > ...
>> > >There is no other possibility, unless you wish to depend upon the
>> > >strength of a cipher which explicitly HAS *no* known or guaranteed
>> > >strength. Not having strength is not a trivial detail, this is the
>> > >essence of the reason for using a cipher.
>> >
>> > Before complaining of my monomanical tirades, you ought to notice a
>few
>> > of your own ...yes, you and others have pointed out with endless
>boring
>> > repetitions, the truth of the premise of that paragraph, that we have
>no
>> > guarantees, measurements, or even definitions of the true, theoretical
>> > strength of any practical cipher. However, as others have tirelessly
>> > responded, your claim that automated switching among lots of ciphers
>is
>> > the only alternative to a falling sky does not follow from that
>premise.
>>
>> Then pray tell us, what does follow? Your silince is quite loud.
>>
>> >
>> >
>> > >The ability to change ciphers offers each of us the power to choose
>> > >what cipher we want to use. This means no government organization is
>> > >edicting our use, or forcing it through market pressure. We get to
>> > >choose what to use, and what not to use, and to change our minds on a
>> > >daily basis. That is not a trivial advantage.
>> >
>> > Yes, it's good to be able to change ciphers. That does not imply
>anything
>> > one way or another about computers negotiating ciphers in real time.
>>
>> While true I see no problem to real-time cipher negotiation. Sure you
>can mangle
>> the job, but you can also do a good job, in which case it becomes a
>non-issue.
>>
>> > >>Other good (i.e. bad) examples of the inevitable perils of
>negotiating
>> > >>besides modems and PPP include TCP and HTTP. Most don't know about
>> > >>about MSS/PMTU or window size problems, but most people have seen
>> > >>"broken" web pages that don't work on some versons of some browsers.
>> > >
>> > >Gosh, I think we'll just have to have a complete specification.
>> >
>> > The equivalent failure mode of negotiated ciphers for a broken web
>page
>> > would be picking ROT26 as the cipher right after ROT13. Or one of
>> > the SSL security bugs.
>> >
>> > The world is full of self-described architects, designers, and
>inventors.
>> > Most are frauds who invent only self-delusions, hot air, snake oil,
>and
>> > promises to finally build a perptual motion machine that will work
>this
>> > time, (and help patent attourneys make the payments on their
>Mercedes.)
>> > The real architects, designers, and inventors not only desgin and
>invent,
>> > but also build real implementations that are useful in real life. So
>when
>> > will we see the implementation of negotiated/varying ciphers that you
>are
>> > building?
>> >
>> > Vernon Schryver [EMAIL PROTECTED]
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 18:38:18 +0200
Subject: Re: Biometric Keys are Possible
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Lincoln Yeoh wrote:
>>
>> On Mon, 18 Oct 1999 09:00:42 -0700, Peter Pearson
><[EMAIL PROTECTED]>
>> wrote:
>>
>> >When the user presents himself for verification, the verifier
>> >sends (over an unsecured line) the error-correction information
>> >and a challenge for a proof-of-knowledge-of-a-discrete-log
>> >protocol that the user should be able to answer
>> >with the help of his biometric. The biometric
>> >reader receives this information, reads the user's hand geometry
>> >or iris patterns or whatever, and completes the
>> >proof of knowledge. Secret information never appears outside
>>
>> Actually "Hints" are not necessary for the IriScan system. "Hints" are
>> usually necessary for other systems like fingerprints.
>>
>> Fingerprint recognition systems usually need a hint to find the relevant
>> biometric data, then they check to see if the biometric data matches.
You're addressing a different problem. The problem you're addressing
is, "Here's a biometric reading; does it match anybody in your
database?"
The problem we were discussing is, "Here's Joe Blow's biometric reading;
extract his private key from it." We can do that, given error-correcting
hints.
In principle, you could build a system of which one could ask, "Here's
a biometric reading; find the owner in your database and extract his
private key from the reading." This is just a combination of the two
problems. The find-the-owner problem has been energetically
studied by the biometrics industry, while the extract-his-key problem
is relatively new territory.
- Peter
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 18:31:57 +0200
Subject: Re: Some humble thoughts on block chaining
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
[EMAIL PROTECTED] wrote:
>> Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
>> : But the whitening e.g. in DESX is supposed to add some security, I
>> : suppose. Is there any clear ground that DES shouldn't be combined
>> : with a stream encipherment, excepting the belief
>>
>> which, of course, is now known to be false
>>
>> : that DES alone is
>> : unbreakable and hence self-sufficient?
>>
>> No.
>>
>> The reason why it is currently being sought to replace DES with a better
>> block cipher, again intended to be used alone, rather than merely being
>> advocated to combine DES with some relatively trivial stream
>encipherment
>>
>> are very difficult to justify
>>
>> but what I believed to be those reasons were mentioned in a post of mine
>> some time ago. Basically, because a block cipher is a nice,
>self-contained
>> black box (except for the key, it is _stateless_) it is felt to pose
>fewer
>> problems to designers.
Is this property, statelessness, actually part of the definition of a block
cipher, or simply the case in most modern ciphers? It appears to me that
the
"blockiness" of a cipher is based on the internal data paths, which are
<blocksize> wide, rather than the internal state.
>>
>>
>> Output feedback and counter mode are assumed to produce satisfactory
>> stream ciphers for anyone who wants one from a block cipher.
>>
>> My earlier post stating the rationale which I believed operating here
>> received a reply which noted that BEAR and LION illustrated that stream
>> ciphers were more useful than this rationale admitted. (Perhaps this
>will
>> help you find it on DejaNews.)
>>
>> It might also be noted that the statelessness of a block cipher means
>that
>> its key size is genuinely bounded; a stream cipher might have a short
>key,
>> but a large internal state, and admit of being used in a nonstandard way
>> that would increase the key size to that of the internal state.
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 18:25:38 +0200
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
[EMAIL PROTECTED] wrote:
>> In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>> > On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$[EMAIL PROTECTED]>, in
>> > sci.crypt [EMAIL PROTECTED] wrote:
>> >
>> >>[...]
>> >>Observe that in my discussion above, the choosing of the cipher
>> >>depends on they key. It is not done randomly which would requiere us
>> >>to add information to the ciphertext about which cipher has been
>> >>used.
>> >
>> > Something seems wrong with this observation: Keys we use for actual
>> > data encryption generally are *message keys*, and in fact *should* be
>> > random values. Using a random message key value to select a cipher
>> > sounds rather similar to using a random value to select a cipher.
>>
>> Well, I meant this: If you choose ciphers from the pool in a way that
>> depends on the key then, by definition, the attacker will not know a
>> priori which cipher is being used for each block. If you choose the
>> ciphers by any other method then, by definition, the attacker will
>> always know which cipher is being used: the attacker can know
>> everything except the key.
>>
>> Now if the attacker *does* know which cipher has been used for each
>> ciphertext block, then he can attack the ciphertext encrypted by the
>> weakest cipher. Consider this: even though we in the public don't know
>> the lower bound of security of the individual ciphers we must assume
>> that a powerful attacker does know. We also can assume that these lower
>> bounds vary a lot - it would be strange indeed if different ciphers
>> were very similar in their lower bound of security. So in a pool of
>> four ciphers it is quite probable that one (the "lemon") is orders of
>> magnitude weaker than the others and that the attacker knows this. Let
>> us assume the lemon falls to a known plaintext attack that requires a
>> small number of known plaintexts. It is true that the attacker will now
>> have to collect four times more data for the lemon, but this quantity
>> will be a trifle compared to the plaintext that must be known for
>> attacking any of the other three ciphers. Therefore the attacker will
>> easily break 25% of the communications recovering almost all
>> intelligence. Instead of using this method, we would be better off
>> choosing one cipher by chance sticking to it.
>>
>> The situation is very different is the choice of ciphers is unknown to
>> the attacker, and for that it is necessary that the choice of the
>> ciphers depend on the key. (There is curious exception: to encrypt the
>> next block choose the cipher completely at random and send only the
>> resulting ciphertext. To decrypt, try in sequence the various ciphers
>> until you get intelligible plaintext.)
It appears to me to be extremely difficult to define "intelligible
plaintext". If the plaintext space is so well defined that it is the
difference between plaintext and noise is detectable than an inadequate
compression has been used.
And if I'm sening noise, e.g., a message key, it is impossible by
definition.
>>
>>
>> > We certainly would hope that any attacker could not distinguish
>> > between ciphertexts produced by one cipher and another. One might
>> > even think that an ability to identify a particular cipher from its
>> > ciphertext alone would be a straightforward indication of cipher
>> > weakness.
>>
>> I agree.
>>
>> > Obviously an attacker could try all ciphertexts under the weakest
>> > cipher first, but if the attack requires messages from only a
>> > particular cipher, how would the attacker know which messages to use?
>> >
>> > When the cipher itself is changed dynamically on a message-by-message
>> > basis, there should be no way to distinguish the subset of ciphertexts
>> > produced by a particular cipher. It would thus seem to be hard for an
>> > attacker to even collect the required amount of single-cipher
>> > ciphertext, let alone start any actual attack.
>>
>> When the cipher choice is changed dynamically in a way that the
>> attacker cannot predict, then we do get some very interesting
>> properties even if the pool contains only two or three ciphers: It
>> seems a ciphertext only attack on the weak cipher will not work,
>> because the attacker will not know which ciphertext blocks belong to
>> it. Known or chosen plaintext attacks will apparently not work either
>> and for the same reason: even if the attacker chooses the entire
>> plaintext stream, he cannot collect and analyze the ciphertext blocks
>> that have been encrypted with the lemon. It does appear that mixing
>> ciphers can be very useful, but only if the attacker cannot predict
>> their sequence.
>>
>> How does one achieve this? Using a few bits of the key to index one in
>> a pool of N ciphers is not the best way, because then all blocks will
>> be encrypted with the same cipher. The attacker applies the lemon-
>> attack and with 1/N probability it will work. Using the key to start a
>> PRN sequence is not the best solution either: If the key is reused then
>> the first block will always be encrypted with the same cipher. I think
>> the best solution is to use an IV as well as the key to start a PRN
>> sequence. One possibility:
>>
>> Pool N ciphers.
>> Define random IV and add it to the ciphertext.
>> T(0) = IV
>> H(0) = Key
>>
>> To encrypt the i-the block T(i):
>>
>> H(i) = Hash( H(i-1) xor T(i-1) )
>> index(i) = H(i) mod N
>> C(i) = encrypt( index(i) ) ( T(i), Key )
>>
>> Here is another possibility. Let us assume we trust four of the AES
>> finalists (which use 128 bit blocks).
>>
>> index = least significant 2 bits of key
>> H = IV
>>
>> Step A: H = encrypt( index ) ( H, Key)
>> Step B: Use 63 groups of 2 bits of H to index a cipher and encrypt the
>> first 63 blocks of plaintext.
>> Step C: index = last 2 bits of H
>> Step D: go to Step A
>>
>> The ciphertext increases in one block and speed decreases about 2%
>>
>> One more thought. Mixing ciphers in a secret sequence seems to be
>> useful even if only two ciphers are used. What about using only one
>> cipher while changing the direction of the encryption, i.e. use it
>> sometimes to encrypt and sometimes to decrypt depending on the secret
>> sequence?
>>
>> Sent via Deja.com http://www.deja.com/
>> Before you buy.
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 22:00:45 +0200
Subject: Re: How to use CBC w/ RC4?
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
On Mon, 25 Oct 1999 11:43:41 GMT, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] wrote:
>>>
>>> As I understand it, using RC4 without an IV or feedback to encrypt
>>> multiple messages with the same key makes a known plaintext attack
>>> trivial, as you just xor the known plaintext with the ciphertext to
>>> recover the key stream.
>>>
>>> My question is, wouldn't using CBC mode with only one byte of
>>> feedback, even with a long IV, also be extremely easy to break, as
>>> there would be a 1/128 chance of identical key streams?
>>>
>>> If this is true, can RC4 be used, assuming a psuedo-random IV, with
>>> some CBC mode that wouldn't be vulnerable to a known plaintext attack?
>>>
>>
>>I don't know where you are going with this, your question is moot. You
>>never use the same key twice for any message, no matter what cipher you
>>use.
Trying to figure out how to use RC4 to encrypt multiple files, as on a
directory of a hard drive, with a single password. If you mean use a
different public IV to xor with the password to create the key to
initialize RC4, then I understand. If you mean a different password
for each file, then it would be a mess. The separate passwords would
have to be stored together in a file, then encrypted with a human
rememberable password.
>>
>>CBC mode is only used replay attacks harder where the same key (but
>>different initial IV) are used.
This goes along with my question. If you were running a block cipher
with, say, a 64bit block size, I can see how a 1 block feedback would
greatly reduce this attack. But a 1 byte feedback would seem to be
terribly weak.
If I was roundabout with the question, I apologize. The goal is to
find an implementation of RC4 (or any other stream cipher, for that
matter), that can be used to encrypt many files with a single
password, that will be strong against a known plaintext attack.
Why? Purely for the experience and knowledge itself. I find all of
this very interesting.
>>
>>Tom
>>
>>
>>Sent via Deja.com http://www.deja.com/
>>Before you buy.
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 18:37:49 +0200
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Crossposted-To: talk.politics.crypto
[EMAIL PROTECTED] wrote:
>> They are looking for
>> encryption that is many times more secure than anything they can crack
>> themselves, so not being able to crack a code is not sufficient to prove
>> it is adequately secure.
Interesting and very succinct statement. It probably applies to
organizations
as well as individuals. The inequality re ability and desires reminds of
eyes
bigger than stomach, and all the important projects that have failed due to
lack of unobtainium.
Perhaps this is the reason that crypto is so fertile in regards to
charlatans. People buy the promises.
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
Date: Mon, 25 Oct 1999 01:22:16 +0200
Subject: Re: Bernstein and letting the court write (or rewrite) laws
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Crossposted-To: talk.politics.crypto
In <[EMAIL PROTECTED]> "Trevor Jackson, III" <[EMAIL PROTECTED]>
writes:
>>And the Supremes have already rules that any infringement of a
>consitutionally
>>protected right is unacceptable. Thanks for the hint.
They have never said anything of the sort. Infringements of protected
rights occur all the time, but they have to occur in very limited
situations and have due safeguard. Loads of laws (treason, libel,
slander,...) violate Freedom of speech. And they have been upheld by the
courts. If fact the various rights in teh constitution are often in
conflict with each other, and one or the other must be violated.
{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{}
{}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}
------------------------------
** 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
******************************
