Re: David Kahn's Codebreakers

[Greg Broiles]

On Mon, Feb 05, 2001 at 08:28:04AM -0600, Zach wrote:
> 
> I'm trying to find a copy of The Codebreakers, by David Kahn.  Does
> anyone know where I can find a copy that costs less than the $52
> Amazon sells it for, or is that pretty much average for the book?

A search on <http://www.bibliofind.com> finds ~ 50 copies in varying
degrees of quality and age between $6 and $75 USD. 

--
Greg Broiles [EMAIL PROTECTED]
PO Box 897
Oakland CA 94604

Re: PGP: n degrees of separation

[Greg Broiles]

On Thu, Dec 21, 2000 at 08:39:50AM -0800, Kris Kennaway wrote:
> Does anyone have any statistics on the average degree of separation
> between two arbitrary PGP keys in, say, the pgp.mit.edu keyserver - in
> other words, the average diameter of the PGP web of trust?

These URLs describing work done at AT&T/Bell Labs may be of interest,
though the results are somewhat dated -

http://www.inet-one.com/cypherpunks/dir.1996.02.01-1996.02.07/msg00313.html
http://bcn.boulder.co.us/~neal/pgpstat/

--
Greg Broiles [EMAIL PROTECTED]
PO Box 897
Oakland CA 94604

Re: Non-Repudiation in the Digital Environment

[Greg Broiles]

At 09:08 AM 10/11/00 -0400, Arnold G. Reinhold wrote:

>My concern is that the vast majority of informed lay people, lawyers, 
>judges, legislators, etc. will hear "non-repudiation" and hear "absolute 
>proof."  If you doubt this, read the breathless articles written recently 
>about the new U.S. Electronic Signatures Act.

I think it would be more sensible to worry that lawyers and judges will 
hear "non-repudiation" and stop paying attention to anything else the 
speaker has to say about law or evidence, as the concept of 
"non-repudiation" as discussed by technologists is fundamentally 
incompatible with the rules of civil & criminal procedure, the 
Constitution, and the rules of evidence, at least in the United States.

If it were possible to reduce questions about facts to the results of math 
problems, we wouldn't need courts at all. That suggests two things to me - 
(a) that's a very, very difficult problem to solve, and we certainly won't 
solve it by handwaving away important questions like security of keying 
material, and (b) even if it were solved, it's very likely the established 
legal system would declare it unsolved in order to protect its continued 
existence.

--
Greg Broiles
[EMAIL PROTECTED]

Re: NSA back doors in encryption products

[Greg Broiles]

At 05:39 AM 5/27/00, Steven M. Bellovin wrote:
>That's tricky, too, since the Constitution provides the *defense* with
>a guarantee of open trials.  At most, there are laws to prevent
>"greymail", where the defense threatens to reveal something sensitive.
>In that case, the judge reviews its relevance to the case.  If it is
>relevant -- and a back door used to gather evidence certainly would be
>-- the prosecution can either agree to have it revelated or drop the
>case.

The Cyberspace Electronic Security Act - at least the version proposed in 
September 1999 - didn't limit its effect to criminal trials. In particular, 
the proposed section 18 USC 2716(a) of the Act would allow the US 
government to file a request with the judge for a protective order 
prohibiting disclosure - even in civil cases, even where the government 
isn't a party to the litigation. Further, the court can prohibit disclosure 
of trade secrets held by private parties disclosed to the government - 
like, for example, an unknown vulnerability or back door which allowed 
decryption or other security failure.

The text of the 9/1999 version is available online at 
 

Re: Java Crypto Library Licenses

[Greg Broiles]

At 03:02 PM 5/1/00, Mark A. Herschberg wrote:

