- cypherpunks-legacy - lists.cpunks.org

NO weak links in DigiCash system!!!
by Marcel van der Peijl 17 Dec '03

17 Dec '03

> I have a couple of problems/complaints with your ecash project. > When I was sent my Acct ID and Passwd they were sent to me plain text > instead of being PGP-encrypted first. This means that some malicious > hacker could have intercepted the e-mail message and stolen the > free cyber-bucks you were so generous as to give me. Second, on the > WWW-page where one downloads the software it does not seem to do a secure > connection between my browser and your server (on netscape there is > a small key in the lower-left hand corner that is supposed to show when > one is securely connected to a secure server). So someone could sniff my > password from the transaction when I GET the software. Also When I'm > buying/selling things it would be smart for all parties involved to > be using PGP, and I think you should stress this point more in your page. > Otherwise this is another vulnerable point in your system IMHO. Let's get this straight before spreading more of these vicious rumours that can easily get misinterpreted. DigiCash is an R&D company developing ecash. We license out our technology to banks. We are running the trial, but only have limited resources to do so. This may result in long waiting time for accounts or no answer on a tech support mail. (We are of course trying to prevent this). In a real-money system, the password can of course not be sent out in plain mail. Either it has to be transferred out-of-band (phone, paper) or PGP'd. But that would require at least ten people answering the phones, sending snailmail, etc. We do not have the resources to do so, so we send out the password plain. A malicious hacker may snatch the password and open the account for you and steal your cb$100. This, however, is not related to the security of the transactions once you open the account! The password is only for starting up the account. And of course downloading on a secure server is not relevant. The software is the same for everyone! It is just not put out for public downloading because it would mean a hundred times more people asking for tech support. It would be more secure if we used different passwords for downloading and for opening the accounts but again, that would give a LOT more problems. PGP does not add any security in the payment system. Ecash is already secure. Feel free to ask us the questions before publicly posting. It will prevent misunderstandings and libel lawsuits. // Marcel van der Peijl, DigiCash bv, http://www.digicash.com/~bigmac/ // "If you had to tell the Whole Truth, you'd never shut up."

2 2

_Do_ read a little Chomsky!
by TOMJEFFERSON＠delphi.com 17 Dec '03

17 Dec '03

You don't have to agree with where he wants to go to enjoy his analyses of where we are and where we are going. He can be devastating. The cheap way to sample Chomsky is to monitor misc.activism.progressive (or is it alt.-.-?) {

1 0

Ping
by Just some guy 17 Dec '03

17 Dec '03

Pinging Cypherpunks

1 0

Gen (x-1)
by j.hastings6＠genie.geis.com 17 Dec '03

17 Dec '03

CNN and others reported that 46% of Generation Xers believe in UFOs, but only 9% believe Social Security will be around when they're old. Har! Kent - j.hastings6(a)genie.geis.com

1 0

Spurious Emissions
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

