December 2003 - cypherpunks-legacy

No Subject
by nobody＠rebma.rebma.mn.org 17 Dec '03

17 Dec '03

with all this talk about bank card transactions, you remind me that i did a software project for remote credit card verification a while back. my part was the interface to the auth network. anybody curious what's in those transaction messages?

2 1

Re: FW: Physical storage of key is the weakest link
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- chris.claborne(a)sandiegoca.ncr.com writes: ><< some suggestion to keep keys secure on floppy>> > ><<Lance Cottrel writes: >If your passphrase is good (128+ bits of entropy), then your private key is >as secure as the messages that you send. Although it need be broken only >once, I see no real danger of IDEA being compromised in the near future. >Given a good passphrase, I would suggest that you want multiple copies of >your key to prevent loss or accidental destruction. My passphrase is > 30 >characters. Fortunately Mac PGP remembers the key during any given session >so typing is kept down a bit. >>> > >If you are really paranoid, keeping your private keys super secure is a good >idea. If a bad guy were come and steal them all she needs to do find out >your passphrase (using all kinds of attacks.... camera over your desk....) >and bingo, they can read all past and future message traffic to you... There are two things to be paranoid about. One is that other people could get access to your information. The other is that you might loose access to your information and the ability to autheniticate yourself. My personal comfort level is currently: having a few coppies of the secret key which I keep physical control over, only using PGP on my personal computer, and protecting it with a very inconvinient passphrase. Should I also mention that I keep the key, PGP, and all my other crypto stuff on an encrypted partition? -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLhz1+FVkk3dax7hlAQGNlgP9EYV7YWcLCeoNqGYJjZ46KcCglhB3zcpC mu/e1Jr26GPDyKNQySEvVuGNAKKQs0Ep9K1HIUmTt5jaalMh+SE4eeNwfuTV3RtT bsy32E0n7AwTMgOLNeA1jhkBFTxpCnT0lSTO/oKQecnukkkgtxlcl+7gzrs1yhn8 R+V4bZoukCc= =W255 -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

ZiffWire article on PGP 2.6 (fwd)
by Michael Johnson 17 Dec '03

17 Dec '03

I asked Philip Zimmermann what he thought of the ZiffWire article on PGP, and this is what he said: ---------- Forwarded message ---------- Date: Thu, 7 Jul 1994 22:29:24 -0700 (MDT) From: Philip Zimmermann <prz(a)acm.org> To: Michael Johnson <mpj(a)csn.org> Subject: ZiffWire article on PGP 2.6 (fwd) Forwarded message: >From columbine!prz Thu Jul 7 20:58:25 1994 Date: Thu, 07 Jul 1994 20:55:20 -0700 (MDT) From: Philip Zimmermann <prz(a)acm.org> Subject: ZiffWire article on PGP 2.6 To: cypherpunks(a)toad.com (Cypherpunks) Cc: prz(a)pascal.acm.org Reply-To: Philip Zimmermann <prz(a)pascal.acm.org> Message-Id: <m0qM65x-0002vqC(a)maalox.ppgs.com> X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Transfer-Encoding: 7BIT Content-Length: 2943 I would like to correct a misleading assertion that appeared in an article dated 5 July, attributed to "PC Week via INDIVIDUAL, Inc" that came from ZiffWire. The apparent author of the article is Eamonn Sullivan. I think it was posted on the Cypherpunks mailing list. The article concerns Pretty Good Privacy, version 2.6, distributed by MIT. The misleading and damaging paragraphs follow: > MIT and RSA's distribution of PGP Version 2.6 is an attempt to short- >circuit PGP's popularity. After Sept. 1, 1994, PGP 2.6 will no longer work >with documents and keys generated and encrypted by older versions of PGP, >and it is licensed for use only in the United States. > > The release is already causing upheaval, since its public-key format is >different than in prior versions, and numerous public-key repositories will >have to be updated. > >[07-05-94 at 17:19 EDT, Copyright 1994, ZiffWire, File: c0705185.2zf] This assertion is erroneous and damaging to PGP's reputation. PGP 2.6 will always be able to read messages, signatures, and keys from older versions, even after September 1st. The older versions will not be able to read messages, signatures and keys produced by PGP 2.6 after September 1st. This is an entirely different situation. There is every reason for people to switch to PGP 2.6, because it will be able to handle both data formats, while the older versions will not. Until September, the new PGP will continue to produce the old format that can be read by older versions, but will start producing the new format after that date. This delay allows time for everyone to obtain the new version of PGP, so that they will not be affected by the change. Key servers will still be able to carry the keys made in the old format, because PGP 2.6 will still read them with no problems. The assertion made in the article has it backwards, which would indeed be bad if PGP were to start behaving that way. If it did, I wouldn't use it myself. I call upon ZiffWire and PC Week to issue a correction to this error. Also, note that any export restrictions on PGP 2.6 are imposed by the US government. This does not imply that MIT or myself agree with these restrictions. We just comply with them. We do not impose additional licensing restrictions of our own on the use of PGP outside of the US, other than those restrictions that already apply inside the US. PGP may be subject to export controls. Anyone wishing to export it should first consult the State Department's Office of Defense Trade Controls. I developed PGP 2.6 to be released by MIT, and I think this new arrangement is a breakthrough in the legal status of PGP, of benefit to all PGP users. I urge all PGP users to switch to PGP 2.6, and abandon earlier versions. The widespread replacement of the old versions with this new version of PGP fits in with future plans for the creation of a PGP standard. Philip Zimmermann

1 0

C-punks in print...
by Jim choate 17 Dec '03

17 Dec '03

Hi all, For those interested there is an article in the July 94 issue of Circuit Cellar Ink: The Computer Applications Journal on pp. 36. It specificaly mentions the c-punks and their position (ala Gilmore) on various issues of crypto and constitutional rights. Is a good article but shallow on technical details. It is intended more as a pump primer for those poor souls doing real-time control apps. I would say it is worth the time to read. Take care.

1 0

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