December 2003 - cypherpunks-legacy

Announcement: PGS v0.99c
by ER CRAMER 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- PGS v0.99c is out there! This new version of PGS supports 8 bytes keyid's. This version will be able to run in a OS/2 DOS box. PGS v0.99c is available on the following site: wuarchive.wustl.edu:/pub/msdos_uploads/pgs/pgs099c.zip I hope that at the end of next week PGS v0.99c will be available at SimTel too... (oak.oakland.com:/SimTel/security/pgs099c.zip) Do not throw away 0.99b yet because we did the bugfix a bit fast because we want to have it ready before the hollidays... - -- ... If you outlaw Privacy, only Outlaws will have Privacy! Eelco Cramer <crame001(a)hio.tem.nhl.nl> ------ - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLh1SOYDAdPKe9hHLAQFkXAP/UTodjE7HqCGVZAazLAxdYrWcrVgMsYBa kPjn2litqpxZWusMjqTIS3+vHYHrEhXCzBexl69CEo1XQ46PNe1kbrbpwPxGCwzc uCryNVeZ+sOdpJOTAWmPmEYM151X2w7KEjI7vPMmgShQGjQlOBWR0PvQ3VOEd61U mUP6FCfW5HQ= =aEkc -----END PGP SIGNATURE-----

1 0

Re:
by lefty＠apple.com 17 Dec '03

17 Dec '03

>On Wed, 6 Jul 1994, Mike Markley wrote: >> can't be broken in a reasonable amount of time. I'm interested in what >> most of the people on this list would consider a reasonable amount of >> time though. > >NEVER is what I consider a reasonable amount of time. >I don't want my secure thoughts broken for public display >in my lifetime. Or any of my children's lifetime. Or there >children's lifetime. .......... You had better not have any "secure thoughts" then. "Forever" is enough time to break _any_ cipher. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

2 1

RE: "Cypherpunk" vs. "Cryptorebel"
by lefty＠apple.com 17 Dec '03

17 Dec '03

>On Wed, 6 Jul 1994, Lefty wrote: > >> >I like the label "cryptorebel" better than "cypherpunk". The word >> >"punk" just does not seem right, while "rebel" does. I do have a >> >certain attachment to "cypherpunk". Comments? >> >> If it weren't for nitpickers, we'd all be knee-deep in nits. > > There is too much "name recognition" in "cypherpunk" for it to be dropped >now...IMHO. A more serious problem with the name "cryptorebel", which did not immediately occur to me, is that crypto-whatever generally means "someone who denies being a 'whatever' but, in fact, is one". In the words of Inigo Montoya, "You keep using that word, but I don't think it means what _you_ think it does". -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

