December 2003 - cypherpunks-legacy

Quiz du Jour
by mpd＠netcom.com 17 Dec '03

17 Dec '03

Which of the following will soon be illegal in the Netherlands? A. Euthanasia B. Pedophilia C. Encryption According to a new telecommunications bill which my Dutch friends tell me has an excellent chance of being passed, the correct answer is "C". Someone send these poor people a good Stego program. -- Mike Duvos $ PGP 2.3a Public Key available $ mpd(a)netcom.com $ via Finger. $

1 0

List Dead lately???
by kelly＠netcom.com 17 Dec '03

17 Dec '03

Subject says it all no mail for days...

1 0

Re: A possibility...
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

:What I am thinking is to have one person encrypt using a RNG (noise). He :encrypts his message using the noise on one channel and then copies the noise :utilized on another channel. He then mixes the two channels to :create....noise. What you mean is generating a random one-time-pad, encrypting with that pad, and sending the pad to the recipient via secure means. I think it has been done before :-) If your idea of sending the 'random noise' is something electronic rather than a black bag, then all you've done is re-invent security through obscurity and your program is little more than hiding plaintext with a stego program. :On the other side the person must be expecting the noise and must know how to :seperate the signal. It seems that this leaves things open by having the :encryption key along with the message, but the message itself is just noise. :(i.e. the interloper must know of the signal, and know how to split it into :it's two components.) Oops. Sure sounds like you meant the security through obscurity option... :::::Comments? You design anything important for Microsoft then??? G

1 0

PowerMac & PGP
by Harry Shapiro Hawk 17 Dec '03

17 Dec '03

X-Reposting Policy: Don't redistribute without permission. Rev.1.0.1 I just got my 7100 PowerPC based PowerMac. So far I am using only 680x00 code and it is runnin just fine. Since there was some questions about where MacPGP would work on this platform, I just generated a key pair. It seems to work fine. I am including the pair and the pass phrase below. Don't use this for privacy :) Here is the pair: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQBPAi2RHwoAAAECANiGZ0Qir9+KnQmGi2wIDQyh2E0jG1kclcBwonmct1II6bq1 I50thXufH/7HL/ISYT8iC//miy89RRKoKLcBkzkAEQEAAbQaUG93ZXJQR1A8aGFi c0B3YXJ3aWNrLmNvbT6JAJUCBRAtkR8kT2czE8MZ2cUBAVfRA/wN3Ozs89tjJgZ4 5dFB65eAQ2iVjGrDDQ3AUEQD4CBDQ1jMerXHKNnK5BsGmf2NIw9OGk4wbybDzKh0 Sk1JT+3TU0zqOE3PNf1lxdJrQvnenDw9fWxw/KDbxHFoxsFjpvKNNA1MIbWt2hR4 gOxjNHW3KSmFTtWlSOSXRTQg9/3axA== =tgZ6 -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP MESSAGE----- Version: 2.3 lQECAi2RHwoAAAECANiGZ0Qir9+KnQmGi2wIDQyh2E0jG1kclcBwonmct1II6bq1 I50thXufH/7HL/ISYT8iC//miy89RRKoKLcBkzkAEQEAAQFWWTx9RmAzxAH/YDTp P9s8+lIhguVPMgrI/L9AIqpYjZ9XDiZ94NfDX68k0/A+hTp7f4/J/jIUp21x+HV5 t1kNE+IfE/HifOH/HQEA9JmghV5dHv8eGH/VkgoRn+OrlN3sv0Ds+fHzUbqNWV4B AMlbeRZVsGNUfP/1qUaP4Yl+h2NGIuXPoa0r2wfY9IevAP7U8bCkPgi1Q5mDlG0e M1SKs6XfMObaSdwOB/6CJQljQ0/9tBpQb3dlclBHUDxoYWJzQHdhcndpY2suY29t Pg== =dokV -----END PGP MESSAGE----- The pass phrase is: powerPGP Harry Shapiro Hawk Manager of Computer Services Warwick Baker & Fiore habs(a)uucp.warwick.com

1 0

A public alternative to clipper?
by an62213＠anon.penet.fi 17 Dec '03

17 Dec '03

