Cryptography-Digest Digest #616, Volume #9 Sat, 29 May 99 06:13:05 EDT
Contents:
Re: being burnt by the NSA (David A Molnar)
Re: evaluation cryptographic algorithms (Johnny Bravo)
Re: The BRUCE SCHNEIER Tirade (John Kennedy)
Re: DSA (Digital Signature Standard) and the Schnorr Patents (Jerry Coffin)
Re: Review of Scottu19 (Aidan Skinner)
Re: DSA (Digital Signature Standard) and the Schnorr Patents ("Roger Schlafly")
Re: OTP Problems (Nicol So)
Re: The BRUCE SCHNEIER Tirade ([EMAIL PROTECTED])
The paradox of secure key distribution channel (Nicol So)
Re: The BRUCE SCHNEIER Tirade (John Savard)
Re: alt.timestamp (Igor)
Re: Review of Scottu19 (Thomas Pornin)
Re: Review of Scottu19 (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: 29 May 1999 04:23:10 GMT
Steve Sampson <[EMAIL PROTECTED]> wrote:
> This group is not designed for politics, keep moving...
> [EMAIL PROTECTED] wrote
>>Who has actually been burnt by the NSA? As far as I know they are so
>>secretive they don't exist.
indeed, talk.politics.crypto exists for that purpose.
followups have been set.
-David
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: evaluation cryptographic algorithms
Date: Sat, 29 May 1999 00:42:44 GMT
On Fri, 28 May 1999 14:16:26 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>> There is no "strong" crypto that can be made weak by describing the
>>algorithm or showing the source code. If there is a flaw that can be
>>found by examining the source, it was never strong to begin with
>>(mainly because that flaw could be found by accident by an attacker).
>
> Actually the above is not ture. SInce the NSA which is some one compedent
>in the field does the best to hide there source code. Yes people like to see
>it when it is being studied but ideally it is best to hide it. No one in
>public knows the many methods they code ther CYPRIS chips with. I also
>think if we told the japanese in WWII that navajo was being used for crypto in
>the war they may have been able to break it. But we counted on the irragance
>of the Japanese to only let a few people even look at the code. Where if they
>would have broadcast some openly to there puplic it would have been broken.
Just how does your paragraph relate in any way that releasing the
source code wouldn't weaken "strong" crypto? Your NSA rant
notwithstanding, so what they hide their code. I didn't say anything
about hidden code can't be strong.. And your statements about the
Navajo only proves my point, it was weak encryption and had the
Japanese managed to learn it they could have easily understood the
messages.
> Actually they keep changing this target number it seems SUNS burn
>up faster than people think so they keep moving the numbers up each year
>so it is hardly overkill.
How is it any less overkill if the time limit is SHORTER than
expected?
>>at the systems we are using. The longer the algorithms can withstand
>>attack the more secure they are believed to be, not a guarantee, but
>>there are no guarantees with crypto.
>>
>> Johnny Bravo
>>
>
> I can guarntee that the NSA can break ROT13
>so ther are some guarntees.
I was talking about a guarantee about the SECURITY of a system, not
the WEAKNESS. Before you start saying my statements are untrue, try
reading them first. Every statement you made in your post made a
wrong assumption about what I had written.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (John Kennedy)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Reply-To: [EMAIL PROTECTED]
Date: Fri, 28 May 1999 11:14:48 GMT
On Thu, 27 May 1999 22:49:34 -0400, "Brian Hetrick"
<[EMAIL PROTECTED]> wrote:
>Well, I'm not Bruce Schneier, but OTP systems are unusable in practice
>because the key size must be the same as the message size -- otherwise
>it's not an OTP -- and distributing the key requires a secure channel.
>Since you can securely distribute the key, it makes sense to use the
>same channel to securely distribute the message, and not bother with a
>key. (Actually, there is a time dependency in there. It is possible
>that the secure channel existed in the past, but not right at the
>moment; in that case, and in that case _alone_, it makes sense to use
>an OTP.)
>
Which is why one time pads have been, and presumably still are used.
Which is why I was puzzled by the comment attributed to Schneier that
they are unusable.
Yes, I understand that they are no replacement for public key
cryptography, but in the right situation they are possibly superior if
provably secure.
--
John Kennedy
--
The causal world imposes a nonarbitrary distinction between detecting in one's visual
array
the faint outline of a partly camouflaged stalking predator and not detecting it
because of
alternative interpretative procedures. Nonpropagating designs are removed from the
population, whether they believe in naive realism or that everything is an arbitrary
social
construction.
(Tooby and Cosmides, in _The Adapted Mind_, Barkow,
Cosmides and Tooby, editors )
=======
Best Anarchy Links:
David Friedman -> http://www.best.com/~ddfr/
Niels Buhl -> http://www.math.ku.dk/~buhl/
Billy Beck -> http://www.mindspring.com/~wjb3/promise.html
========
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Crossposted-To: talk.politics.crypto
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Fri, 28 May 1999 12:21:45 -0600
In article <7ik47j$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> It is axiomatic in patent law that a patent claim is an expression
> of what the inventor regards as his invention, and that the scope
> of the patent is limited to what is actually claimed in the claims.
This is NOT entirely true -- at least under U.S. law, the scope of the
patent is limited to what is actually claimed OR "reasonable
equivalents thereof." In a "means plus function" claim (usually
distinguished by the wording "means for <whatever>", though at times
the courts get involved in deciding this) the scope of an element is
limited not simply to what is recited in the claim itself, but to what
is discussed in the patent disclosure (again, "or reasonable
equivalents thereof"). This can cut both ways: if a particular claim
says "means for X" without suggesting a particular means, but the
patent disclosure DOES suggest those means, the patent may well still
cover that means.
Also note that since the Markman case, "claim construction" has been
deemed a matter of law rather than fact. This basically means that in
a means plus function claim, the judge in the case gets a chance to
decide what things are reasonable equivalents, and will/would be
considered reasonable equivalents of what is recited in the claim.
Then, after the judge has done this, the jury gets to decide roughly
the same thing again. It can happen (and has) that the judge rules
something as not being a reasonable equivalent as a matter of law, but
the jury turns around and decides that it IS a reasonable equivalent
as a matter of fact...
The patent prosecution history can have an effect here as well: for
example, if a claim was originally written to suggest a particular
thing, and is rewritten to quit mentioning it because of prior art
noted by the patent examiner, then there's what the courts call
"Estoppel", which basically means the patent holder can't turn around
and try to claim that this area is covered as a reasonable equivalent,
even if it might otherwise be considered a reasonable equivalent to
what is recited.
I don't recall whether I've pointed it out here before or not, but a
couple of years ago, Judge Rader (which sits on the Court of Appeals
for the Federal Circuit, which works exclusively with patent cases)
did a study of patent cases. He found that THE MAJORITY of decisions
in patent cases were reversed on appeal, to at least some degree.
That means that over half the time that lower court judges make
decisions about patent law, they're wrong, at least according to the
higher courts in the country. We can hope that the average judge
knows more about patent law than I do, meaning there's a better than
even chance that all of what I've said above (no insult intended, but
also what Roger Schlafly says) is wrong. There are quite a few patent
specialists who quite openly state that a number of U.S. Supreme Court
decisions have been completely wrong as well.
That should be taken as a warning. My word (much like Roger
Schlafly's) should NOT be taken as the final word. In any legal
matter, you should only trust an attorney, and in anything related to
patent law, you might not want to trust even an attorney too much...
------------------------------
From: [EMAIL PROTECTED] (Aidan Skinner)
Subject: Re: Review of Scottu19
Date: 27 May 1999 21:58:03 GMT
Reply-To: [EMAIL PROTECTED]
On 27 May 1999 09:27:29 GMT, Thomas Pornin <[EMAIL PROTECTED]> wrote:
>The only excuse for doing so is that in some cases you may gain some
>speed of execution, but this is rare on modern architectures (using a
In which case it's almost always better to use inline asm anyway. ;)
>However, the fact that your are proud of such coding is funny.
Especially to an Ada programmer. ;)
- Aidan (strange, strange C people...)
--
http://www.skinner.demon.co.uk/aidan/
Real men whistle ed commands at 300 baud into a can.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Fri, 28 May 1999 22:39:05 -0700
Jerry Coffin wrote in message ...
> [discussion of equivalents in patent law and fallibility of the courts
snipped]
>That should be taken as a warning. My word (much like Roger
>Schlafly's) should NOT be taken as the final word. In any legal
>matter, you should only trust an attorney, and in anything related to
>patent law, you might not want to trust even an attorney too much...
On the subject of the DSA-related patents, there is no need to trust
me or anyone else. The matter has been litigated. In court, the owners
of the Diffie-Hellman and Hellman-Merkle patents put forth an argument
as to how those patents cover all digital signatures. Neither side was
able to win on summary judgment. The patents expired. Meanwhile, the
owners of the Schnorr patent conceded that it does not apply to the DSA,
and never even put forth an argument of how the Schnorr patent might
cover the DSA. It is a dead issue, and there is no reason to speculate.
McLellan started this with a theory that the RSA and Schnorr patents
somehow inhibited GAK. The theory makes no sense to me. The
Schnorr patent had no impact on DSA. Even if it did, the GAK issue
involves encryption keys, not signature keys.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: OTP Problems
Date: Sat, 29 May 1999 01:41:31 -0400
DJohn37050 wrote:
>
> OTP is provably secure. Why is it not used everywhere?
> It has some problems in practice:
> 1. Key length = message length, this is impractical in most applications.
On the other hand, there are uses for which one-time pad is well-suited.
> 2. What do you do if you run out of key? Choke!
Wait for the next shipment of key material, or switch to another cipher,
or reuse portions of the key material in some way (and sacrifice
unconditional secrecy in the process, if acceptable).
> 3. Key must be totally random, this is non-trivial to accomplish.
Actually, generating sufficiently random key material is quite easy. It
may be a challenge if you need to generate *a lot* of truly random bits
*fast*.
> 4. Two-time pad should be considered insecure, any reuse can be fatal to
> security.
Basically you lose the guarantee of unconditional secrecy. The
practical impact may range from almost nothing to complete loss of
security, depending on the situation.
> 5. Synchronization between sender and receiver is critical, if a little as one
> bit is dropped, you lose everything.
This problem can be solved quite easily. (Re)synchronization can be
achieved by transmitting in the clear the offset of key bits in the
one-time pad.
Nicol
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Sat, 29 May 1999 03:08:10 GMT
What does 'EARENISECYRE'?
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: The paradox of secure key distribution channel
Date: Sat, 29 May 1999 02:06:56 -0400
Ruud de Rooij wrote:
>
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>
> ... if you use a OTP to
> > transmit the key, you first need to transmit the key for *that*, etc.
> > (a never-ending cycle), or if you use some other system to secure the
> > key, why not use that system instead of the OTP for the actual
> > transaction?
>
> An OTP can be useful if there is a temporal distance between the
> transmission of the key and of the data. E.g., a bank gives you the
> OTP key in person when you open an account, and you use (part of) that
> key when you later submit a transaction electronically.
It is a paradox that beginners may find puzzling--if you have a secure
key distribution channel, why bother with encryption at all? To make
sense of it, one has to understand that a "secure key distribution
channel" may mean meeting in person or sending a trusted courier. Such
a channel may:
- be expensive
- have a low bandwidth
- have a high latency
- not be available the moment secure communication is desired
Nicol
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Fri, 28 May 1999 21:03:38 GMT
[EMAIL PROTECTED] (John Kennedy) wrote, in part:
>I don't see anything wrong with asking why a true one time pad is
>supposed to be unusable.
The point is, though, his invention makes it "usable" by allowing a
short key to encipher a lot of text. He may have a very secure stream
cipher, but in general calling a stream cipher a "one-time pad" is a
mark of snake oil, in the same way that hiding from the sun or not
being visible in a mirror are the marks of a vampire.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
Date: Fri, 28 May 1999 16:44:53 -0500
From: [EMAIL PROTECTED] (Igor)
Crossposted-To: alt.config
Subject: Re: alt.timestamp
Reply-To: [EMAIL PROTECTED]
1) It should be moderated, with sigs by moderation bot serving as TTP
2) something like this already exists. Search for predictions registry.
igor
Brian Queen <[EMAIL PROTECTED]> wrote:
*
* alt.timestamp free, online Trusted Third Party for electronic media.
*
* Charter:
*
* Posting of nothing more than minimally sized digital signatures of
* electronically
* published information for the purposes of time stamping.
*
* Justification:
*
* In an effort to produce a free, fully automated and online
* Trusted Third Party (TTP) I propose the creation of
* a new newsgroup alt.timestamp under the assumption that
* the distribution system of Usenet provides in itself a TTP.
*
* The newsgroup would provide a timestamp in the following manner:
* a user would send a digital signature of the electronic document to the
* newsgroup.
* The digital signature gets propagated throughout Usenet and archived and
* indexed
* according to the extent of the current and future search engine
* capabilities.
* Future claims regarding the date of a document may be resolved by
* finding the digital signature in one of the archives.
*
* Existing newsgroups such as alt.anonymous could be used for such
* purposes
* but the creation of a new group for this specific purpose would be
* beneficial.
*
* Proponent:
*
* Brian Queen
* [EMAIL PROTECTED]
--
============================================================================
char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
\=/, _-===-_-====-_-===-_-==========-_-====-_
| @___oo ( )_
/\ /\ / (___,,,}_--= )
) /^\) ^\/ _) =__ Anything is good and useful if )
) /^\/ _) (_ )
) _ / / _) ( it's made of chocolate. )
/\ )/\/ || | )_) (_ )
< > |(,,) )__) ( http://www.algebra.com/~ichudov )
|| / \)___)\ (_ _)
| \____( )___) )___ -==-_____-=====-_____-=====-___==
\______(_______;;; __;;;
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Review of Scottu19
Date: 29 May 1999 09:21:46 GMT
According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
> However I doubt it will run very fast since the design was counting on
> the indianess of the PC.
Alpha and PowerPC can make each memory access with both endianness.
It is just a matter of setting a bit in the opcode. As for Sun
sparcstations, the endianness is based on a per-page basis, which means
that it is possible also to access data like a PC does (but it requires
some fiddling with the OS, since the kernel only is responsible for the
MMU). PC do memory access only little-endian, but (since the 486) have
the bswap opcode, that reverses a 32-bit words in a cycle (or less).
680x0 have a similar trick.
Therefore, endianness may be handled at low or no cost, whether it
is big or little endian. In most cases, it is done by the compiler;
either directly or via the htonl()/ntohl() macros. Moreover, when doing
essentially pseudo-random access in a large table, a vast majority
of memory acess will be cache misses, which means that any 'reverse
endianness' calculation is neglectable.
To sum up, the endianness is a non-issue as far as speed is concerned
(for block ciphers, on modern and not-so-modern computers).
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Review of Scottu19
Date: Sat, 29 May 1999 10:49:29 GMT
In article <7iobja$llt$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Thomas Pornin) wrote:
>According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
>> However I doubt it will run very fast since the design was counting on
>> the indianess of the PC.
>
>Alpha and PowerPC can make each memory access with both endianness.
>It is just a matter of setting a bit in the opcode. As for Sun
>sparcstations, the endianness is based on a per-page basis, which means
>that it is possible also to access data like a PC does (but it requires
>some fiddling with the OS, since the kernel only is responsible for the
>MMU). PC do memory access only little-endian, but (since the 486) have
>the bswap opcode, that reverses a 32-bit words in a cycle (or less).
>680x0 have a similar trick.
>
>Therefore, endianness may be handled at low or no cost, whether it
>is big or little endian. In most cases, it is done by the compiler;
>either directly or via the htonl()/ntohl() macros. Moreover, when doing
>essentially pseudo-random access in a large table, a vast majority
>of memory acess will be cache misses, which means that any 'reverse
>endianness' calculation is neglectable.
>
>To sum up, the endianness is a non-issue as far as speed is concerned
>(for block ciphers, on modern and not-so-modern computers).
>
> --Thomas Pornin
When I had access to a SUN it took quit awhile to mode the C code
to get scott16 to work. If I ever get access again to a SUN with a GNU C
compiler how does one set the option bits to make it act like a PC?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