Curve Encrypt 1.1 Release
by W. Kinney 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Curve Encrypt 1.1, IDEA encryption for the Macintosh is now available. Curve Encrypt is a freeware drag-and-drop encryption application for the Macintosh. It uses IDEA cipher-feedback mode with a 255 character pass phrase, encrypts both the data and resource forks of files, and will encrypt the contents of a folder or volume in a single operation. Source code is provided, natch. CE is System 7 only. (Note that this program has nothing whatsoever to do with elliptic curve encryption methods, just so nobody gets confused...) NEW FOR 1.1 The following changes have been made for the 1.1 release: o Faster encryption and decryption. o Faster file wipes. o Department of Defense standard file wiping is now an option. o The "Use as default pass phrase" selection is no longer present. Instead, Curve Encrypt 1.1 uses keyfiles, a more reliable way to reuse pass phrases. oJCurve Encrypt now saves the creation and modification dates of files when they're encrypted, and restores them to their original values when a file is decrypted. o An incompatibility with the Super Boomerang utility has been fixed. Ftp Sites: ripem.msu.edu:pub/crypt/other/curve-encrypt-idea-for-mac/ This is an export controlled ftp site: read pub/crypt/GETTING_ACCESS for information. ftp.csn.org:/mpj/I_will_not_export/crypto_???????/curve_encrypt/ csn.org is also export-controlled: read /mpj/README for the characters to replace ???????. Address for support: Curve Software <kinney(a)bogart.colorado.edu> Copyright and Distribution: Curve Encrypt (c)1994 Curve Software. Permission is granted for distribution within the United States only, including products containing Curve Software copyrighted source. Export of this software is a Federal crime. Don't do it. Curve Encrypt is free. All releases are verified with PGP signatures. Public key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCPAiz+bEEAAAEEAMUbtdwYC1vY+s5559ERIvC1MT+Yaw3ozheaHcUciJe7cSAk k9TpAQd7iKukKnQe5kK1YtvYm0JP6fmNrcO8AmG5ukvcOlyuri618sjpXncpQ1cL 5xeV80f3JtmheGMnqAzTK8OyfJ7zRh1PhAZcT/vVzf+JGuCuVcJkEfxTVMrJABEB AAG0K0N1cnZlIFNvZnR3YXJlIDxraW5uZXlAYm9nYXJ0LmNvbG9yYWRvLmVkdT6J AJUCBRAuDZ3RwmQR/FNUyskBAd4wA/90tc6Fp0T3kSrmz0Vsbn+M7eND3fNp/XVy CW4xM6xzQK3ooRAjWBbnZbixTyhzlK33X2+EQGGYB5jWA5A+hgGOk3xYhApgBn+K rivF0xKJxNhR4CnsummIyXLn7UPXl0HrPvKszvSCVDhtky2Sy6jNKQcmN7vkFfY+ aAe8ox8944kAlQIFEC4CAaNLsloC2TxExQEBq2gD/2KeXbfrOC3i6FsTNNrODRI1 7i23XTMiquBWmRNheVIQV1dbNKB7DWawUNaykSZiGCEooW+HRKSv3iEGvQiBu1v1 1JB/7Id10a+bIpzCzzfGQ+RvbCCTt9+gACv3JpuXtBmcvIoHKAUpbuQhUd/vR17x 6U9tNhyEa4fdefHgmUsjiQCVAgUQLQSyUSA78To+806NAQECxQP/X5rfktz8h3Je DqX0c9IhobWL36vYGVvzqr8ViYkARMYI7Q4cKupHgDunO+Q+zKiSSsSFBlzlPe4f dg5hJ+eDOUircFRgz5Bu/CN1jAwPdElAHc4W12yiirTvq4HggR7j37aCPz1xsUmg zbKbiM6FI6SKTWK0faOoXoCCbGzA4v0= =IGUN - -----END PGP PUBLIC KEY BLOCK----- This key is also available from the key servers. Curve Software <kinney(a)bogart.colorado.edu> Cypherpunks write code! -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLhsNVMJkEfxTVMrJAQEFfgP+K7NRta8HUqhlegb1d0r9K/DD2mHqy7tv vKF50VVZordlKxLDryv7O5kpXIQK9iGKSZIyu42WL/L25qNJw5DpmSruNPk80ChK n1vOwzJLSXg4qOmPcVU9ejbxzrUy+j7FUOWC3+mBeOBB/oHYBiAISx3o+UHlLDYC 52leB7ozW8U= =B0E/ -----END PGP SIGNATURE-----

1 0

Request: tamper-proofing executables
by Dan Marner 17 Dec '03

17 Dec '03

I would appreciate any pointers to documents, source code or programs that deal with using cryptographic techniques to detect or prevent modification of executable code. I am looking for something that uses either a signature or a one-way hash to detect modifications at run time. Of particular interest is information on signing a file that includes the signature as part of the file. Is this possible with any of the common algorithms? Thanks! Dan -- Dan Marner dmarner(a)mis.nu.edu Network Weasel National University "Not on MY network!"

7 6

Re: On the crime bill and remailers Re: On the crime bill and remailers
by nobody＠kaiwan.com 17 Dec '03

