December 2003 - cypherpunks-legacy

Provably Correct Crypto?
by Matthew James Sheppard 17 Dec '03

17 Dec '03

The shadowy figure took form and announced "I am Dr. Frederick B. Cohen and I s ay ... > > I don't accept the ability to compile it myself as evidence and I > > don't accept a summary of that source written in english prose > > The reason to believe that thttpd fulfills the claims it makes is > provided in some detail in the white paper on our server (see what's new > under http://XXX.XXX) A slightly more detailed version has been > submitted for a journal article, and hopefully will appear in a year or > two. > > [ A ton of crap which was exactly what I said I didn't want ] I stipulated I didn't want any such garbage, I specifically said english summaries are not acceptable and you bombard me with them. Yet you wont accept others opinion of PGP's security, which verbal or other wise, can only be an abstract summary. > > You state that crypto should be poved correct and suggest a technique > > otherwise known as formal specification. I agree, pgp should have > > been written in Z-specs. If you take a course in formal specification > > you will soon see the intractability of the technique wrt large > > systems. > > I didn't say that. Perhaps you should review what I said before > characterizing it. piffle! Your words: "I think that this issue can generally be addressed by a divide and conquer strategy. Prove that the called routines are correct and confined under all possible parameters, do the same for the calling routines, do the same for the interaction between them, and I think you have it." This sounds like performing a formal analsis to me. And you didn't address the intractability anyway. > I have shown (not yet proven) certain things. A graduate student is now > working on trying to prove the various properties I believe to be of > interest in an automatic theorum prover he is working on. The work in automatic theorum proving is ongoing and not limited to your grad student or your work. > I believe that these things are worth showing (and proving), but you > may certainly feel free to disagree with these contentions. I said showing by english isn't good enough, proving would be fantastic. I don't believe these issues reside solely with pgp and as such you should question computability as a whole before using "incomplete specification" in accusing one system to be flawed. > > If you want prople on this list to repeat after you "I cannot be > > certain there is no compromising bugs or backdoors in X" Then I will > > go out on a limb and say everyone here will agree if system X is > > sufficiently large. > > I don't believe I ever asked anyone on this list to repeat anything. > All I did was ask questions and respond to responses to my questions. Your tiresome repetitive question was "Why do you belive X is secure" I herby answer exactly as above "I cannot be certain there is no compromising bugs or backdoors in X" -- <URL:http://www.comp.vuw.ac.nz/~matt> __________ .- __ / -- -\ __ . . . 0 / <___> ___ | =8' //\/ .^| _---_ / \ = / \ \/\ |o | = / o | | || | ... / =0=======0==| |----| |= Another drive by shooting on \_\_/ \_\_/ \_\_/ the information super highway.

2 1

Re: a hole in PGP
by Marc Horowitz 17 Dec '03

17 Dec '03

So Dr. Cohen, what do you use when you want to send a message across the Internet with better security than cleartext? What do your recommend to others? Marc

3 4

Re: Zimmermann legal fund
by nsb＠nsb.fv.com 17 Dec '03

17 Dec '03

At 12:20 PM 8/1/95 +0800, Enzo Michelangeli wrote: >Now, my main objection to opening a US account is that it's unclear >whether or not, for simply receiving payments there, a non-resident and >non-citizen account holder like myself incurs in any tax liability with >Uncle Sam's Inland Revenue. Can anybody on this list shed light on the >issue? Last time I checked, the guys at FV weren't sure either. The real question isn't based on your bank account, but on whether or not Uncle Sam thinks you are "doing business in" the US. This is the fundamentally thorny question that is raised by cyberspace businesses. Having payments made to a US bank account may make it more likely that the US will decide that you are doing so, but they could decide it anyway just because you have buyers in the US, or because you're using a US-based payment server. The laws are, to say the least, not clear on such points. As a practical matter, however, it is true that using a US account will make it easier for Uncle Sam to tax you if it decides that's appropriate. -- NB

1 0

Pat Robertson Fears E-cash?
by John Young 17 Dec '03

17 Dec '03

A Foxhole-atheist swears Pat Robertson said last night that his new book warns of a "digital cash society" and massive theft by cyber-criminals. Did any believer hear this, or know if this is what he prognosticates for e-cash bedevilment?

