- cypherpunks-legacy - lists.cpunks.org

Re: Reflections on the Bernstein ruling
by jim bell 17 Dec '03

17 Dec '03

At 11:57 PM 12/20/96 -0800, Greg Broiles wrote: > >(Please keep in mind that I'm not a lawyer yet, and that my comments are >intended only as the reflections of an amateur and are intended as >discussion fodder, not legal advice.) > >Folks seem to be very excited about Judge Patel's ruling in the Bernstein >case - and with good reason. It was, for example, a first-page >above-the-fold item in both of the Bay Area's legal newspapers today. >Unfortunately, most of the media reports have done a poor job of >interpreting the ruling, and it's easy to draw bad conclusions from erratic >news reports about the case. The decision is available online ><http://www.eff.org/pub/Legal/Cases/Bernstein_v_DoS/Legal/961206.decision> >thanks to the folks at EFF. I thought list members might appreciate a >summary of the decision and its potential effects. Please comment on my (layman's) proposal that no "mens rea" ("guilty mind") can be attributed to a person who is relying on a not-yet-overturned judicial decision. In other words, if a person has a genuine belief that what he's doing has been upheld by the Patel ruling, he cannot be claimed to have had "mens rea." (I am presuming, here, that before he does anything, he "clears it" with a lawyer who assures him that what he's planning is at least covered in the Patel decision as being okay. I understand, of course, that "mens rea" may be irrelevant in CIVIL REGULATORY issues, but not in CRIMINAL ones.) >1. What the ruling said >In brief, Judge Patel ruled that Category XIII(b) (the category which >refers to cryptographic equipment/software) is unconstitutional because it >functions as a prior restraint upon speech without providing important >procedural safeguards which are required when a prior restraint scheme is >put into place. She ruled that the "technical data" provision of the ITAR >is also unconstitutional when it refers to technical data about Category >XIII(b) items because of the lack of procedural safeguards. > >Mopping up other points raised by the suit, Judge Patel ruled that the term >"defense article" as defined in 22 CFR 120.6 should be read to elide the >phrase "or technical data"; and that when interpreted that way, the terms >"defense article", "defense service", and "technical data" are not >unconstitutionally vague. She also ruled that the term "export" is not >unconstitutionally vague, and writes (in 'dicta', which is legalese for >"offhand comment", e.g., without precedential value but interesting as a >hint re what's going on in the judge's mind) that placing software on an >"Internet site" which can be accessed from a foreign country is an export >for ITAR purposes. What about leaving a floppy on a sidewalk in Des Moines, Iowa, which might be picked up by a wandering foreign tourist who happened nearby? Sheesh, these judges are real idiots, even when they accidently are coming to (mostly) the right conclusion. However, if being "on the Internet" is automatically presumed to be an export, why can't we program using remote-control editors which might, someday, be available on the Internet? (maybe they already are; somewhat analogous to the old timesharing computers of yore. If the underlying files were kept overseas, modified by specific editing commands sent to a remote system, presumably Patel's dicta would suggest that those files were never "exported" per se. They were formed and kept overseas, INTENTIONALLY, to avoid the later necessity of exporting them had they been kept in the US.) This would be an modifed and automated version of the way versions of PGP later than 1.0 were supposed to have been developed: Actual coding was done overseas, based on suggestions and comments from other countries. (including, presumably, the US.) Yes, realize that pessimism overtakes me here. "The system" never wants to admit a contradiction. I would argue, however, that whereever the system wishes to draw the line and call everything outside the line "an export," that decision should be considered binding on the government even when such a conclusion leads to unexpected and undesireable consequences. (for the government, at least...) >She also ruled that the "fundamental research in science and engineering" >(120.11(8)) and "general scientific, mathematical, or engineering >principles" (120.10(5)) exceptions to the definition of "technical data" >are void because they are too vague. As far as I can tell, they are thus no >longer available to potential ITAR defendants. Wouldn't it be more accurate to say that they are no longer considered precisely defined exceptions, NOT that the exceptions no longer exist? It seems to me that if the "burden of non-ambiguity" falls on those writing the regulations, failure to eliminate ambiguity would have to be resolved in favor of tolerating actions that fall into the grey area. For example, if a law was passed that said, "pornographic writing is illegal," and the SC later determined that "pornographic" was ambiguously defined, what they WOULDN'T do is to make ALL writing illegal! (which would, obviously, be an over-broad restriction, in an of itself.) Otherwise, what would on the surface appear to be a overturning of a law would actually be a _broadening_ of it. >It's also unclear that Judge Patel's ruling is enough to make export of >crypto source legal by people/organizations located even in the Northern >District of CA. Venue is proper, in an ITAR case, in any jurisdiction which >the defense articles have moved through. (18 USC 3237(a); _US v. Durrani_ >659 F.Supp 1177, 1182 (D. Conn, 1987); an easy analogy is to the _US v. >Thomas_ "Amateur Action" case, where Tennessee venue was proper for >prosecution of California defendants who sent porn into Tennessee.) So it's >at least arguable that the feds could simply bring an ITAR prosecution in >another district, if exported crypto flowed through that district. But again, deal with the mens rea issue. If Patel said, "It's okay to export this software because the regulation is invalid," and you do so relying on this ruling, wouldn't any subsequent (criminal) prosecution both have to prove you did it, and ALSO prove that you were being unreasonable in relying on the ruling? (Are rulings of illegality somehow more "reasonable" than rulings of legality?) I'm not suggesting that her decision can't be overturned in the future; I'm suggesting that until it is overturned, each member the public is entitled to act in reliance on it, perhaps at least the ones in her jurisdiction. >So while the ruling has considerable historical, cultural, and symbolic >significance, it's dangerous to assume that it means that export >restrictions on crypto are dead. However, wouldn't it be a good idea to take advantage of what is at least a temporary decision? If I were a large corporation, having just developed an excellent design for a crypto telephone, I might want to export it NOW, which is in effect taking advantage of a temporary loosening of restrictions. Jim Bell jimbell(a)pacifier.com

2 1

RE: [NOT NOISE] Microsoft Crypto Service Provider API
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Wed, 25 Dec 1996 23:17:53 -0500, Blake Coverett wrote: >And to think MS was good enough to provide an UpdateResource >API that I haven't yet had a good reason to use. Right thoughtful of them, wasn't it..? <g> >> Interestingly enough, CSP signatures are held in the registry instead of >> the binary, necessitating some install procedure for a given CSP. Not >> to start rumors, but NT 4.0 does use threads to watch some registry >> entries that control the version (workstation/server). Not much of a >> stretch to imagine a thread that tracks (reports?) changes to > >Nope, a little experimentation shows you can change those entries >while the system is running to your hearts contents. Try temporarily >renaming the signature key of the base provider. Now, yes. However I wonder how quickly a service pack would be released to extend the monitor garbage... # Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp # <cadams(a)acucobol.com> | send mail with subject "send PGPKEY" "That's our advantage at Microsoft; we set the standards and we can change them." --- Karen Hargrove, Microsoft (quoted in the Feb 1993 Unix Review editorial)

1 0

Re: Legality of requiring credit cards?
by jim bell 17 Dec '03

17 Dec '03

At 11:20 AM 12/25/96 -0800, Eric Murray wrote: >Brian A. LaMacchia writes: >> >> At 09:35 PM 12/24/96 -0800, jim bell wrote: >> >Bzzt, wrong answer! By definition, if the report was filed as a >> consequence of >the transaction, then the transaction was reported IN FACT >> and the person didn't >evade it! (whether he wanted to evade it is, of >> course, pure speculation on your >part. It is, obviously, questionable >> whether the government can make a person's >mere _desires_ criminal.) >> >> Please, Jim, *go read the law*. Do it now, before you even think about >> replying to this message, else you'll say something else stupid and >> irrelevant. Look, I'll even give you the complete, specific URL for the >> section of the U.S. Code in question; all you have to do is cut-and-paste >> it into your favorite Web browser: >> >> http://www.law.cornell.edu/uscode/31/5324.html > >It appears that Jim's 100% wrong- they omit the 'Suspicious >Transaction' report in the list of reports that the gambler was >busted for trying to avoid: Well, I agree that I was "shooting from the hip" on my statement that the government doesn't prohibit informing the victim (and yes, such people are indeed properly called "victims") that a report was made (see below). Imagine that, Jim Bell OVERestimating the ethics of the government! That'll teach me a lesson. > > >Section 5324: > >(a) Domestic Coin and Currency Transactions. - No person shall for the >purpose of evading the reporting requirements of section 5313(a), > section 5325, or the regulations issued thereunder or section 5325 > or regulations prescribed under such section 5325 (FOOTNOTE 1) > with respect to such transaction - > > (FOOTNOTE 1) So in original. See 1992 Amendment note below. > (1) cause or attempt to cause a domestic financial institution > to fail to file a report required under section 5313(a), > section 5325, or the regulations issued thereunder or > section 5325 or regulations prescribed under such section > 5325; (FOOTNOTE 1) > (2) cause or attempt to cause a domestic financial > institution to file a report required under section 5313(a), > section 5325, or the regulations issued thereunder or > section 5325 or regulations prescribed under such section > 5325 (FOOTNOTE 1) that contains a material omission or > misstatement of fact; or > (3) structure or assist in > structuring, or attempt to structure or assist in > structuring, any transaction with one or more domestic > financial institutions. Notice that they don't define what would constitute an "attempt to cause a domestic financial institution to fail to file a report..." Since from the story told, it is obvious that there is no hard-and-fast rule on reporting, it should be equally obvious that there is no sure-fire way to prevent a report. As such, equally so, there is no object way to tell (other than, say, a direct statement by somebody) that a person's actions were intended to avoid a report. >Section 5313 is the 'normal' reporting section, Section 5318(g) >is "suspicious" transactions (note that it wasn't listed in 5324 above): > >(g) Reporting of Suspicious Transactions. - > (1) In general. - The Secretary may require any financial > institution, and any director, officer, employee, or agent > of any financial institution, to report any suspicious > transaction relevant to a possible violation of law or > regulation. > > (2) Notification prohibited. - A financial > institution, and a director, officer, employee, or agent of > any financial institution, who voluntarily reports a > suspicious transaction, or that reports a suspicious > transaction pursuant to this section or any other authority, > may not notify any person involved in the transaction that > the transaction has been reported. > > >This is really scary to someone like me who doesn't often read >laws. They're required to report "suspicious" transactions >(with the definition of "suspicious" left completely wide open) >and they're not allowed to tell you that you have been reported. >This sounds like police-state tactics, not something that would >happen in a free and open society. Given that the 1st amendment to the US Constitution supposedly is intended to guarantee freedom of speech, any prior restraint on speech must be presumed to be unconstitutional unless proved to be constitutional. Since under the circumstances described there is no known crime or ongoing investigation, such a prohibition on speech doesn't even rise to the level of hypothetical "obstruction of justice" which is occasionally brought up as a phony justification for such bans. Jim Bell jimbell(a)pacifier.com