17 Dec '03

Mr. Unicorn is rude and uninformed. He will go far. 1) The act does not make it a per se offense to have a remailer. 2) The act makes it an offense to aid a terrorist. 3) Query: is there a scienter requirement in (2)? [for the sake of simplicity, we will ignore the fact that there are scienter requirements in a related part of the bill already, and use Mr. Unicorn's hypothetical of no explicit requirement of scienter] 3a) There must be a scienter requirement to avoid turning the proscription in (2) into either (i) a per se offense, excluded by (1), or (ii) a violation of due process. 3b) Query: why would it be a violation of due process to have a ban on unknowingly aiding terrorists in the manner Mr. Unicorn wishes to read the satute? An analogy will make the point. Suppose the act concerned restaurant regulation, and made it an offence to "feed" a terrorist. Carlos walks into your joint in disguise, orders and duly consumes ham on rye. What verdict? Courts will do what it takes to say not guilty, whether via due process, the rule of leniency, or statutory construction. N.B. these problems could be cured, and due process observed, by finding a duty to make enquiry or imputing a negligence standard of some sort, but we do not see any hint of this in the statute. 4) Aha! you say, but terrorism is different from nice law abiding restaurants, and we brave c'punkers that we are, are on the Edge, not like the honest sandwitchman. The courts will not give us any breaks. Alas, there is the case of Ratzlaf v. United States, 114 S.Ct. 655 (1994) [summary quoted below], in which the Supreme Court imputed a scienter requirement into a money laundering statute which on its face required no such scienter at all. 5) QED. (As for others who are as quick to damn as to praise...watch your cholestorol!) //QUOTING-- SYLLABUS: As here relevant, federal law requires a domestic bank involved in a cash transaction exceeding $ 10,000 to file a report with the Secretary of the Treasury, 31 U.S.C. 5313(a), 31 CFR 103.22(a); makes it illegal to "structure" a transaction -- i.e., to break up a single transaction above the reporting threshold into two or more separate transactions -- "for the purpose of evading the reporting requirement," 31 U.S.C. 5324(3); and sets out criminal penalties for "[a] person willfully violating" the antistructuring provision, 5322(a). After the judge at petitioner Waldemar Ratzlaf's trial on charges of violating 5322(a) and 5324(3) instructed the jury that the Government had to prove both that the defendant knew of the 5313(a) reporting obligation and that he attempted to evade that obligation, but did not have to prove that he knew the structuring in which he engaged was unlawful, Ratzlaf was convicted, fined, and sentenced to prison. In affirming, the Court of Appeals upheld the trial court's construction of the legislation. Held: To give effect to 5322(a)'s "willfulness" requirement, the Government must prove that the defendant acted with knowledge that the structuring he or she undertook was unlawful, not simply that the defendant's purpose was to circumvent a bank's reporting obligation. Section 5324 itself forbids structuring with a "purpose of evading the [ 5313(a)] reporting requirements," and the lower courts erred in treating the "willfulness" requirement essentially as words of no consequence. Viewing 5322(a) and 5324(3) in light of the complex of provisions in which they are embedded, it is significant that the omnibus "willfulness" requirement, when applied to other provisions in the same statutory subchapter, consistently has been read by the Courts of Appeals to require both knowledge of the reporting requirement and a specific intent to commit the crime or to disobey the law. The "willfulness" requirement must be construed the same way each time it is called into play. Because currency structuring is not inevitably nefarious, this Court is unpersuaded by the United States' argument that structuring is so obviously "evil" or inherently "bad" that the "willfulness" requirement is satisfied irrespective of the defendant's knowledge of the illegality of structuring. The interpretation adopted in this case does not dishonor the venerable principle that ignorance of the law generally is no defense to a criminal charge, for Congress may decree otherwise in particular contexts, and has done so in the present instance. Pp. 5-15. 976 F.2d 1280, reversed and remanded. JUDGES: GINSBURG, J., delivered the opinion of the Court, in which STEVENS, SCALIA, KENNEDY, and SOUTER, JJ., joined. BLACKMUN, J., filed a dissenting opinion, in which REHNQUIST, C. J., and O'CONNOR and THOMAS, JJ., joined. //END QUOTE----------- SOLONg