4 4

Re: commerical busters
by WOOD＠VAX2.ROCKHURST.EDU 17 Dec '03

17 Dec '03

ON: 31-JUL-1995 20:14:46.10, dan(a)netmarket.com wrote: > At 8:50 PM 07/31/95, Patrick May wrote: > > > My dim memories from a project I did for Sony a couple of years > >ago are that commercials are separated by a fixed number of black > >frames and some, at least, have tracking information encoded so that > >advertisers can monitor how often they are played. I'll try to dig up > >more info. > > From: dfitzpat(a)interserv.com > Wednesday July 26, 1995 -- ShopTalk > > - -- > > NEW VCRs TAKE ON COMMERCIALS POINT-BLANK > > By Jonathan Takiff > Philadelphia Daily News Staff Writer > > > Already besieged by Washington politicians over the content of TV > programming (and threats of a show-blocking chip), television > broadcasters are about to be hit with another whammy. This time it's > VCRs that automatically blank out commercials. > > <snip> > > $$$$ $$$$$ $$$$ > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQCVAwUBMB193KZKaCr9f/gtAQFa5AP/ZEmtSM/hSXb6zcFHDmv9Me0thtAqqCxZ > 7COYgWxuLkl78+y/INpFKW861mrNig1UlO8Q+vDImKK3qUmTS1tzRWNIH9XVyYtA > pJ05g/Z/WKUPx17jd2no9oRqut4bziLa4iMj59B/4nxAhIjEtE5TZFP6okCQ1HGm > qbFhOteJavc= > =Opny > -----END PGP SIGNATURE----- > dan Hello all, I have thought about this before, as usual my ideas are not new. My vision was like this. 1. Develop a few methods to recognize commercials through cable T.V. a. The blank spaces between broadcasting? b. Analysis of image information? c. Analysis of sound information? d. Understanding cable T.V. protocols? e. etc? 2. My commerical buster would work on a delay. a. The broadcast information would enter a queue. b. The broadcast information would be evaulated. c. If all of the tests for commericals passed, display. d. If any of the tests fail, the T.V. goes blue, and my CD player is served. e. The time of delay is dependent on the time to analyze the broadcast information. I wish it could happen, I hate commericals. Many Thanks, ------------------------------------------- | "Computers are boring and slow." | | | | David Wood | | Information Systems Specialist? | | wood(a)vax2.rockhurst.edu | -------------------------------------------

2 1

Australia next to ban PGP
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