> Also, the development of clipper was done with tax dollars. > The government has no need to recoup its investment in developing the > chip. Therefore, they can sell the chips at the cost of > manufacturing, and forget the R&D. That ability to ignore the bottom > line is a pretty powerful mechanism. If a clipper phone costs $100 > less than the alternative, because we the taxpayers already paid for > it, Clipper becomes more and more the only choice. Well, then. Maybe it's time to develop our own PGP chip. Would the PGP routines fit in a large PGA? What's the smallest, cheapest alternative we can come up with? If we give away the PGA code freely, that would help reduce the cost of inclusion in a commercial product. An FPGA would give the user the ability to change keys with little trouble. Upgrading is as easy as swapping a prom. (Better yet have an onboard programmer.) Even then, I would guess that a lot of people would have to pay a bit more for secure communications. I think it's worth it. ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Canon Color Copiers
by Harry Shapiro Hawk 17 Dec '03

17 Dec '03

X-Reposting Policy: Don't redistribute without permission. Rev.1.0.1 Hi, With a friend, I conducted an experiment. We took two one dollar bills. We tried to copy each one on a Canon CLC 550 (aka Canon Color copier). The side with George Washington on it copied fine. The other side didn't. We adjusted the bills so we exposed only half of each bills; that is the top and bottom half and the right and left half. The bottom have copied while the top half didn't. The Left half copied (side with The Great Seal) while the right half didn't. We assumed then it was finding something located in the upper right half of the back of the dollar bill. When we attempted to isolate that part of the bill, it DID copy. Strange. Perhaps someone could look at a 1, 5, 10, 20 and 100 dollar bill and see if there is anything in common in the upper right half of the back of those bills. Interestingly, when we did isolate the upper right half even though it copied, it didn't copy cleanly. You might ask, "How good are the copies." My friend thought they were not great, while I thought they were pretty good. As we were leaving the copier and cleaning up after ourselves, the truth was revealed. My friend tried to pick up one of the "copied" dollars. My friend then remarked, "I guess it is not such a bad copy." /hawk Harry Shapiro Hawk Manager of Computer Services Warwick Baker & Fiore habs(a)uucp.warwick.com

3 2

information question.
by basic＠altern.com 17 Dec '03

17 Dec '03

Hello, i have read your message. Perhaps it could interested me. I'm working in computer security and for my job i try to broke systems. Are those informations interesting for you . Sent me a mail at this adress. bye.

2 1

Promise her anything...
by Hal 17 Dec '03

17 Dec '03