>The only thing I find harder than crypto is trying to understand
>software licenses and export laws.
>
>I am building a commercial product. Sun's JCE (as well as JAAS and JSSE)
>all have non-commercial licenses, which I understand to mean as: I can't
>use them in a commercial product.
>
>http://java.sun.com/products/jce/jce12_providers.html lists companies
>providing crypto services and clean room implementations.
>
>1. Am I correct that a clean room implementation, such as one at
>http://www.openjce.org/ can be used in place of Sun's JCE?  Such that I
>could interchange the two modules and my code written to the JCE API
>will work in either case (modulo bugs).
>
>2. Just as important, am I understanding their public license
>(http://www.openjce.org/licence/PUBLIC_LICENCE) correctly to mean that I
>can freely use their software in our product?

I haven't read their license; but they're probably giving you a license to 
use their copyrighted code, but not a patent license for other people's 
(e.g., RSA or Certicom) patents. You should consider patents and copyrights 
separately when trying to figure out licensing. The RSA patent is still in 
force until Sep 20 of this year.

>3. Being that we are a US company (we write code in the US), and this
>(the clean room JCE) was done in Australia, and we're marking in Asia,
>how can we figure out what export laws are applicable?  (We have
>lawyers, but its always cheaper to do some initial leg work.)

US software export control law governs the transfer of software or 
information about software from US persons to non-US persons, and the 
subsequent transfer and use of that software/information. If your 
development or production environment depends on that activity - e.g., a US 
person transfers code or knowledge about code to a non-US person; and that 
code provides information-hiding functionality, then you probably need to 
think about export control. The export control regime became less onerous 
recently, but hasn't withered away entirely.

Also, Australia has historically had some funny rules about crypto export, 
depending on whether or not the information leaves Australia over a wire 
(not regulated) or on disk (regulated). You may need to consider the import 
and export restrictions of every country you're touching, not just the U.S.

I've redirected this to [EMAIL PROTECTED], as it's not about writing code.

Re: legal status of RC4?

[Greg Broiles]

At 10:45 AM 1/25/00 , Eric Murray wrote:
>Real-To:  Eric Murray <[EMAIL PROTECTED]>
>
>
>Does anyone know the legal status of RC4 in the US?
>
>I know that a cipher purporting to be RC4 was published on
>Cypherpunks by Anonymous, and that various crypto packages
>have RC4 or "EC4".  My question is, has RSA taken anyone to
>court in the US for using RC4 without buying a license from RSA?

I haven't heard of such a case.

I see four possible approaches by which RSA could hold an interest in the 
IP around RC4 - patent, trade secret, copyright, and trademark. With 
respect to RC4, I believe the following -

1.  No known patent covers RC4; so there is apparently no patent problem.
2.  RSA used to say that the RC4 algorithm was a trade secret - but 
it's been published in a book (see Applied Crypto) and so widely publicized 
by now that not even the DVD people would say that it's still a trade 
secret. So I think there's no trade secret problem.
3.  If you don't have an author who's willing to take credit for 
writing code, it's possible that the copyright in the code you're seeing 
hasn't been licensed to you, so there's a potential copyright problem. 
Safest course of action would be to reimplement RC4 from the published 
descriptions of its workings, e.g., Applied Crypto.
4.  RSA likely has a valid trademark in the term "RC4", so it's safest 
to be careful about using the term so that you're not creating confusion in 
the minds of consumers about whether or not you're providing them with 
something created by RSA or yourself or some third party. Some people and 
organizations have used the term ARC-four to describe an algorithm that 
interoperates with RSA's RC4; I don't think it matters much what you call 
it, so long as you're not creating confusion about who wrote the code and 
the algorithm, or otherwise clobbering someone else's trademark.


--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Re: Killer PKI Applications

[Greg Broiles]

At 05:00 PM 1/11/00 , [EMAIL PROTECTED] wrote:
>For the CA-based trust infrastructure to work for this scenerio ... the CA 
>needs
>to be asserting the trust/quality/integrity of applications produced by each
>software company (so that I only need to record CA-level trust decisions) ...
>once I need to record vendor-level trust decisions then I've truncated any 
>trust
>hierachy (embodied by a CA which then becomes superfulous/redundant).

While this would certainly be an interesting goal to achieve, I think it's 
worth remembering that current software industry practice is for the 
software publishers themselves to disclaim all or almost all warranties 
regarding the performance of their software or its lack of errors .. so 
you're asking CA's to guarantee something that publishers themselves don't, 
at present.

Further, CA's (well, the cautious ones) carefully limit their liability to 
third parties who rely on their statements - the customer of a CA is likely 
to be different from the end user who wants or needs to rely on the CA's 
assertion.

The above model would change both of the above practices - putting the CA 
on the hook to the end user, and making a positive warranty about one or 
more aspects of the software's performance.

At present, the risk ( = cost) of software failure rests on the 
purchaser/licensee, who's frequently unable to measure or calculate or 
otherwise account for it, so it's mostly ignored. Shifting that cost to the 
publisher/licensor or a CA or their insurers means that the cost will be 
measured and calculated and not ignored. Because end users mostly don't 
account for that cost, they're not likely to assign a high value to a 
transaction which shifts that cost to another party; but the party to whom 
the cost is shifted will want to value the transaction at its cost, or 
higher, because the cost can't and won't be ignored. The difference in 
apparent value of that cost-shifting transaction makes it unattractive to 
one or the other of its participants.

Thus, while the scenario you describe is an attractive one (especially if 
I've got my end-user hat on), I suspect that it's unlikely to see the light 
of day any time soon.


--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Re: Thawte "SuperCerts"

[Greg Broiles]

On Wed, Dec 01, 1999 at 02:36:46PM -0500, Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>, "Marcus Leech" writes:
> > The Thawte folks are busily promoting their "SuperCerts" which enable
> > 128-bit
> >   symmetric modes in "International" versions of the various browsers.
> > 
> > I guess I've been out of touch--is there an extension in web certs that
> > enables
> >   better than 40-bit symmetric SSL modes?  My assumption has always been
> > that
> >   a 40-bit (or 56-bit) browser was "nailed" to that particular key size,
> > or
> >   lower.
> > 
> There's an exemption that permits 128-bit keys when talking to financial 
> institutions.  In SSL, this is enabled by some field in the merchant's
> certificate.  Perhaps a "SuperCert" has that bit set?

Yes, this seems to be the Thawte version of Verisign's "Global Server
ID"'s; both have taken advantage of the DOC's modified regulations to
add an additional charge to merchants taking advantage of the program.

See <http://www.thawte.com/certs/server/128bit/contents.html> for the
Thawte, or <http://www.verisign.com/server/prd/g/index.html> for
Verisign.

--
Greg Broiles [EMAIL PROTECTED]
PO Box 897
Oakland CA 94604

Re: BXA

[Greg Broiles]

On Wed, Sep 29, 1999 at 07:41:34PM -0700, I wrote:
> At 04:49 AM 9/29/99 , Donald Ramsbottom wrote:
> >What really intrigues me is the end of your post  relating to the
> >distinction between object code and source code. So if I understand you
> >correctly, you will still require the old style regime and restrictions on
> >source code. If so does that not mean that there is effectively no
> >liberalisation?
> 
> [...]
> Specifically of interest are general question #18, which indicates that 
> technical assistance, APIs, and source code will continue to be controlled 
> under the old regime; technical question #7, illustrating a new detailed 
> approach to API regulation; and technical question #8, reiterating that 
> only object code will be subject to the new policies.

It appears that this may no longer be correct. John Young has made
available on his website a document
<http://cryptome.org/bernstein-mot.htm> filed by the US Government with
respect to the en banc rehearing of the Ninth Circuit's decision in the
_Bernstein_ case. In short, the US Government is asking the court to
postpone oral argument in the case until the US Government has revealed
the new regulations, promised for release on December 15 1999.

As the filing states -

"It is possible that the revised regulations will not materially change
the treatment of source code. But it is also possible that the revised
regulations will alter the treatment of source code in ways that could
have a bearing on the constitutional issues before this Court.[1]"

where footnote 1 says that the BXA's question and answer document "does
not reflect the review that is taking place."

Thus, reliance on that document may no longer be appropriate. BXA's
website does not reflect that change in status. 

--
Greg Broiles
[EMAIL PROTECTED]

Re: desirable properties of secure voting

[Greg Broiles]

On Mon, Oct 11, 1999 at 07:40:16PM +0200, Anonymous wrote:
> > 2. Robustness: Dishonest voters, other participants or outsiders can't
> > disturb or disrupt an election.
> 
> Votehere's system depends on a coalition of mutually suspicious parties
> to tally the vote (they mutually share the necessary decryption key).
> If enough of these refuse to cooperate then this could disrupt the
> election.

Do you have documentation for this? Thus far, the people at votehere
seem to think they have something to hide, and are asking people to
accept their system without disclosure. It would be more accurate to say
"Votehere claims that their system depends .." 

> Snake oil is a nasty phrase in this business.  It's about the worst thing
> you can say about a crypto related enterprise.  Next time it would be
> better to learn about the technology before commenting on it rather than
> the other way around.

If it's not possible to learn something about crypto which is being
promoted, that's all that one needs to know to know that it's snake oil.
If you have a pointer to actual code or technical information about
votehere, it would be helpful, especially in light of votehere's
admission that the information they had on their website, until
recently, was misleading and incorrect. If your conclusions about
votehere are based upon that incorrect information, it might be
appropriate to reconsider them. Have you received information dated
later than their CTO's retraction of their prior statements? 

--
Greg Broiles
[EMAIL PROTECTED]

RE: Is SSL dead?

[Greg Broiles]

,SECURITY ISSUES ,ONLINE SHOPPING ,SSL
> >
> > Abstract/Summary:
> > The title is a bit scary, but I wanted to get your attention
> >(worked, didn't it?). Most
> > security experts have been aware of problems with SSL, but
> >generally speaking we
> > haven't said much because there wasn't much of a replacement
> >available for it,
> > and it hasn't been exploited extensively (chances are it will be,
> >though). I'll start
> > with an explanation of the basic attack, followed by some methods
> >to protect yourself,
> > and finish with an interview with Dale Peterson of DigitalBond and
> >the summary.
> >
> > How to do it
> >
> > Let's say I want to scam people's credit card numbers, and don't
> >want to break into
> > a server. What if I could get people to come to me, and voluntarily
> >give me their
> > credit card numbers? Well, this is entirely too easy.
> >
> > I would start by setting up a web server, and copying a popular
> >site to it, say
> > www.some-online-store.com, time required to do this with a tool
> >such as wget is
> > around 20-30 minutes. I would then modify the forms used to submit
> >information
> > and make sure they pointed to my server, so I now have a copy of
> > www.some-online-store.com that looks and feels like the "real"
> >thing. Now, how do
> > I get people to come to it? Well I simply poison their DNS caches
> >with my information,
> > so instead of www.some-online-store.com pointing to 1.2.3.4, I
> >would point it to
> > my server at 5.6.7.8. Now when people go to
> >www.some-online-store.com they end
> > up at my site, which looks just like the real one.
> >
> > Original URL: http://securityportal.com/closet/closet19990930.html
> >
> > Added: Wed  Oct  6 12:41:14 -040 1999
> > Contributed by: Keeffee
>
>-
>Robert A. Hettinga 
>The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
>44 Farquhar Street, Boston, MA 02131 USA
>"... however it may deserve respect for its usefulness and antiquity,
>[predicting the end of the world] has not been found agreeable to
>experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
>
>For help on using this list (especially unsubscribing), send a message to
>"[EMAIL PROTECTED]" with one line of text: "help".

--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Re: LA wiretaps -- full details available

[Greg Broiles]

At 05:46 PM 9/27/99 , John Gilmore wrote:
>[...]
>When sworn officers of the law and the courts violate the law with
>impunity, concealing their activities by making fraudulent statements
>under oath, and filing all incriminating information under seal, the
>law-abiding public cannot trust the justice system.

Last Saturday's LA Times had an article about the growing wiretap scandal. 
The reporter talked to Gil Garcetti, LA County District Attorney; this 
quote from the article is particularly telling -

>Garcetti defended the use of the so-called handoff practice, saying
>that the technique is used around the country. Kalunian disputes the
>assertion.
>"To my knowledge, no court has said you can't do that," Garcetti
>said.

(Kalunian is an assistant LA County public defender, who apparently still 
has faith in the honesty of law enforcement officers outside of the LAPD.)

Apparently, Garcetti hasn't darkened the doorstep of a law library since 
the mid 1960's, when the federal wiretap statutes were passed. He also 
seems distressingly unfamilar with California state law on the topic, which 
is somewhat problematic, given that he's a prosecutor.

I believe his comment about the widespread use of the tactic will prove 
prophetic.

--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

En banc review granted in Bernstein

[Greg Broiles]

Cindy Cohn (one of Bernstein's attorneys) reports on another list that
the 9th Circuit has granted en banc review of the 9th Circuit opinion in
_Bernstein v Dept of State_. That means they'll redo oral arguments (I
can't remember if they'll also redo the briefs) and the court will then
deliberate, this time with 11 instead of 3 judges.

--
Greg Broiles
[EMAIL PROTECTED]

Re: Internet voting protocols

[Greg Broiles]

On Tue, Sep 28, 1999 at 09:52:41AM -0700, Andrew Neff wrote:
> We acknowledge that our web site does not accurately reflect the protocols 
> on which we have built our products, and we will make the 
> appropriate changes.  However, in creating the site, our intent was
> only to provide marketing literature to the general public.

Why would you build a marketing site which did not accurately reflect
the technical underpinnings of your products? Misrepresentation of your
products seems likely to place you afoul of laws against common-law
fraud, unfair or misleading business practices, and securities law if
you've also been soliciting or accepting investment.

Given that you've already started doing business in a dishonest fashion
(e.g., creating marketing literature which is known to be incorrect),
why in the world would voters, candidates, or registrars of voters ever
choose to trust you in the future? 

When will the inaccurate marketing materials be removed from your
website?

> Regarding our voting and encryption protocols, the techniques used in our
> products are based on the established literature in secure voting
> protocols.  For competitive reasons, we have chosen not to publish the
> algorithms or even release specific references to the literature at this
> time.

If your work is based on established literature, what's to be lost in
making the details public? 

> We want to assure the cryptographic community that we will publish
> all technical details relevant to the security of our system at the
> appropriate time.

How will you determine what the appropriate time is? How could an
outsider determine that independently of your judgement, so that we can
check to see if your assurance proves to be reliable? 

> In the
> mean time, we ask that judgment about whether or not our products
> are "snake oil" be deferred until our technical specifications are
> published.

"Snake oil" is an apt description of a product which is marketed as
having certain characteristics (e.g., security) but whose ingredients or
properties are hidden from potential purchasers.

If you don't want your product to be called snake oil, don't offer sales
literature without technical literature to go with it.

--
Greg Broiles
[EMAIL PROTECTED]

No liberalization for source code, API's

[Greg Broiles]

There's been some discussion of this in the press, but not much discussion 
of the specifics. BXA has published a "question-and-answer" document 
discussing the anticipated regulations; it's available at 
<http://www.bxa.doc.gov/Encryption/q&a99.htm>, and John Young has archived 
a copy at <http://cryptome.org/bxa091699.htm>.

In particular, the aspects of the crypto export policy most directly 
related to research, development, and discussion of improving security are 
unchanged. In the BXA's words -

 >Can you provide a few examples where a license will still be required?
 >
 >Licenses will still be required for exports of encryption technology,
 >technical assistance, cryptographic application programming interfaces
 >(CAPIs), source code and exports destined to foreign government and military
 >end users.

and

 >Is source code allowed to be exported under a license exception or does this
 >policy only authorize the export of encryption object code?
 >
 >Source code will continue to be reviewed under a case-by-case basis. This
 >update will allow the global export of object code encryption software under
 >a license exception.

Also, their thinking about API's seems to have become more nuanced; they 
now envision two classes of API's which are treated differently for export 
purposes, to wit -

 >How does the update to encryption policy affect the export of
 >cryptographic application programming interfaces (CAPIs)?
 >
 >Cryptographic interfaces are divided into two classes: Open Cryptographic
 >Interfaces (OCI) andClosed Cryptographic Interfaces (CCI). OCI's are
 >considered crypto-with-a-hole because they permit a customer or other party
 >to insert cryptography into an encryption item. OCI's will continue to be
 >reviewed on a case-by-case basis through the licensing process.
 >
 >CCI's contain a mechanism (such as a digital signing key) that prevents a
 >customer or other party from inserting cryptography into an encryption item.
 >After a technical review of the binding mechanism, these products will be
 >eligible for export under a license exception. If destined to a commercial
 >enduser, the additional signing can take place under a license exception
 >after a technical review. If destined to a foreign government or military
 >entity, the additional signing requires a license.
 >
 >We intend to discuss this issue with industry as we consult on the
 >implementation of this regulation.

.. so don't throw away those license forms yet, open source fans. The BXA 
can now focus its efforts on Linux fans instead of Microsoft and Netscape/AOL.


--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Re: Why did White House change its mind on crypto?

[Greg Broiles]

On Fri, Sep 17, 1999 at 11:05:37AM -0400, Russell Nelson wrote:
> What's the difference between that, and someone claiming that a
> certain piece of text decrypts to a sinister message?
> 
> Seems to me like the best defense against that is mass-market crypto.
> Because if the TLA claims that something decrypts to something, and I
> can use the mass-market crypto to have it decrypt to something else,
> the TLA has a credibility problem.
> 
> Or is this not why you're scared?

What scares me is the possibility that there won't even be an argument
about whether or not a particular clump of ciphertext decodes to a
particular bit of plaintext because I don't think it'll be possible to
cross-examine prosecution witnesses about the way that they came into
possession of what's purported to be plaintext. They won't need to say
how they came into possession of the plaintext, because that would
reveal their methods - if you know what ciphertext they used (especially
if you're seeing it as an email message (perhaps with Received lines
intact), or as the output of tcpdump) you probably know how it was
intercepted, and that's something they want to keep secret.

The scenario I'm concerned about is a simple swearing/credibility
contest - the prosecution witness asserts that the defendant was the
author of a particular (plaintext) communication which is either a
crime, or admits to committing a crime. The defense can now choose
between offering no response, or having the defendant deny authoring the
communication (under oath, waiving their right against
self-incrimination, including related to collateral matters). The
defense won't have a meaningful opporunity to question the technical
correctness nor the constitutional/legal appropriateness of the access
to the text, because it's not possible to meaningfully explore those
issues without revealing the government's methods.

It's difficult to imagine that the Clinton administration, in light of
recent weeks' revelation about misconduct, hidden information, and
perjury which occurred regarding the conduct of federal law enforcement
officers at Waco, is proposing new legislation which limits instead of
expanding access to information about law enforcement techniques and
behavior. It's likely that a number of criminal convictions were
obtained against the survivors of the burned church building because of
the information which was hidden from the defense and the jury by
prosecutors and law enforcement agencies. That information is now coming
to light as a consequence of a later, civil suit regarding the burning
.. but would we ever have learned it if a statute prohibiting disclosure
of law enforcement methods were in effect? The current CESA draft only
applies to law enforcement methods used to gain access to electronic
information - but if the public swallows that bitter pill, we should
expect it to spread to a general prohibition about questioning the
tactics of the government in all venues.

--
Greg Broiles
[EMAIL PROTECTED]

Re: US encryption announcement: Business as usual

[Greg Broiles]

At 12:51 AM 9/17/99 , Bill Stewart wrote:
>In the absence of technical constraints, it's hard to tell what
>the technical review could be reviewing - we're being told to believe
>that we're allowed to export full-strength crypto,
>and there aren't requirements for key compromise,
>and "works in North Korea" isn't a technical requirement,
>just a customer-destination one.

Some (anecdotal) information on this topic is available from Microsoft, as 
part of their discussion of the NSAKEY discovery - they claim they were 
forced to adopt that peculiar two-key architecture in order to comply with 
the NSA's rules for what's exportable.

Assuming Microsoft is telling the truth about this - and we've had several 
big names weigh in on behalf of Microsoft's good faith and credibility - we 
can conclude that, in some cases, the NSA wants to not only review the 
technical specs, but make substantitve design modifications with 
considerable security implications prior to granting their approval.

I think there are some serious due process problems with requiring review 
according to unpublished secret unrevewable standards prior to exercise of 
a constitutional right, but that's just me.

I'm sure we'd all be pleased to hear more details from either Microsoft or 
NSA about this process, as it's apparently still an important one, even in 
these days of "liberalization".


--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[Greg Broiles]

> [MODERATOR's NOTE: I'm sorry, but I find this totally wrongheaded. A
> 3DES ethernet card need not be "trusted" -- if the thing interoperates
> with other IPSec implementations, its correct, pure and
> simple. Indeed, the slightest flaw and it would not
> interoperate. Perhaps they could rig it to leak too much in the RF
> spectrum, but they could do that with the rest of the chipset, too,
> and you are using *that*.

Which part of the IPSec standard would prevent the card from selecting
key material from a restricted (and known) set of the keyspace, or from
leaking information through a covert channel (which might include parts
of other network packets, or timing of packets)? 

> As for their RNG hardware, Paul Kocher was invited to look inside the
> Kimono and has published a full report on it, and he didn't find
> anything odd... --Perry]

If you're referring to the report at
<http://www.cryptography.net/intelRNG.pdf>, it seems that Paul got a
look at some data which supposedly came from inside the kimono - as the
report states, "For this review, Cryptography Research performed a
series of tests and evaluated the results of experiments performed by
Intel. Raw data and design specifications for the analysis were provided
by Intel." (section 4, page 3).

So, assuming we trust Intel, we've got a report which assures us we can
trust Intel. That helps protect against inadvertent design or
implementation flaws, but doesn't address intentional misbehavior.

--
Greg Broiles
[EMAIL PROTECTED]

Re: Justice Dept asks Court of Appeals to reconsider ruling in Bernstein case

[Greg Broiles]

On Mon, Jun 21, 1999 at 07:26:11PM -0400, Steven M. Bellovin wrote:

> According to the AP, the Justice Department has asked the 9th Circuit Court
> of Appeals to reconsider its decision in the Bernstein case 
> (http://www.nytimes.com/aponline/w/AP-Encryption.html).  The article didn't
> say so, but I assume that they've asked for a rehearing by the full
> court, instead of just a three-judge panel.

They've asked for both, which is how this sort of thing works. 

They advance two arguments in their petition -

"The EAR's Export Controls on Encryption Source Code Are Not a Facially
Unconstitutional Prior Restraint"

(arguing that the crypto export controls aren't targeted at expressive
activity, and hence not properly subject to a facial challenge on prior
restraint grounds)

and

"The Export Controls on Encryption Source Code are Severable From the
Export Controls on other Encryption Products". 

(arguing that the Supreme Court, in _ACLU v. Reno_ 117 S.Ct. 2329,
establishes that it is appropriate for a court to sever part of a
statute or regulation where there is a "textual manifestation" of a
distinction between constitutional and unconstitutional regulation.)

--
Greg Broiles
[EMAIL PROTECTED]

Carl Johnson Documents on the web

[Greg Broiles]

I've put together a collection of documents related to the recent
prosecution and conviction of Carl Johnson, a sometimes itinerant country
musician and author, on charges related to a series of e-mail messages he
allegedly sent to the cypherpunks mailing list.

I'd planned to keep them under wraps until after the sentencing, because I
was concerned that extra publicity might make the prosecutors or
investigators angry, and I didn't think that particular hornet's nest
needed any more disturbing. It's not like they've historically shown
themselves to be inclined towards restraint or a mature sense of
perspective.

Unfortunately, I accidentally published a new version of my web page which
included a pointer to the documents; I can see from my webserver logs that
they've attracted interest from people behind one of the treas.gov web
proxies (they spent a few hours poring over the documents related to Jim
Bell and CJ), so I guess that's cat's out of the bag, for better or for
worse.

So .. go take a look at <http://www.parrhesia.com/cj/> if you'd like to
see what sort of evidence federal law enforcement is producing these days,
and what they're doing with your tax dollars.  

--
Greg Broiles
[EMAIL PROTECTED]

Re: Is anonymous speech protected?

[Greg Broiles]

At 05:30 PM 5/17/99 -0700, Jim McCoy wrote:
>At 04:30 PM 5/17/99 -0700, Dave Del Torto wrote:
>>Second Question: can anyone cite/remember any other federal court decision 
>>that protects one's right to remain anonymous (other than those protecting 
>>victims or people in federal witness protection programs, etc)?
>
>
>Talley v California
>362 US 60
>[...]
>There was another case in the mid-90s similar to this which made it up to 
>the Supremes.  Either way, this particular decision was nothing new...  As 
>always, IANAL.

McIntyre v. Ohio Elections Commission - a 1995 case, IIRC.

The article Dave was looking for follows -

Ban on Masks Called Unconstitutional (SF Daily Journal, 5/11/99)

SOUTH BEND, Ind. - A federal judge has ruled a Goshen city ban on masks
unconstitutional, saying it violates the rights of Ku Klux Klansmen to
express themselves and associate anonymously.

US District Judge Robert L Miller issued the ruling May 4. It was made
public by lawyers on the case Monday.

Last June, Goshen enacted an ordinance making it illegal for anyone 18 or
older to wear a mask, hood, or other device in public to conceal his or her
identity, except for religions, safety, or medical reasons. Violators were
subject to a $2,500 fine. City officials hoped the measure would discourage
the KKK from rallying there.

The American Knights argued that they consider themselves a religion, and
their national leader, the Rv. Jeffrey Berry, testified that members
conceal themselves because they are sinners in God's eyes.

The group also said many members wear the hoods to remain anonymous and to
reduce the risk of retaliation.

Indiana was a Klan stronghold in the 1920s. THe state had 10 active
chapters in 1997, according to KlanWatch, a national group that monitors
KKK activity.


--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Re: Exporting crypto from the US? Think first...

[Greg Broiles]

At 12:13 AM 5/7/99 -0700, James A. Donald wrote:
>Large numbers of people have been conspicuously breaking this law for a
>long time.
>
>Who has been prosecuted?

Charles Booher of San Jose received investigatory attention and subpoena(s)
from the BXA for his website posting of crypto code; I've lost track of
what's happening in his case, but he sounded like he was on the road to
administrative fines, last I heard. 


--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Trademark issues

[Greg Broiles]

 everything.

If RSA wants the crypto community to modify our vocabularies and our books
and our writings so that they can reserve for themselves a valuable IP
right, perhaps they ought to offer us something in return .. like, say, a
clear statement that they've abandoned any trade secret rights in the RC4
algorithm, that they'll abandon their registered trademark in the term RC4,
and that they'll grant a nonexclusive royalty-free irrevocable license to
use the RSA public key cryptosystem (US Patent 4,405,829, if memory serves)
to anyone making a noncommercial code release under a BSD/GPL/NPL or "Open
Source"(tm) compatible license. They can continue to make money from
publishers who make money, but people who want to work on SSL-compatible
free software, or other important crypto apps, can do so, immediately, with
no IP concerns from RSA. Sound like a fair trade?


--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C

Re: new bill getting through congress?

[Greg Broiles]

On Fri, 12 Mar 1999, Anonymous wrote:

> There are troublesome aspects to the SAFE bill, but this notion that it
> is only for companies and won't benefit individual software developers
> appears to be false.  It would be helpful to know where this idea came
> from, and to see what is behind it.

I believe this idea comes from the conduct of the discussion/debate
surrounding domestic and export controls on crypto - it's usually framed
as a dispute between financial/business interests and national
security/law enforcement interests, and the players involved work to find
compromises between the two (apparently conflicting) interests.

Current law and policy attempts to limit the use of cryptography by
limiting its production and distribution, leaving end uses unrestricted.
The compromises (like SAFE) proposed by the business/law enforcement axis
shift the locus of control from the producer/distribtor to the end user -
distributors will not be primarily responsible for eliminating unpopular
or forbidden uses of crypto, end users will.

Producers/distributors of crypto like that shifting of the control point
to the end user because their own regulatory burden is significantly
lessened (modulo continued restrictions on academic and non-economic
distributions of crypto, per Ian Goldberg and Jim Gillogly's messages),
and they're likely to see wider sales/distribution as a result. Law
enforcement doesn't mind (terribly), even though they'll kick and scream,
because while the controls will be less effective (e.g., total compliance
rates will go down) they'll gain extra funding, expanded investigatory
power, and better prosecutorial leverage through the additional "crypto
for a crime" charges that all of the proposed bills create.

End users may not be as pleased with the changes, as they're suddenly the
focus of new restrictions and regulatory activity. End users,
unfortunately, don't have much of a lobby; and they're difficult to
"compromise" with, since many of their positions rest on fundamental
rights, which shouldn't be compromisable. Unfortunately, the vocabulary of
rights and freedom is unintelligible in Congress - it's necessary to talk
about dollars and jobs (and children and fear) to construct a meaningful
sentence, which has led us to the current set of business vs. national
security compromises.  

Of course, since end-user control of crypto won't work any better than it
does with firearms or drugs (or other politically incorrect technologies),
we're likely to see a return to source control within a few years - but
the end user controls (granted as quid pro quo for the reduction of source
control) won't be removed, because by that point it'll be obvious that our
problems were caused by inadequate government intervention into ordinary
human lives, so a reduction of that intervention certainly won't be seen
as appropriate.

Also, on an unrelated note, I understand that both houses in Congress are
considering a fast-track bill to outlaw the transfer or sale of
thermometers to frogs or other amphibians without a license from BTA.

--
Greg Broiles
[EMAIL PROTECTED]

Misc crypto & patent notes

[Greg Broiles]

While working on another project, I noticed that Tandem (through four
employees) recently received a patent on a variant of public key crypto
which involves the use of three primes and the Chinese Remainder Theorem -
the patent itself is available at
<http://patent.womplex.ibm.com/details?pn=US05848159__>.

Also, Silvo Micali recently received a patent for "traceable anonymous
transaction" which appears to involve identity escrow by a third party (I
haven't had time to dig into this further) - the patent is at 
<http://patent.womplex.ibm.com/details?pn=US05812670__>.

I found those while looking through the patents which have issued which
reference the original RSA public key patent (4,405,829) - it's pretty
easy to construct a query to find all of those patents (currently 140)
which might make interesting reading - see
<http://patent.womplex.ibm.com/patlist?&uref_pno=US04405829__>.

Also, someone on sci.crypt noted that a German Enigma machine (minus the
codewheels) was recently sold via eBay; it sold for $7300. See
<http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=64840419>
including a picture and detailed description. The same seller (from
northern NJ) also sold a Swiss copy of Enigma for $2500. The same buyer -
who did not have any previous transactions listed - was the winning bidder
for both machines. I don't get the impression the seller had any idea that
hardware crypto is export controlled, as (s)he discussed making
arrangements for foreign shipment.

--
Greg Broiles
[EMAIL PROTECTED]

Re: AUCRYPTO: Bidzos pro-wassenaar posturing.

[Greg Broiles]

On Sat, 9 Jan 1999, Enzo Michelangeli wrote:

> So, my question is: is anybody aware of any (official or unofficial)
> licensing condition from RSADSI discouraging the use of ciphersuites based
> on Diffie-Hellman key exchange? Or may we hope in TLS-compliant browsers
> before September of next year?

I've talked to and worked for organizations which might've been subjected
to conditions like you mention above and have never heard of one proposed
by RSA nor accepted by a licensee. I think you could characterize RSADSI's
licensing and price terms as being structured to encourage the use of DH
and TLS.

RSADSI is, reasonably, trying to get people to standardize on BSAFE, both
as an API and as a library; that way they can continue to collect
royalties even when their current monopolies (like the patent on RSA, and
the FUD around RC4) wither away. This is not necessarily bad, at least for
commercial users - working, debugged, supported crypto libraries can take
a lot of the headache out of product development, and a royalty is just
another cost to be figured into a business model. To a freeware/opensource
developer, $20K/year is prohibitive - to an ongoing business, it's not an
obstacle. Unfortunately, this means businesses don't have a strong
incentive to work with unencumbered ciphers - it's not sexy to
develop/support them, as you can't make much on licensing your code (or
it's not "unencumbered" any more); but it's not efficient to develop
unencumbered code in-house at a cost of maybe $100K per developer-year, if
you could license someone else's encumbered code/ciphers for a fraction of
that.

The interesting question is what's going to happen - or not - to the
BSAFEeay packgage, which implements the BSAFE API on top of SSLeay. It's
certainly not patent-clean inside the US for another 21 months or so .. I
don't know whether or not it's copyright-clean or trade-secret-clean. If
not, it's certainly possible to make a version which is. See
<https://www.cypherpunks.to/bsafeeay/> for more about BSAFEeay.

--
Greg Broiles
[EMAIL PROTECTED]

Re: Cupertino meeting on Thursday....

[Greg Broiles]

On Sun, 10 Jan 1999 [EMAIL PROTECTED] wrote:

> 
> 
> [Anyone going to this meeting? 
> 
> --Peter Wayner]
> 

Jan 15 is Friday, not Thursday; I'm hoping to attend, but that day is a
project deadline for me, so if the project's not done, I'll be at work
instead. 

Other meetings like this I've been to have been educational - if you're
interested in crypto policy/politics, it's probably worth attending.

--
Greg Broiles
[EMAIL PROTECTED]

Re: RSA's Australian deal

[Greg Broiles]

On Wed, 6 Jan 1999, Rich Salz wrote:

> www.aus.ras.com, I think.

er, www.aus.rsa.com

> Curious.  Two years ago OSF's outside counsel, bright folks at
> Hale&Dorr, advised us that a wholly-owned subsidiary of a US
> company was subject to the US regulations.

The US seems to think that everyone, more or less, is subject to their
regulations - but the US regs don't prohibit offshore development, as long
as US persons don't participate or provide technical assistance or
technical data. RSA's strategy is (apparently) the same as that previously
adopted by C2Net, Sun, etc - offshore development by non-US persons. It's
nice to see that BXA/DOC has finally blessed this strategy - but it
doesn't seem especially remarkable that US crypto regs shouldn't apply to
the activities of non-citizens operating outside of the US working with/on
foreign-developed software.

It'll be interesting to see whether the Australian government chooses to
view RSA's investment as an opportunity or as a threat. 

--
Greg Broiles
[EMAIL PROTECTED]

Re: DigiCash Update, part II

[Greg Broiles]

AL COIN.

There's no discussion of foreign patents, which seems peculiar - the legal
bills from the patent attorneys included amounts for foreign associates,
with legal bills for Japanese patent matters sticking out in particular. 

As far as I can tell, Digicash Inc. (the US corp) was formed in 1990; the
Netherlands and Australian corps are/were subsidiaries of the US corp.

The filing discloses the following historical financial data -

YearSales
1998$134,842
1997$ 10,000

YearIncome
1998$23,161 interest
1998$ 2,580 sale of assets 
1997$53,464 interest

The other item which may be of interest is that the IP portfolio has been
pledged as collateral for a post-filing bridge loan obtained from most of
the funders who are owed the $2M unsecured; I was hoping to trade files
with someone else (whom I haven't been able to meet with yet) so I didn't
get a copy of that filing, but I seem to remember that the postfiling
bridge loan, approved by the court, was for $330K, which will be paid back
from the proceeds of the sale of DigiCash's assets.

I'm hoping to work all of this up into a more comprehensive presentation,
but that's going to take another week or two at least.  
--
Greg Broiles
[EMAIL PROTECTED]
PGP: 0x26E4488C