1 0

Re: Legality of requiring credit cards?
by jim bell 17 Dec '03

17 Dec '03

At 12:31 AM 12/26/96 -0500, Brian Davis wrote: >On Tue, 24 Dec 1996, jim bell wrote: >> Again, he clearly DID NOT "evade the reporting requirement." Brian Davis >> admitted this. (Whether he ever intended to do this is sheer speculation on >> the part of anyone else. We'll never know; as Davis pointed out, the IRS >> screwed up.) Even if the standard of evidence was as low as "preponderance >> of evidence" (which it, of course, is not in a criminal case) he SHOULD have >> won. By waiting until the return was filed and the tax was paid, the IRS >> was allowing him to resolve whatever ambiguity remained. > >You misunderstand what the statute intends. The violation is for >attempting to evade *the bank's* requirement to report certain >transactions (i.e. >$10K). He structured the transaction in an effort to >keep the bank from complying with the law. You just admitted that the bank was ready, willing, and able to report the tranactions without regard to whether they fit within some specific, fixed standard. That being the case, and presuming somebody was aware enough of the practices to realize this (which the lawyer presumably was), then there's no evidence that doing what the lawyer did would "keep the bank from complying with the law." (How, exactly, was the lawyer to know whether or not any particular action would actually achieve the result you claimed he wanted?) >> Actually, if there were any justice, he should have been able to sue the >> bank for reporting him and NOT INFORMING HIM of that fact. (I presume the >> law requires the bank to report suspicious transactions. I also presume >> that the law _doesn't_ prohibit the bank from telling the customer that it >> will have to report that transaction.) Apparently, I presumed wrong. The thugs are even more thuggish than I had imagined. Whether or not any such prohibition is constitutional is another issue, however. The fact that anybody would attempt to write such a restriction into law says a lot about them, however! >>The bank, presumably being experts >> in the matter, recognizes that lay individuals can't be expected to be experts >> in specialized areas, and should be considered obligated to warn customers >> away from suspicious-looking transactions. I'm sure the REAL LAWYERS (tm) >> on this list will be able to cite examples of where experts of all kinds >> were sued by non-experts for failing to warn them of unexpected dangers that >> could have been averted had the appropriate advice been given promptly. >> >So you want the bank to be your nanny? I would argue that if the bank can be forced to help the government enforce the law, the bank should also become liable for damage done as a consequence of complying with such requirements. While it's a different area, within the last few years a decision was made (SC?) that companies which had made Agent Orange for the US Government during Vietnam can be held liable (without recourse against the government, apparently) for the damages caused ex-servicemen for selling dioxin-tained Agent Orange to the government, but manufactured totally according to government specifications. (and used only outside the US, under government direction, by government agents, in an entirely different legal jurisdiction, to boot!) Seemingly, doing something at the behest of government does not immunize one. > The guy is a lawyer and had >previously been involved in transactions in which such reports had been >filed. What is your explanation for the three 3 $9k check request? I have none. But then again, I don't have to. Unless "guilty until proven innocent" has been adopted as a standard of proof in American courts. Do you know something we don't? BTW, gambling pools like this are supposed to be illegal, aren't they? Isn't it odd when government seems to stop enforcing laws unless it's profitable to do so? Jim Bell jimbell(a)pacifier.com