> Path: ping.be!Belgium.EU.net!EU.net!howland.reston.ans.net!tank.news.pipex.net!pipex!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!rja14 > From: rja14(a)cl.cam.ac.uk (Ross Anderson) > Newsgroups: alt.security.pgp,alt,politics.datahighway,aus.legal,aus.net.news,sci.crypt > Subject: Australia next to ban PGP > Date: 1 Aug 1995 17:53:50 GMT > Organization: U of Cambridge Computer Lab, UK > Lines: 57 > Message-ID: <3vlpne$cks(a)lyra.csx.cam.ac.uk> > NNTP-Posting-Host: nene.cl.cam.ac.uk > Xref: ping.be alt.security.pgp:9699 sci.crypt:4852 > > Australia's proposed crypto policy: > > (1) Banks will get key escrow > > (2) Other Australian residents will be forced to use weak crypto > > Source: talk by Steve Orlowski, Assistant Director, Australian attorney > general's department, given at the Cryptography Policy and Algorithms > Conference, Queensland University of Technology, last month. > > p 34: `the needs of the majority of users of the infrastructure for > privacy and smaller financial transactions can be met by lower > level encryption which could withstand a normal but not > sophisticated attack against it. Law enforcement agencies could > develop the capability to mount such sophisticated attacks. > Criminals who purchased the higher level encryption products > would immediately attract attention to themselves.' > > He mentioned that his department considered itself a suitable repository > for the government central decrypting unit, which would decrypt traffic > for local police forces. He also wants to escrowed keys for banks and > other organisations allowed to use strong crypto. > > Centralising the wiretap capability with the AG is represented as a useful > safeguard against abuse of power by local police forces. It would be > presented as a `data recovery' facility in order to reassure the voters. > > Centralisation will enable the AG to acquire the capability to use ``more > sophisticated techniques in circumstances where the key cannot, for > whatever reason, be recovered from escrow''. > > So the technical parameters would appear to be: 40 bit keys for the > masses, 56-bit escrowed keys for the banks, and a Wiener machine sitting > in Orlowski's office. Belt, braces and string. > > Curiously enough, he quotes a `Review of long Term Cost Effectiveness > of Telecommunications Interception' as saying that ``Encryption by > targets of their communications (both voice and data) is not considered > as a problem for TI at present in Australia'' and goes on to say that > ``there has been comparatively little market for voice encryption > products, although they have been readily available''. > > He even produces some good arguments for the EFF, such as that much of > the intelligence comes from the call log data and from calls to third > parties such as airlines and hotels which are not encrypted. > > He also says that the OECD countries will hold a meeting on National > Cryptography Policies later this year. While at the conference, I found > out that a classified meeting took place this March in Germany between > the signals intelligence agencies of the developed countries, plus > Australia and South Africa, at which the assembled spooks agreed to > press their governments to bring in escrow and/or weak crypto. > > Australia seems rather eager to lick Uncle Sam's boots on this issue. > I wonder what the payoff was? > > Ross -- Thank you VERY much! You'll be getting a Handsome Simulfax Copy of your OWN words in the mail soon (and My Reply). <Andrew.Spring(a)ping.be> PGP Print: 0529 C9AF 613E 9E49 378E 54CD E232 DF96 Thank you for question, exit left to Funway.

2 1

ANNOUNCEMENT: Mailcrypt 3.3 for GNU Emacs
by Patrick J. LoPresti 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mailcrypt version 3.3 is now available. Mailcrypt is an Emacs Lisp package which provides a simple interface to message encryption with PGP. (You do use Emacs to handle your mail and news, right?) Features: Encryption, decryption, signing, adding keys, extracting keys, passphrase caching with timeout, multiple secret key (identity) support, a simple but flexible interface to Cypherpunk remailers (including chaining, response blocks, pseudonyms, and Mixmaster support), and an automatic keyserver interface via HTTP. *We* think it's the best interface to these functions anywhere, but then again, we're biased. The NEWS file is appended to this message. Obtain it through the Mailcrypt home page at http://cag-www.lcs.mit.edu/mailcrypt/ or from the FTP mirror at ftp://cag.lcs.mit.edu/pub/patl/ and enjoy! - Patrick J. LoPresti (patl(a)lcs.mit.edu) - Jin S. Choi (jin(a)atype.com) Tue Aug 1 15:00:27 1995 -0500 ====================================================================== Noteworty changes in Mailcrypt version 3.3: Numerous minor bugs have been fixed. Mailcrypt now requires at least FSF Emacs version 19.28 or XEmacs version 19.12. Sorry, but anything else is too annoying. Support has been added for reading mail under (ding) GNUS. Noteworthy changes in Mailcrypt version 3.2: Mailcrypt now uses "start-process" instead of "call-process-region" to run PGP; this uses a pipe instead of a temp file for various inputs, including your passphrase. Ahem. All Mailcrypt commands now start with the prefix `C-c /' to bring Mailcrypt into line with documented GNU standards. `mc-insert-public-key' is now bound to `C-c / x' (an in "extract") instead of `C-c a'. `mc-deactivate-passwd' is bound to `C-c / f' (as in "forget"). `mc-read-mode' and `mc-write-mode' are now full-blown minor modes. So you can do, for example, `M-x mc-install-write-mode' from a Text mode buffer and have the normal encryption and signing commands available. The keymaps for the modes are configurable variables. Interactive commands `mc-encrypt-region', `mc-sign-region', etc. are now defined. If you use RMAIL and you say no to "Replace encrypted message with decrypted?", you will be dropped into RMAIL mode for viewing. RMAIL summary mode is now supported. Documentation in the form of a Texinfo file is now part of the distribution. Mailcrypt can now fetch a needed key from finger, HTTP, or any of a list of locally stored keyrings. `C-c / k' initiates a fetch manually; Mailcrypt will offer to initiate one automatically as appropriate during encryption or signature verification. The remailer functions now support Mixmaster. `C-c / d' can handle conventionally encrypted messages. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMB6GjHr7ES8bepftAQGXLQP/W4sWXEWficWMlQ340StWd+RC5pJmFh4d 9jlAodH/Gmv1slPmJy21WDPqeyp+3z5BJ8BUgz98e7rqooZ3tB7Fy6cT4Q3UJ0Gv +WZQBkNV4tT7bNjCQxjIE3QrowGBeko0CZIMwGlRujioguHMgHcm8XTJO37ZuypB Sn24f/uPkGc= =8f59 -----END PGP SIGNATURE-----