6 8

REMAIL: scripts
by Karl Lui Barrus 17 Dec '03

17 Dec '03

Recently, somebody mentioned writing scripts to assist in using the remailers (I deleted the message and can't remember who it was). I used to keep a remailer list, and generated simple unix Bourne shell scripts and DOS batch files to do exactly this; however, I'm cleaning up my account and now defer to superior products: (Matt Ghio's and Raph Levien's remailer lists are better, and Hal Finney's chain program is more functional than the scripts). But, if they may be of some use to somebody, I just made available the various PERL scripts, makefiles, etc. I once used to generate the above mentioned scripts. It is available via anonymous ftp at chaos.bsu.edu in pub/cypherpunks/incoming as klb.scripts.tar.gz. The remailer data file included is fairly old and will need updating if somebody wants to toy with the scripts, etc. -- Karl L. Barrus: klbarrus(a)owlnet.rice.edu 2.3: 5AD633; D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 2.6: 088C8F21; 97 73 9E 8B 98 3E DD B5 E8 97 64 7E 20 95 60 D9 "One man's mnemonic is another man's cryptography" - K. Cooper

1 0

Virtual Liability and Lethal Arguments
by blancw＠pylon.com 17 Dec '03

17 Dec '03

Responding to msg by Jim Hart: >What about liability of non designers for failing to >make changes? What about liability of people who use >fallacious moralistic arguments and use coercion to >stop changes? ................................................................. .......... You don't really have a problem with that, do you? :>) There are no expectations placed on non-designers to come up with anything of any practical use to society, therefore they have no responsibility or liability, as no one takes them very seriously. People who put up blocks to progress and improvement (not merely 'changes' per se) are suffering from a sense of loss of control over their existence, and should be sent to a hospital to recuperate from their psychic wounds. (Actually, I think that this wouldn't become such a big problem if, for one thing, everyone had a clear understanding & appreciation of the concept of "property", what that constitutes, and what that means in terms of the liberty to affect things in the world around us.) Blanc

1 0

Re: art encryption...
by Pierre Uszynski 17 Dec '03

17 Dec '03

> From: John Young <jya(a)pipeline.com> > > Responding to msg by pierre(a)shell.portal.com (Pierre Uszynski) > on Mon, 19 Sep 6:32 PM > > >What would be ideal in all these cases is a > >steganographic process that would map to the whole as > >much as to the parts. Fractal steganography. > > The fractal steganography sounds promising. Is this yours or > has it been done? Let me reassure you: I have never heard the idea seriously explored before, and I'm not certain it leads anywhere really useful (as in satisfying from a security point of view.) Mostly, though, the interest in crypto has been so far toward standard message digests made to detect *any* tampering with the message. On the other hand, there has been work on ad-hoc steganographic marks with the purpose of tracking leaks and dumb or hurried copyright violators, and in that case it is useful to keep in mind: no point in protecting only the whole, or only some parts. Still, nothing close to what I described that I know of (I have no read yet about the work at one of the bell labs :-) on marks in text for leak tracking.) Again, as I pointed out, there must be serious tradeoffs in implementations of the idea, to the point where I don't know if it is realizable, or useful. And so far, art signature ideas have been fairly limited and not really explored to their conclusion. Besides, I'm in the "copyright is dead" camp, and for artwork I would tend to put value in physical objects (whether single original, or editions intrinsically limited because of the process). An electronic copy is an electronic copy is an electronic copy. There is value in timeliness too, and that's the main incentive for new ideas and work. Especially nowadays, being there first has value in itself, we don't need legislation to prop that up. I am however interested in such robust message digest ideas in an information retrieval context: How do you index documents without deciding in advance what the retrieval will be based on: words, parts of speech, lines, sentences, paragraphs, digest, exact, approximate, phonetic, relevance feedback... The whole or the part. See also the recent announcement about an NSA product to match similar texts without prior knowledge of topic or even language (as claimed). > The need for authentic sigs on architectural and engineering > drawings is not merely aesthetic. Right now municipal agencies > will not accept digital documents because of the lack of > verifiable authorship to establish responsibility, and > liability, for the health and safety of the design and > construction. Hard copy with original seal is required to > prevent unauthorized manipulation. In this case, a signed message digest would do just fine. If the agency really wants paper, they can have a seal on a form with a printed public key. They can verify that the signature and digest match when the drawing is first delivered, and that's it. No unauthorized manipulation can happen and not be detected (if the drawing digest is checked before the drawing is used.) And the author need not be allowed to repudiate a signature on old drawings. If he destroys the private key after having used it on a project, no new drawings can be filed that fit the same published public key either. So that should do it. Date-stamping is relatively well understood too. > Beyond copyright protection, architectural and engineering > documents are means to guide actual construction, rather than > end products like paintings and drawings in the art world. Actually, they only wish the painting was the end product. Instead it can get ripped off, copied, changed, printed, appropriated in many ways. > If there could be a way for buildings themselves to convey > authenticity, say, that they are healthy and safe, by a kind > decryption by the public that could help prevent concealment of > shoddy construction. It's not the drawings that assure safety > but field verification of the end result that construction work > was done right. > > What a great help if a building could convey its own message of > authenticity about its fitness and safety for habitation and > use. > [...] > Any other thoughts? Yes, we are nowhere close to that, but it's fun to think about it. However, "healthy and safe" is not an authenticity problem. Whether a building is an original or a copy is, so, maybe, is whether the building is according to drawing or not. "Healthy and safe" is very subjective, especially in an over-regulated society where "meeting the code" is essentially impossible. So "healthy and safe" is a certificate granted by an agency that can be duped and/or is lazy and/or has other agenda^H^H^H^H^H^H priorities. (:-) what's the plural for agenda ?) A building according to drawing need not be "healthy and safe". Finally (and then I'll stop, promised) verifying a message digest relies on the verifier having access to at least all that needs to be verified. And only what is available can be verified, of course. So shoddy construction is unlikely to become verifiable because it is hidden from whoever would have done something about it. Transparent finances and more efficient use of reputation may help you more. Pierre. pierre(a)shell.portal.com