2 1

Re: Elliptic curves
by mixmaster＠remail.obscura.com 17 Dec '03

17 Dec '03

Tim C[unt] May styles his facial hair to look more like pubic hair. o o --/-- <~\ Tim C[unt] May __\ _/\ \ /

1 0

Distributed data havens?
by some days weren't there at all 17 Dec '03

17 Dec '03

Is anything new on the distributed data haven front? Many apologies if I'm retreading scorched earth, but I've been out of touch with the world for the past, oh, twelve weeks. In particular, it would be interesting to know if * there are any lists currently extant relating to datahavens (I've changed e-mail addresses and can't recall the subscription address for dh-l) * anyone has created working or in-progress code to play with. Doesn't have to be "distributed", supported, or documented particularly well. * there are archives of relevant papers or talks avaliable. I've found a few archives for cryptography and stego, but nothing specific just yet (unless you count the discussions of anon remailers). Anyone still interested? --------------------- "Deities do not fall ten floors to the basement" - Willis/PKD pandemic(a)hotmail.com please contact for PGP public key. http://www.skylink.net/~bigdaddy

2 1

A Postcard!
by FiFtHnAiL.c0m＠strydr.com 17 Dec '03

17 Dec '03

======================================================== You have a postcard from FiFtHnAiL.c0m. (fifthnail(a)hotmail.com To retrieve this postcard point your web browser at http://postcards.stryder.com Your password is LIJKBCRT and must be typed in exactly Your postcard will be reserved for you for about two weeks Sincerely, the folks at Stryder Communications, Inc.

1 0

re: Papers Galore
by Kenneth J. Hawley 17 Dec '03

17 Dec '03

>From: bart(a)netcom.com (Harry Bartholomew) >Subject: Papers Galore, address correction >To: cypherpunks(a)toad.com >Date: Tue, 24 Dec 1996 01:58:31 -0800 (PST) >Sender: owner-cypherpunks(a)toad.com >Forwarded message: > >> Date: Mon, 23 Dec 1996 15:16:39 -0500 >> To: cypherpunks(a)toad.com >> From: John Young <jya(a)pipeline.com> >> Subject: Papers Galore >> >> The NSA-hosted National Information Systems Security >> Conference, held in October, 1996, has made a wide >> range of papers available (in PDF format), and listed in: >> >> http://csrc.nist.gov/nissc/1996/papers/NISSC/toc.pdf (110kb) >> ^^^^^ > > should be NISSC96 Actually the correct URL is: http://csrc.nist.gov/nissc/1996/papers/NISSC96/ followed by: toc.pdf and many others. The URL will give you an FTP-style file list. -- Kenneth J. Hawley (616)372-5774 Principal khawley(a)silenus.com Silenus Group, Inc. Detroit - Atlanta - Kalamazoo

1 0

[Fwd: Returned mail: User unknown]
by Carl Johnson 17 Dec '03

17 Dec '03

1 1

Error Condition Re: Invalid request
by listproc＠plaidworks.com 17 Dec '03

17 Dec '03

=============== Mail Daemon Command Error =============== The line that caused the error was: >UNSUBSCRIBE SHARKS CYPHERPUNKS(a)TOAD.COM: You are not subscribed to sharks(a)plaidworks.com ==================== For more help, send e-mail to <info(a)plaidworks.com> or browse <http://www.plaidworks.com/ListAdmin/> to use our new World Wide Web interface. ==================== Any list commands after the point of error are ignored. If you put a 'signature' on your email, that will cause an error. This can be ignored if you received confirmation of your other commands. ========== Mail Daemon Command Summary ========== The syntax for the most common commands is: (if you aren't sure, get help from the above help sources) SUBSCRIBE listname your name goes here UNSUBSCRIBE listname To turn on DIGEST mode, use: SET listname MAIL DIGEST To turn off DIGEST mode, use: SET listname MAIL ACK ========== If you need more help ========== If you can't make it work, send e-mail to <postmaster(a)plaidworks.com> and we'll help you out.

1 0