December 2003 - cypherpunks-legacy

Bug in PGP2.6 when editing your key
by Jeffrey I. Schiller 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- We have found an important bug in PGP 2.6 (and 2.5). Problem: If you store your pass phrase in the PGPPASS environment variable or supply it via the PGPPASSFD hack and you edit your key (pgp -ke) you may lose. Specifically if you edit your key and do *not* change your pass phrase, then it gets clobbered and you lose access to your private key. What to do if this happens to you: You will know that this has happened because you will edit your key and then not be able to use your private key. *IMMEDIATELY* restore your secring.pgp and pubring.pgp from the ".bak" versions that PGP automatically creates. This will put things back the way they were. Work Around: You can avoid this problem when editing your key by doing one of the two things below. 1) Remove the PGPPASS environment variable (or don't use PGPPASSFD) when editing your key. You will then have to manually type in your pass phrase when editing your key, but the pass phrase will not get clobbered this way. 2) If you still use the PGPPASS environment variable, then when the key editing process asks you if you wish to change your pass phrase answer "y" (i.e., tell it that you wish to change your pass phrase) it will then prompt you twice for your new pass phrase. Note: You can set it to what it was, effectively not really changing it. PGP will not know the difference and your pass phrase will not get clobbered. Status: This problem has a known fix and it will be included in the next release. -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBLiCWkVUFZvpNDE7hAQF/GQIAoWi86mx1TylR5CUWInJrYy/L5kNB0qqB Uo/gA+u4M7YYeFEVF+voeBBRW686j2ksWaMA3ERTN8o6HWc5hrcf+A== =fXWk -----END PGP SIGNATURE-----

1 0

using RSA-the-cryptosystem to secure RSA-the-company's patent?
by Jef Poskanzer 17 Dec '03

17 Dec '03

Apropos the recent thread on tamper-proof programs... Can anyone think of a way that RSA-the-company could include some sort of RSA-cryptosystem-secured check in a release of PGP so that it would only interoperate with other versions that have the same check? I don't see how it could be done, but it's sure an intriguing idea. --- Jef

2 1

Re: using RSA-the-cryptosystem to secure RSA-the-company's patent?
by Jef Poskanzer 17 Dec '03

17 Dec '03

>The point of this is, why would *you* care? I can understand why RSA >_might_ care, but I don't see Phil Zimmermann agreeing to it, and I >don't see how anyone could force it into PGP at this point. They got the stupid version number thing in; if they had thought of a better trap, they could probably have gotten that in instead. The point is, the secret key would not be in the source code. I can't think of a way to use that; you can't; RSA couldn't; but I'm not convinced it's impossible. --- Jef

2 1

LD's Cypherwonks list
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Peterwheat(a)aol.com: > found this by doing a keyword search (cryptography) in America Online's > database of mailing lists. I thought it might be of interest to the > cypherpunks mailing list: > > CYPHERWONKS: The Development of Cyberspace I subscribed to this when LD first announced it early last December. I never received any mail. At that time I do believe Julf had said something supporting this list. Incidentally the address for LD in your database on AOL is ancient. And the description message seems watered down. The original post was full of LD's paranoid gems -- here's an excerpt for your entertainment: > anonymity. However, we do not necessarily believe that others are > required to read anonymous postings. To the contrary, we believe that > the individual should have the tools and freedom to filter his or her > own mail based on real identities. In particular, we condemn the > practice of `pseudospoofing,' the dangerous deception where a person > builds up a pseudonym and misrepresents it as being that of a real > person's identity. We police each other on the list to prevent it, and > require a promise that our members refrain from it. While our trust can > be betrayed, only those that are honest are true cypherwonks, and > anyone who betrays our trust we consider a dishonist hypocrite, or worse, > a *traitor* Note the Detweilerese: pseudospoofing, honest and true, hypocrite, *traitor*. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

PGP for Russia...
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

"Robert M. Humphrey" <Robert(a)rmh.khabarovsk.su>: > Anyone with any ideas how I can get going on PGP or something else under > the circumstances would be more than welcome. Do you have telnet/ftp access? I believe the .su domain does have full Internet connectivity... If you do, you should pick up PGP version 2.6ui from ftp.dsi.unimi.it /pub/security/crypt/PGP/pgp26uix.zip Even if you're a US citizen you can't export PGP from the US under US law, so don't try it from CompuServe. If you don't have net access, the only way is to have someone split PGP into dozens of UUENCODED parts and mail it to you. If no one else volunteers to do this from outside the US, ask me. (Yes, I am lazy, and maybe someone's already got a split UUENCODED PGP ;-) Rishab ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

"uncrackable" executables
by dfloyd＠runner.utsa.edu 17 Dec '03

17 Dec '03

As to altering MS-DOS executables, the only option that I see that someone cannot go through is a dongle with the MD5 image signed by your public key burned on the ROM. The dongle will be optional, and for user verification that the program works. I wonder if one can boot off the dongle... have it do its tests in rom on applications....?

2 1

Tamper-Proof Software? No!
by collins＠newton.apple.com 17 Dec '03

17 Dec '03

Hello, Software only products cannot be made unconditionally tamper-proof, for the following definition of `tamper-proof': "An attacker, on their own machine (over which they have complete control), given a copy of the software that `runs' on that machine but includes mechanisms so that it won't run under certain conditions (the `tamper-proofing'), cannot produce a piece of software that lacks the tamper-proofing." By this definition, I am not addressing, e.g., pirates attempting to unlock a software distribution without the key, nor getting a bogus agent to run in a protected environment like Telescript, nor programs where a significant part of its functionality happens inside a physically tamper-proof `dongle'. Tamper-proofing is a fundamentally different problem from secret communication. The latter is `How can two parties exchange information such that no third party can learn it?' The former is `How can one party tell a secret to a second party, and at a later time, take it back?' You can't `un-tell' a secret. The functionality of your program is the secret. If that secret is revealed (and when you run the program, it will be) there's nothing left to protect; the secret is out. Tamper-proofing mechanisms amount to questions, answers, and actions. Each can be supplied by either the software itself or some outside entity (e.g., the OS, a `dongle', a network key-server, etc.). They come in many forms, but they can be reduced to "Is this the original software?", "yes" or "no", and `continue' or `quit'. In the case where it is the software itself that decides whether to run or quit (and since the attacker has complete control over the environment, it must be), the attacker is not constrained to defeating an arbitrarily hard authentication scheme. It is sufficient to avoid the test or refuse to quit. Replace each call to a tamper-detection routine with a call to a routine that has the same side-effects as the original would when no tampering has occurred (which can be observed). Thus, if the software checksums itself---remove the code that asks for the checksum, or remove the code that quits if the checksum doesn't match. If the checksum is required to decrypt some part of the program---build a copy of the software that is already decrypted, or use the saved checksum from an original run. If the program uses the value returned by a dongle to decrypt part of itself---watch it happen once, then keep the decrypted part. If a network server won't give you an open socket until the software answers an unpredictable question about itself that the modified program cannot answer---relay the question to an unmodified instance of the program. Sooner or later, in the course of execution, the `useful' part of your software will be presented, unencrypted and ready to run (if not without strings) to the CPU. Even if this happens only a little bit at a time, the attacker can record those hunks and assemble them into a new, unencumbered package. The attack might not be cheap! But people will do it if the reward exceeds the cost. If there is functionality you want to protect unconditionally, don't give it away! Sell a service instead. Hope this helps, Scott Collins | "That's not fair!" -- Sarah | "You say that so often. I wonder what your basis 408.862.0540 | for comparison is." -- Goblin King ................|.................................................... BUSINESS. fax:974.6094 R254(IL5-2N) collins(a)newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 ..................................................................... PERSONAL. 408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Forwarding & Reference Pointers
by Stuart Smith 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >greg(a)ideath.goldenbear.com (Greg Broiles) writes: >> Count this as a vote in favor of pointers to information instead of >jgostin(a)eternal.pha.pa.us writes: > Count this as a second, plus some kind of summary of the article >referenced. :-) This is a silly way to prove a point, but count this as a third.. <sigh> - -- Baba baby mama shaggy papa baba bro baba rock a shaggy baba sister shag saggy hey doc baba baby shaggy hey baba can you dig it baba baba E7 E3 90 7E 16 2E F3 45 * 28 24 2E C6 03 02 37 5C Stuart Smith <stu(a)nemesis.wimsey.com> -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLiAWI6i5iP4JtEWBAQHfEwQAjBsf3djmjC+x6iCGZQVfQTbLqic+CgBy pM/TFLVZWd7GxmsQSG8oOXpyo4WnAVDDsj2p/o7jNArUSFotbB5ZNEWJgrQV7c0Y MVj08Tj4YtnPzfZaa9y3qN0R01smLp/q6RwiM2c2THRXkA7egqO0MXwUHyN2+wIN ua3UJz8nhww= =rNRk -----END PGP SIGNATURE-----

1 0

Cross-posting problems
by m5＠vail.tivoli.com 17 Dec '03

17 Dec '03

I don't know much about how the majordomo software works, so this suggestion may be impossible. A solution to the decision point Mr. Choate and others find themselves in opposition over might be to add functionality to the list software that would allow articles to be cross-posted in a more sophisticated way. The article could be routed to a special majordomo sub-address which would file the article under some supplied title and then post to the list a brief announcement that the article had been deposited there. There'd be another "ftp" server port for retrieving the articles. Clearly, some provisions would have to bee made for sweeping out the repository, but with some discipline this seems like it might make everybody happy: those who dislike the volume of the direct crossposts would be able to skip by based on subject header alone. Those who appreciate the opportunity to read something they otherwise missed would have a pretty easy time fetching the articles. [ If this is already possible, or if it has been suggested and even beaten into the ground, I apologize; I haven't had much caffeine yet this morning :-] | GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5(a)tivoli.com> | | TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | | (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |

1 0

Re: Bit counting
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Again, if its speed you want, you can't beat look up tables no matter how hard you try. Ray, you've missed the point of some of the explanations; VERY FAST cpu's as unbelievably fast as long as they are executing *on-chip* - as soon as they have to go to RAM for a table lookup, they suffer a performance hit equivalent to executing large amounts of in-line instructions - one array lookup might be worth 200 straight opcodes. Hence why an in-line scheme has to be found for critical inner-loop stuff. The precise details vary according to the pipelining and the amount of on-cpu instruction cache. G PS We'd seen the Escrow Officer Trading Card skit on t.p.c when it first was posted a couple of months ago ;-)

2 1