Spurious Emissions Problem: Get yourself a sheet of log/lin graph paper. Orient the paper so that the log axis is horizontal, and the linear is vertical. On the very bottom major axis of the lin, mark it as -157. The next major axis up would be -147. Next up from that is -137, and so on, to -117. Label this axis as dbmV/m RMS. On the very left of the log axis, mark it as 100. Next major log line is 1K. Next one is 10K, then 100K, 1M, 10M, 100M, 1G, 10G. Label this as Hz. Starting at the junction of 100/-148, draw a nice, straight line to 2K/-148. Continue the line to 10K/-152, then 100M/-124, then 1G/-120, then to 10G/-120. If a body was to test for emissions at a distance of 1 meter, and kept their emission levels below that line, they might consider themselves Real Resistant. Discussions with a Person Who Knows (but wishes to remain anonymous, curiously) have indicated that a body might like to have a room like this: steel outsides (like, say, one of those steel pre-fab sheds), and make sure that steel was grounded *real good* (like at each vertical support, and for each wall's outside material). To make sure there weren't any gaps, a person might want to use fastening screws every 2 or 3 inches, or better still, weld all the junctions. Then they could put insulation (regular thermal type) inside, and hold it in place with steel (or better still, aluminum, since it literally blocks magnetic fields as opposed to absorbing them like steel does) flyscreen, making sure to overlap the screen a good 6 inches at the junctions, covering all inside surfaces (including any windows), and "sewing" the overlapped screen bits with metal wire (preferably the same metal as the screen). Getting in and out screws up any Effects and Properties, but those can be dealt with by having a good 6 inch solid metal overlap on the door, so that it made good mechanical and electrical contact with the wall when the door was closed - there are companies that are more than happy to sell those little metal fingers that you see on RF gear to help with this. Power should be run through standard solid metal conduit, underground, from the power source (electrically isolated, like a transformer) and only appear aboveground inside the room. It should also be *heavily* filtered. A room like this wouldn't be formally certifiable in any official capacity, but would sure screw up anyone trying to monitor emissions, forcing them to either get in real close (and risk discovery), or give up as being too much trouble. But of course, all this is Pure Supposition and Theory. - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

1 0

PRZ on 2048-bit keys, etc.
by Philip Zimmermann 17 Dec '03

17 Dec '03

Folks, a lot of people seem to be eager to generate 2048-bit keys with various not-from-me versions of PGP that have been hotwired to allow 2048-bit keys to be generated. MIT PGP 2.6.1 was supposed to allow 2048-bit keys, but not generate them. Because of yet another bug, the new intended feature of accepting 2048-bit keys does not really work for 2.6.1. That particular feature was added late, and not really tested before the release. We are preparing a 2.6.2 release this week to fix this problem, and maybe a few others. PGP 2.6.2 will accept, but not generate, bigger keys. Why, you may ask, did I go through the trouble of making (well, OK, trying to make) 2.6.1 accept bigger keys, but not actually generate them? I'm glad you asked. Because this is part of a carefully phased keysize upgrade path. You see, from PGP 2.0 on up, each version of PGP that had to introduce a new data format to support a new feature was done in this same manner. A new format is first read by the new release, but not generated. Then, in the next release after that, the new format is generated. This allows time for the new software (that accepts the new format) to be thoroughly propagated through the user community before the new format is actually generated by the even newer software released later. This makes life easier for all PGP users, by preserving interoperability as much as possible. This means that any two consecutive releases of PGP are bidirectionally compatible. My intent was to get a thorough deployment of PGP software that could accept bigger keys before anyone was actually generating any bigger keys. I do it this way to serve the interests of the PGP user community. PGP development has always worked this way, and no one complained before. Now it seems that people everywhere are all too eager to release their very own hacked version that screws up my efforts to preserve interoperability. They make all kinds of changes without talking to me first, to find out why I do things this way, before dashing ahead with what they think the rest of the PGP users need. My phone number is in the PGP documentation. It would be so easy for code developers to simply pick up the phone and call me, and maybe find out why a particular PGP feature (or bug) is in there, when I intend to fix it, or if indeed it should be fixed at all. I would prefer that people call me before they create and release mutant strains of PGP. A little direct human contact by phone goes a long way in defusing misunderstandings about PGP. I would urge that people not generate 2048-bit keys until 2.6.2 has been in circulation for at least a couple of months, to give it time to spread through the user community. I will release a new version later that actually generates 2048-bit keys, for the diehards that want them, and the new software will offer many other improvements as well. I urge that people use the releases of PGP that I make and publish through MIT. The development process includes participation of the user community, and I take seriously everyone's suggestions for what should be included in PGP. I do not work in a vaccuum here in Boulder. I do not make many public statements about PGP export issues, because my lawyers won't let me, but that should not be interpreted as insensitivity to the needs of the PGP user community. There is still an ongoing criminal investigation concerning export of PGP, and I am still the target. Some militant Europeans may think I don't care about PGP usage outside the USA. At least one guy in Europe has demanded that I make statements about and get involved in export-related issues of PGP, and says I've "sold out" (Really? Sold out to whom? And for how much?). I haven't sold out. But I also don't enjoy the freedom of speech that other Americans enjoy. Of course, none of these remarks I'm making here should be interpreted to mean that I approve of anyone violating US export law. And, BTW-- for those of you who get all paranoid whenever I post something on the newsgroups that is not digitally signed with PGP -- Look, sometimes I just don't feel like signing everything I say. There is another email encryption protocol, PEM, which makes you sign every message, because PEM is designed for accountability for every remark you make, and assigning blame. PGP doesn't require you to sign every encrypted message, because PGP doesn't try to put you under oath every time you open your mouth. In my circumstances, maybe I just don't feel like making every little note I write be a signed affidavit. -Philip Zimmermann prz(a)acm.org

1 0

Majordomo sigh
by pstemari＠bismark.cbis.com 17 Dec '03

17 Dec '03

Gee, it was awfully quiet this AM.... Return-Path: <Majordomo-Owner(a)toad.com> Date: Tue, 27 Sep 94 08:51:03 PDT To: psmarie(a)cbis.com From: Majordomo(a)toad.com Subject: Majordomo results: ping Reply-To: Majordomo(a)toad.com -- >>>> who cypherpunks Members of list 'cypherpunks': glowell(a)thorn.wpd.sgi.com cypherpunks-local(a)bb.com sebaygo(a)sibylline.com michael.shiplett(a)umich.edu cypherpunks(a)umich.edu Rolf.Michelsen(a)delab.sintef.no adwestro(a)ouray.Denver.Colorado.EDU Andreas.Elbert(a)gmd.de doug(a)OpenMind.com jeffb(a)sware.com ksackett(a)cs.uah.edu collsc(a)snowbird.aud.alcatel.com koontzd(a)lrcs.loral.com trollins(a)debbie.telos.com matthewn(a)uiuc.edu

1 0

Re: Status of Netscape Bug Exploit (suggestions needed)
by Rev. Mark Grant 17 Dec '03

17 Dec '03

Couldn't you either create the address in a register, and then do an indirect jump through the register, or push it onto the stack and do a ret ? You could do something like mov ecx, address + 01010101 sub ecx, 01010101 jmp [ecx] I'm not certain of the format for BSDI assembler, but I presume that's possible. You could modify the value you add and subtract to make sure there are no netscape-invalid bytes in the compiled code. Mark

1 0

Re: NetScape's dependence upon RSA down for the count!
by jbass＠dmsd.com 17 Dec '03

17 Dec '03

> jbass(a)dmsd.com writes: > > client -> filter Client sends packet with K(c) > filter -> Server filter forwards packet with K(f) filter <- Server Server sends encrypts with K(f) > > client <- filter filter re-encrypts with K(c) > > > > As the protocol progresses the filter also uses the master key, > > and follows the renegotiation as the master key expires. > > Yeah, but in order for this to work, the fake server needs to know > netscape.com's private (secret) key, no? > > -jon No ... the public part of any server private key is held by the filter and not returned to the client. The client only encrypts with public keys provided by the filter. The Server only encrypts with public keys provided by the filter. The filter has cleartext of the entire session. John

3 2

Re: copyrighting algorithms
by Wolfgang Roeckelein 17 Dec '03

17 Dec '03

Hi, From: Bill Trost <trost(a)cloud.rain.com> > >Wolfgang Roeckelein writes: > >I wasn't aware that you could copyright an algorithm. Patent, > >yes, but not copyright. Intellectual property meens secret, > >right? Aren't there any precendence cases involving propriety > >schemes that are reverse engineered? > > Game cartridges (I think sega was involved) > >You might be referring to Nintendo vs. Galoob, which was used as a >sample case in an January 1994 article in the Communications of the >ACM titled "Copyright's Fair use Doctrine and Digital Data". The >article states No, I was referring to a case, where a third party game cartridges manufacturer reverse engineered the specifications of the game cartridges slot for producing his own cartridges for this game. Unfortunatly, I have lost the reference and the names of the companies, but this is the main case cited when it comes to reverse engineering propriety schemes. Maybe I can dig this out, or another member of the list has details available. Wolfgang --- Dipl.-Wirtsch.-Inf. Voice: +49 261 6509 173 Wolfgang Roeckelein Fax: +49 261 6509 179 WHU Koblenz E-Mail: roeckelein(a)wi.whu-koblenz.de Burgplatz 2 (NeXTmail ok) D-56179 Vallendar WWW: http://www.whu-koblenz.de/~wolfgang/ Germany --rsa--------------------------------8<------------------------------------- #!/usr/local/bin/perl -s-- -export-a-crypto-system-sig -RSA-in-3-lines-PERL ($k,$n)=(a)ARGV;$m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2% Sa2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*' ,$_)while read(STDIN,$m,($w=2*$d-1+length($n||die"$0 [-d] k n\n")&~1)/2) -------------------------------------8<------------------------------------- TRY: echo squeamish ossifrage | rsa -e 3 7537d365 | rsa -d 4e243e33 7537d365 Residents of the USA & France *MUST NOT* include this .sig if following up! *** Residents of France & Russia *MUST NOT* make any use of this -sig ! ***

1 0