December 2003 - cypherpunks-legacy

Java power
by Raph Levien 17 Dec '03

17 Dec '03

At the recent cypherpunks meeting about Java, I was fairly skeptical of its power, especially its ability to do anything useful towards interesting cypherpunk projects. I've been thinking about it a bit more, and I believe I was overly pessimistic. My thinking problem was that I was envisioning Java as a replacement for ordinary HTTP server interaction (such as CGI scripts). I still believe that, absent HTTP server interaction, Java applets are quite limited. However, now that I've started thinking about systems that are built using a combination of Java and servers, the universe has expanded a lot. I'm still unclear about the exact security policy implemented by Java browsers, but this is my understanding: * No access to local files at all. * Can only access URLs on same server as applet came from. Actually, I'm pretty sure the latter is an oversimplification, that the applet can contact any socket as long as it is on the same IP host as the applet itself. However, since HTTP can do pretty much anything any other socket can, the only difference that makes is performance. Here's the "big insight" I had: the server can make up _both_ of these deficiencies, by acting as a file server and communications proxy. Essentially what this architecture does is shift the security burden from the client to the server. In this way, the applet can become "net complete," rather than merely Turing complete. I see one big drawback to this approach. Setting up a server like this is pretty expensive, and using it takes up precious resources. Not everyone has access to a fully scriptable server, which will limit a lot of people. One concern is the "parasitic" use of file system resources on the server. However, there may be a certain amount of security through obscurity that makes this ok. If all Java browsers enforce the policy of only allowing connections to the home host of the applet, then you won't be getting connections from other, parasitic applets. The remaining danger is rogue Java browsers, and non-Java applications that talk to the server, pretending to be Java applets. Some form of authentication could be used to reduce the impact of these attacks. I do see this kind of architecture used to supply services at, say, an organizational level. For example, the "scheduling" scenario could be implemented quite handily, including authentication of access to the schedules, and even distributed scheduling if the different servers are talking to each other. Another scenario which works is email, even including transparent encryption. This one is interesting to me, so I'll go into a little more detail. In this scenario, the server acts as a file server for keyrings (both public and secret) and mail spools. Here's a typical sequence of events for me getting my mail and replying to one message: 1. I call up the JavaMail web page, which is just a wrapper for the JavaMail applet. 2. The JavaMail applet starts with a forms-style login screen. I type my username. 3. The applet asks the server for my mail spool (given the username and perhaps also a password for authentication). 4. The applet displays my mail spool on the screen and lets me fiddle with it, scrolling through it, reading messages, etc. 5. Let's say one of those messages is encrypted with my public key. The applet, recognizing that fact, queries the server for my secret key, encrypted of course (with a symmetric cypher). 6. I type my password to the applet, which lets it decrypt the secret key. 7. Now, that it has my secret key, the applet can RSA-decrypt the encrypted mail and show it to me. 8. I want to reply to the message, so I hit 'r'. The applet gives me a window for typing my reply. When I'm done, I click "send". The applet queries the server for the recipient's public key. 9. When the applet gets the public key, it RSA-encrypts the message and sends it to the server for delivery. 10. When the mail has been delivered, the server notifies the applet of the fact. To me, this is an exciting scenario. Note that, as long as you trust the browser, this lets you read your mail from anywhere. I have no idea whether this scheme is practical. One temporary drawback is the speed of RSA operations. However, this will get fixed when there is native code generation or a bignum library, whichever comes first. Even before then, performance can still be good, using two techniques. First, implement a cache of decrypted session keys (also stored on the server in symmetrically encrypted form). Second, don't display a new email message until it's been decrypted. That way, the RSA operation affects only the latency of mail delivery, not the bandwidth of reading through messages. Of course, these techniques will also dramatically improve performance even for native code crypto. I can see people setting up servers like this for themselves. However, here's an idea on how to set these servers up "for profit." In return for providing file system and mail communications services, the server would expect clients to search keyspaces during idle cycles. When Java goes native code, the computing power thus tapped could be quite substantial. I'm interested to hear what people think about these proposals. Is this something that cypherpunks should be doing full steam ahead? Raph

2 2

Re: SciAm Bye-Byes Privacy
by Duncan Frissell 17 Dec '03