1 0

Re: OS noise [Was: a hole in PGP]
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

>On Mon, 31 Jul 1995, Phil Fraering wrote: > >> For better or for worse, we all must use programs (or collections >> of programs) that large or larger: even if PGP could be implemented >> in 1 % of the current source code, it would still be running in an >> operating system that's cramped in 4 megabytes of ram, because that's >> a characteristic of the common modern operating systems. > >Ahem! Commiedore APOLOGIED when it released its 512K OS a couple of >years ago. These things _don't_ have to be this large. Foo. Unix used to work just fine in 64K+64K split I&D space on a PDP-11 :-) It got bigger when lots of stuff was added, especially networking and X windows, and I wouldn't want to go back to small machines. However, during one such discussion on comp.unix.wizards or wherever, Dennis Ritchie posted a nice article about "Mine is smaller than yours", saying "here's how big my OS is" (I think ~250K, and the OS was 8th or 9th Edition), "telnet over to foovax, it's this big", "datakit over to barmips, it's that big", "some other networking method over to some other machine, it's that big", "yet another protocol over to yet another bigger machine", "display size of the operating systems on my 256K Blit and Gnot terminal, etc. And QNX's kernel fits just fine inside the cache on a 486, though it wouldn't actually stay there much. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #--- # Crypto in 3-4 lines of perl --> http://dcs.ex.ac.uk/~aba/

1 0

US vs Overseas Banks
by Duncan Frissell 17 Dec '03

17 Dec '03

At 07:05 PM 7/30/95 -0400, Lucky Green wrote: >Six years ago, you could walk into a Bank, show them your driver license, >and open an account. >Today, you need several pieces of ID. >Three years ago, you could withdraw money from your own account without >having your checkbook on you. >Today, they make you pay for a "counter check". >One year ago, you could walk into a bank an cash a check drawn onto an >account at the very same bank. >Today (Coast Federal), they make you pay a $10 check cashing fee. This depends on location. The Feds require that banks use the same ID to open an account that they would require to cash a check. The banks on the Left and Right Coasts are fairly restrictive (more restrictive than they have to be). Banks in the Heartland (particularly the Intermountain West) are much easier. With a little work, it is still possible to open accounts with "soft" ID in the more relaxed regions. Since these banks are accessible by ATM and Fedex and will soon be on the net (in some cases), they can be convenient to use. Likewise Canadian banks (which routinely offer US$ accounts). In the soft ID category, I place Employment ID and Student ID which you are free to make yourselves as well as the new secured credit cards; some of which can be obtained in spite of one's lack of existence. The latter make very good ID. >The US banking industry has gone to the dogs. The day a non-US bank offers >an account that can be accessed over the net will be the day I close my US >accounts. This will be the most interesting story of the next few years. I will be anxious to see if the new ease of "switching" money reverses the trend toward decreased financial privacy caused by the war on money laundering. DCF "If Work, Jobs, Income, and the Middle Class Dream are all over, how come more Americans and a higher proportion of Americans are now in paid employment than ever before in our history."

3 2

Re: a hole in PGP
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

>It is definitely much more difficult to implant a backdoor into a program >which is available as source code than into a black box. > >BTW: Has anyone ever found a modified and weakened version of pgp ? Not that I know of, but there were some versions with a bug in the random-input generation - I forget if that was with ~2.2 or ~2.6.0; Colin Plumb had something to do with it. I've recently acquired ViaCrypt 2.7.1 for WinDows, and one nice feature is that in addition to typing in random keystrokes, you can click your mouse in a box and wave it around to input randomness. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #--- # Crypto in 3-4 lines of perl --> http://dcs.ex.ac.uk/~aba/

1 0