From: Duncan Frissell <frissell(a)panix.com> > The Black Letter phrase from my Commercial Paper class in law school: > > ---------- > Negotiable Instrument: A promise to pay to order or bearer a sum certain > in money on or after a date certain. > ---------- The other night at the library I had a chance to browse through the Uniform Commercial Code as enacted by the state of California. It had a large section on promissory notes and commercial paper in general. The basic definition of a promissory note did include a variation on what Duncan quoted. It would appear that the legal requirements and restrictions on the issuing and sale of such notes are pretty flexible. However, in the digital realm, it is not clear whether a promissory note would truly be enforceable, in the event that the debtor refused to pay. The main question is the digital signature. One thing I wonder about is this. Suppose I simply create a file saying that I promise to pay the bearer $100 on demand. I then sign this using my PGP public key, and give it to someone in exchange for $100. This would be the electronic analogue of the issuing of a paper promissory note. The problem is, "forgery" of such notes, in the sense of duplication, is both trivial and undetectable. With paper, someone could Xerox a note and end up with two, both claiming to be worth $100. But in practice we could distinguish the original from the copy. Better forgeries might be harder to detect but in principle experts should be able to tell the difference. But with the PGP-signed document, any copies made would be completely in- distinguishable from the original. How could the debtor know to honor such a note without being able to tell whether it was the original or not? How could the holder of the note sell it to someone without them kmnowing whether it is valid? Because of this uncertainty, it seems to me that in this simplest sense digitally-signed promissory notes do not work. Such a note, even though signed, cannot be considered to carry value in and of itself because it is too easy to forge. The digital signature is of no value in preventing forgeries since copies of valid notes are just as useful as plain forgeries. Now, the more elaborate technology of digital cash can actually go a long way towards solving this problem, at least in theory. With this approach, each note has a unique serial number, and part of the agreement is that only the first presentation of a note with any given serial number will be honored. Then if the holder of a note wants to sell it to someone else, they go through a protocol with the borrower in which he verifies that the note has not been spent, and a new note is issued with a new serial number that nobody has seen before. This way the buyer of the note is protected against being sold an already-sold note. Plus, the digital cash technology allows this to be done without the debtor finding out who is selling his old notes to whom. There is no reason for him to have this information; the holder of the note ought to be able to sell it privately, and this is a good way of preserving that aspect of the transaction. So, the digital cash technology works pretty well for this application. The problem is that there have to be many additional restrictions and rules in the handling of the notes - notes have to be transferred using the special protocol, and only previously-unseen notes will be honored. It is not clear to me how these additional contractual restrictions can be incorporated into the note without violating the simplicity that Duncan quoted above. Also, in the technical sense, the blinded signatures used in digital cash do not allow the signing of a textual document. Instead, what is signed is a simple number in a specified form, and the *exponent* used in the signature is what determines the "sum certain". So the formal structure of a piece of digital cash does not match the requirement for a promissory note. There would have to be some additional documents which, for example, map the signing exponents to the note values. But again, there is no place in the note itself to put pointers to such additional documents. It is possible that the note could consist in effect of two documents, one part which is a PGP-signed text document laying out the terms and conditions which are relevant, and which states that it only has value when accompanied by a digital-cash data item, signed with the proper exponent, not previously seen by the debtor, etc. Again, then, you have to worry about fraud by the debtor, in which he claims to have seen a note before when one is presented for redemption. In order for note holders to protect themselves against this fraud there would have to be some way for debtors to prove that various notes had been spent. This might be difficult, especially if the people presenting notes for redemption are anonymous to the debtor. It's going to be hard to distinguish between the twin frauds of a holder presenting the same note for redemption twice, possibly at almost the same time from two different addresses, and the debtor who receives a note for redemption, then quickly sends it to himself as though from another holder, back-dating it a few seconds so he claims that one arrived first. Perhaps some form of registered mail for note redemptions, plus a requirement that when a conflict like this arises both presenters must identify themselves, could address some of these problems. (These problems arise for digital cash just as much, by the way.) Hal

1 0

Canon Color Copiers
by Harry Shapiro Hawk 17 Dec '03

17 Dec '03

X-Reposting Policy: Don't redistribute without permission. Rev.1.0.1 ------ From: Edward J OConnell, Thu, Mar 24, 1994 ------ @ THis dovetails with what the service guy told me about using some sort of @ piece of plastic to make stuff copy...but that was when we were working @ with the color theory--he said he could interpose this piece of clear @ material to make stuff that was the 'wrong color' copy. HE didn't say @ what it was. I am willing to think that it first looks for a color or a range of colors. (I have said that before). However, it must be looking for something special based on the test I just ran. (It could be something in the non-visable spectrum.) Does anyone know what range of the specturm the CCD devices in the CLC 550 can capture? FYI, The 550 has 5 CCD's. /hawk Harry Shapiro Hawk Manager of Computer Services Warwick Baker & Fiore habs(a)uucp.warwick.com

1 0

PGP: change ".z" to ".gz" for gzip?
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

While browsing pgp.c, I noticed it checks for several kinds of compression: static char *compressSig[] = { "PK\03\04", "ZOO ", "GIF8", "\352\140", "HPAK", "\037\213", "\037\235", "\032\013", "\032HP%" /* lharc is special, must be last */ }; static char *compressName[] = { "PKZIP", "Zoo", "GIF", "Arj", "Hpack", "gzip", "compressed", "PAK", "Hyper", "LHarc" }; static char *compressExt[] = { ".zip", ".zoo", ".gif", ".arj", ".hpk", ".z", ".Z", ".pak", ".hyp", ".lzh" }; Since gzip now uses ".gz" consistently, perhaps the ".z" should change for PGP 2.5 (or whatever the next public version will be called). I think the code would have to change more to do the right thing with both, since it uses the compressSig to decide which compressExt to try -- is this right? I guess it'd be cleaner to accept both, but probably not worth extra code that would eventually become obsolete. Diogenes (Fingerprint 6FC5C2A5D1A0ED006B576AF7107D51FB)

1 0