17 Dec '03

>Scientific American, November, 1995 > >Rights of Privacy > >Technology has its eyes on you > >But the search for personalization in a high-tech world >may create an uncomfortable situation in the global >village. Villages are safe places but not very private >ones. Mrs. Grundy, peering from behind her lace curtains, >did stop housebreakers. but she also tried to halt many >other things of which she disapproved. There are signs >that Grundyism is returning to Britain. For those who have neglected their education: 1798 Theater --- "Speed the Plough" by English playwright Thomas Morton, 34. "Be quiet, wull ye [says farmer Ashfield]. Always ding, dinging Dame Grundy into my ears-What will Mrs. Grundy say? What will Mrs. Grundy think?" DCF

1 0

Re: Netscape rewards are an insult [NOISE]
by Richard.Johnson＠Colorado.EDU 17 Dec '03

17 Dec '03

Jeff Weinstein wrote: >John Young wrote: >> >> Responding to msg by stripes(a)va.pubnix.com ("Josh M. Osborne") >> on Sun, 15 Oct 12:0 AM >> >> The PR of Bugs Bounty is the aim, as the quick-market-adapter >> Netscape Chair speechified in FR. >> >> Promoting the notion that hackers are earnestly attacking >> Netscape and reporting its bugs increases its credibility to >> the stock market porkers. Is that not why dear >> all-too-attentive Jeff has been assigned duty on this list, >> feeding peanuts to chimp hackers and champ newshacks? > > I have not been "assigned duty" on this list. I'm here of my >own free will. I want to keep up on whats going on in the >cypherpunk world, and sometimes tap the expertise of the list. >I'm not some corporate flack assigned here to "feed the chimps". >My personal feelings definitely lean toward unimpeded strong >crypto, personal privacy, freedom from govt. surveilence, etc., >and I was interested in this stuff at a personal level before >joining netscape, or working on security stuff. > > --Jeff So a reviewer stepped in and accused the rock star of having "sold out"... Does working as a programmer for a "major label" on a top-40 hit mean you're not true to your artistic roots any more? Or does "working within the system" permanently disqualify you from rebel/outcast status? OK, sorry, enough of the cliches. :-) Richard

1 0

Motherload of Crypto Site...
by frenchie＠magus.dgsys.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I hope that I'm providing some useful info here. I came accross this site in DDJ (Oct 95). A comprehensive amount of crypto stuff available. Crypto Stuff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Admiration, n.: Our polite recognition of another's resemblance to ourselves. -- Ambrose Bierce, iQCVAgUBMIVvH7bmxeO+s+1xAQHS+AP+ImrrqcHfBi6OGOyu5tSAhNHrpkvPE9E5 qh3e8TsFfbyxq1UXgz73FEFfalhs3GeZOgye5DKp0/vsTQ+ZwQyizKX0XhM/MsNT zFnv7B2uOACljwqjiMCc6ZiNA25nXveA+TMIa1sZkhTMtwHzVFogE7X4S91F2gBg Til3urgFAWU= =C/CT -----END PGP SIGNATURE----- =====================PGP Encrypted Mail Preferred======================== PGP Public Keys: 1024/BEB3ED71 & 2047/D9E1F2E9 on request. As soon as any man says of the affairs of the state " What does it matter to me? " the state may be given up for lost. J.J.Rousseau - The Social Contract GAT/E/O d++@>- H--- s: a29 C+++$ UL++++($) P+>+++ L++>++++ E W+++ N++ K- w---- O- M- V-- PS+ PE++ Y+ PGP+++ t 5+ X R* tv b++ DI++ D++ G++ e h+ r y++ [Geek Code v3.0] a.k.a [ root(a)magus.dgsys.com / vamagus(a)delphi.com] ==========================================================================

2 1

Re: responce to graphic encryption replies
by privsoft＠ix.netcom.com 17 Dec '03

17 Dec '03