1 0

Re: (fwd) "Will You Be a Terrorist?"
by frissell＠panix.com 17 Dec '03

17 Dec '03

At 01:53 PM 9/17/94 -0700, Timothy C. May wrote: >(In this interpretation, the remailers that many of us have talked >about, designed, written software, run on our systems, etc., could be >considered to be part of a conspiracy, should Bidzos, Mykotronx, >ClariNet, the Feds, etc., choose to focus on remailers as "a >continuing criminal enterprise.") But we designed and deployed the remailers not as part of a criminal enterprise but in an attempt to *generally* protect privacy. We may also have wanted to weaken some of the control measures inherent in the TCP/IP protocols. The TCP/IP protocols are *not* a government. It is legal to weaken them. Additionally, federal courts have explicitly held that anonymous communications (and anonymous associations) are protected by the First Amendment. No US Attorney is going to be interested in the sort of messy political case that would be involved in remailer prosecutions. What we are doing in any case is more like sedition than a normal criminal conspiracy. The Feds have only brought two sedition cases in this century (WWII isolationists and white supremicists in the 1980s) and didn't do too well. Sedition cases are real hard to win because in order to prove intent to overthrow the government you have to prove some realistic capabilities. Like Professor Crampton said when he saw my "Fuck the State" button in 1971 -- "That would be a rather large job, wouldn't it?" DCF

1 0