find attached the document on PrivaSoft in txt format. Once again if you have any comments please call or E-mail me. Steve Orrin Mgr. Tech Services ************************************************* PrivaSoft TM * 1877 Springfield Ave PO BOX 600 * Maplewood NJ 07040-0600 * Tel. 201-378-8865 Fax. 201-762-3742 * Http://www.privasoft.com/privasoft * E-mail: privsoft(a)ix.netcom.com * ************************************************* How Secure Can PrivaSoft Be? Introduction PrivaSoft is a communication security product, and the user is entitled to know how secure it is. This document addresses the question of cryptographic strength of PrivaSoft. Export license regulations In some advanced countries, cryptographic products are categorized as "munitions" and their use, sale or exportation is controlled by local licensing regulations. PrivaSoft has obtained an export license from the governments of Israel and the USA. Licen ses in other countries are obtained in coordination with the local distributors. The typical policy is to limit the allowable cryptographic strength of commercial products to a level that is strong enough for commercial purposes. The basic intention of this regulation is to protect the state from abuse of too strong cryptographic products by terrorists and criminals. Some countries do not practice such law because it is viewed as a denial of freedom of expression. PrivaSoft willfully complies with the se regulations as it is a commercial product, and it is not intended for national security applications with its current key length which is the maximum legally allowable for commercial users. The cryptographic engine of PrivaSoft PrivaSoft uses a pseudo-random generator that is seeded by a 9 digit number uniformly normalized from the user's secret key. The engine is proprietary, designed according to the rules of modern cryptology to make the best use of the allowable key length. Like other dependable cryptographic engines, the structure of the encryption software can be disclosed without compromising the security of the user. However, the coding and specific parameters of the mechanism are considered a trade secret and will be disclosed for the purpose of cryptoanalytic validation when necessary and under an appropriate non-disclosure non-competition agreement. The use of default keys When secret keys or passwords are used by laymen, there is always a conflict between security and convenience: The user tends to use fixed, easily memorized keys again and again, while the cryptoanalyst only waits for an opportunity to see many messages encrypted by the same key. PrivaSoft, being a secure commercial product must live in peace with both - allow the user to use a repetitive, default key, and deny the cryptoanalyst the pleasure of having many messages encrypted by one key. This is done by using the pseudo-random "key extension" feature which is described in the PrivaSoft user's guide. The information contents a clear message If a cryptographic product is properly designed, then the almost only way to crack it is to try all possible keys. If the process is done by a computer, the "cracking"" software must be taught to tell the correct key from the wrong keys. This can only b e done if there are some properties of the decrypted message that are known a - priori. With the PrivaSoft analogue graphical encryption, and with the naturally noisy fax images, a significant portion of the page must be reconstructed, and a significant amount of mathematical correlation must be calculated between neighboring areas of the image, before the cracking software can tell whether the candidate key is wrong. This makes the cracking process much slower than in alphanumeric encryption of the tex t in a natural language. The 9 digit key, when applied to analogue, the graphical encryption is equivalent to a much longer key applied to alphanumeric encryption. The cryptographically oriented user can make it very much harder by some smart pre-proces sing of the image prior to its encryption. A simple example: For a short message, increasing the font size of the text by a factor of 10 will significantly increase the time required for breaking the encryption. Customized versions of PrivaSoft PrivaSoft is unique in being a one-stop product than can serve all types of modern correspondence, including E-mail, fax and paper printouts. Special applications that need and can obtain a license to use non-commercial cryptographic engines can be accom modated by special versions of PrivaSoft. The cryptographic engine can be customer-furnished and customer integrated, however - since in some areas the integration of this product with certain cryptographic engines may be considered "munitions", each cus tomized version of the product has to be licensed separately in accordance with the laws of the territory where it was created and used.

2 1

Re: REMINDER: SF Federal Building, Oct 20, 1015AM: Bernstein case
by Duncan Frissell 17 Dec '03

17 Dec '03

At 01:02 PM 10/19/95 -0400, Thomas Grant Edwards wrote: >Q: Will they allow CU-SeeMe in the courtroom? (over Metricom radio modem?) > >-Thomas > No cameras allowed in federal courtrooms. DCF

1 0

Re: [NOISE] Re: Postscript in Netscape
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

Please stop dinging Dr. Fred on the list, I know he's brought it on himself, but it's painful to watch and pretty juvenile. It's also bring the signal to noise ratio on this list way down. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: DalSemi: Add-Only Memory for Storage of Digital Cash (fwd)
by Dave Emery 17 Dec '03

17 Dec '03

Forwarded message:

1 0

PGPfone and (?) boxes
by Alan Patterson 17 Dec '03

17 Dec '03

A couple of months ago, the release of PGPfone got the list started on hardware alternatives to PTN encryption... An associate of mine recently returned from the Consumer Electronics show in Hong Kong and broght me a lot of stuff including a flyer for a telephone scrambler. >From the flyer: Secure your telephone conversations through high-tech scrambling. Never again be concerned with eavesdroppers! Description: With our state of the art Telephone Scrambler you can now discuss confidential business and/or personal matters over the public telephone network without worrying about eavesdroppers. This compact and easy to install unit renders taps and monitors useless by way of rolling code encryption. Eavesdroppers will hear nothing but gibberish, ensuring complete privacy for all your telephone conversations. The Telephone Scrambler allows you to set your own unique code ensuring that only you and the party that you are speaking with can decode the conversation. Two units are required -- one for each end of the conversation. Features: o One-touch scrambling o Thousands of key combinations o "Rollig code" scrambling o Works with Tone or Pulse o Easy connection o LED display o FCC registered o Compact and Portable Specifications: Power: 12 VDC Dimensions: 5 1/2" X 3" X 1" Weight: 6 oz PTN Connection: USOC TJ-11C Keys: 2^12 Company is: P3 Personal Protection Products 405 Park Avenue New York, NY 10022 (212) 421-4757 (212) 421-5024 Fax Well, in itself it isn't very impressive. However, I plan on giving them a call tomorrow and check prices. If they aren't that bad I'll get one and pull it apart. Perhaps it can be at least reprogrammed for more keys and another encryption algo. Hell, at 2^12 keys, all it takes is a few seconds to find which one the conversation is using. Alan Patterson (lep(a)wsnet.com) Fngpt: 41D0F61B496FECC09FABECF686AB2A1C WSNetwork Communications Services, Inc. PGP Encrypted Email Preferred Montgomery, Alabama (334) 263-5505 (800) INET-750 Public Key @ MIT keyserver

1 0

Re: digital cash and identity disclosure
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:48 PM 10/19/95, Bryce wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > Someone claiming to be the nym calling itself tcmay(a)got.net (Timothy C. >May) wrote: >> >> As Hal notes, there are a lot of issues and attacks to consider. I'm sorry >> that my brief section on Chaumian digital cash in the Cyphernomicon doesn't >> adequately cover the issues (and as the debates here show, confusion still >> reigns, and no doubt some of my points are misleading, wrong, or >> incomplete). > > >Boy, if I were you I would want to fix the inadequacy in C'nomicon in >order to protect my positive rep... To each their own. There's not enough time in my life to fix all the things that are wrong, even if I knew what they all were. My "positive rep," such as it is with certain people, does not depend on producing flawless documents. In fact, there are different kinds of people. Some favor "closely reasoned" arguments (A implies B implies C implies D....), some favor "imaginative leaps." Where I am depends on my mood. - >> it tends to make >> identity-revealing attacks possible (such as the attack I alluded to, and >> that Hal more completely describes), > > >I hesitate to pipe up in such august company, but one of us is >confused. The attack that we have been discussing is possible because >Chaumian Ecash allows the payer to identify the payee. This would be >true whether or not there were any protocols related to >double-spending. (i.e., because the payer knows the actual ID number >of the bill, she can choose to relate it to the bank and then the bank >can identify who turns in that bill. Has nothing to do with >double-spending. If the protocol provided for re-blinding before >depositing the bill then this would not be possible, I think, and >would still have nothing to do with double-spending.) Oh, but it does. Suppose Alice pays out the same piece of digital cash to Bob, Charles, Ellen, Dave, etc. Each thinks they've been paid, each gets to the bank, each finds the bank will not honor the digital cash, as Alice has double spent. (Note: Any schemes for "re-blinding" must still allow "uniqueness"...and must still point back to Alice. Else the scheme/scam above will work. Online clearing, in which only the _first_ to present a digital cash claim gets paid, does not have this problem.) >Announcement: I'm about to fade out from c'punks list for a while, so >be sure and Cc: me if you want me to see your post. I will this time, but people generally should not expect out-of-band cc:ings. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1