December 2003 - cypherpunks-legacy

Re: Silly technical question from a non-technical person
by droelke＠spirit.aud.alcatel.com 17 Dec '03

17 Dec '03

> > - For DES I think so, asked for others opinions, this might be the > next one to die, big project but possibly doable with lots of keys > at once > But, what is a good DES target to attack?? SSL was a great target because it is both visible and because it has a well defined open specification that made it easy to determine exactly what to attack (unlike Microsoft Access). I know someone who *used* to be in the ATM transaction business, but is no longer. Is the code from a credit card reader DES encrypted? We could be possible "tap" the serial port between the reader and the modem and get a byte stream in that manner.... but then again, my knowledge of those beasts is pretty limited. Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX http://spirit.aud.alcatel.com:8081/~droelke/

2 1

Re: More on Netscape
by koontz＠MasPar.COM 17 Dec '03

17 Dec '03

>It says that the commerce server supports (among others) DES and DES3 >(same as 3DES?). They list the key sizes as 64 and 192 bits >respectively. My question is, isn't DES 56 bits? (with an 8 bit salt >that would be 64 I guess), but isn't DES3 112 bits, not 192? DES keys are specified as 64 bits, of which 8 bits provide odd parity. The 192 bits would specify three independent keys (not triple DES)

2 1

Non-News Govt Announcement on Key Escrow
by banisar＠epic.org 17 Dec '03

17 Dec '03

The White House and NIST annouced today that they were planning to hold two open meetings next month to develop standards for "acceptable" software key escrow. The standards will then be made into a FIPS. The programs cannot have keys larger than 64 bits. Its great to see that it only took them 18 months (since Feb. 94) to come up with a call for public meetings for something that nobody really wants anyway, expcept for the officals who plan to make it mandatory by slipping it through bit by bit and a couple of vendors. (sorry, sarcasm mode off...) -d (in non-official sarcastic mode today from home) David Banisar (Banisar(a)epic.org) * 202-544-9240 (tel) Electronic Privacy Information Center * 202-547-5482 (fax) 666 Pennsylvania Ave, SE, Suite 301 * ftp/gopher/wais cpsr.org Washington, DC 20003 * HTTP://epic.digicash.com/epic

1 0

I need an exportable crypto algorithm.
by Darrell Perko 17 Dec '03

17 Dec '03

Greetings; I realize that bad crypto is offensive to some here but I am in desperate need of an exportable, public-domain, general-purpose crypto algorithm. Or at least the rules for creating such. Sorry to bother y'all with this, but I am in dire straights. Thanks, Darrell Perko dperko(a)efn.org

2 1

Re: SSL challenge -- broken !
by ab411＠detroit.freenet.org 17 Dec '03

17 Dec '03

John Pettitt <jpp(a)software.net> writes: >On Wed, 16 Aug 1995, Damien Doligez wrote: >> The exportable SSL protocol is supposed to be weak enough to be >> easily broken by governments, yet strong enough to resist the attempts >> of amateurs. > >Exactly. > >> It fails on the second count. Don't trust your credit >> card number to this protocol. > >Huh? So you run on 120 workstations worth how much? to steal a credit >card number worth how much? Get real - there are hundreds of ways >to get credit card numbers that cost less. ... SSL can of course be used to protect information other than credit card #s. It is supposed to be strong enough to resist the attempts of amateurs, yet it was broken not by a government, not by a three letter agency, not by a major corporation, but by a grad student with a lot of spare cycles. In other words, it was broken by an amateur. The real issue is not cc#s, the real issue is: does it do what it was designed to do (foil amateur attempts), and the answer is: no, not so long as it is export-restricted to only 40 secret bits of key. -- David R. Conrad, ab411(a)detroit.freenet.org, http://www.grfn.org/~conrad Finger conrad(a)grfn.org for PGP 2.6 public key; it's also on my home page Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50 Jerry Garcia, August 1, 1942 - August 9, 1995. Requiescat in pace.

1 0

Re: WANTED: anonymous remailer source code
by Alex de Joode 17 Dec '03

17 Dec '03

Quazi sez: : I'm interested in porting some remailer code to work on NT (most : likely using NTMail as the smtp service). I'd like to be sure I'm : starting my port from the most recent revisions, and the sources at : the archive at berkeley seem a bit dated. Are they the latest sources? : Are there more recent sources available somewhere? Try ftp.hacktic.nl:/pub/remailer -- Alex de Joode Fear Uncertainty Confusion and Kaos, Inc.

1 0

I need exportable crypto revisited.
by Darrell Perko 17 Dec '03

17 Dec '03

Greetings; Thank you all for your amazingly quick responses! However, I should have noted in my original message that this encryption is to meet a contractual point for a commercial product to be delivered soon. The product can have one and one only version to be boxed and shipped and will be sold internationally. The encryption portion will be dynamically linked, so real encryption will be available on the net just not in the box. Thanks, Darrell Perko dperko(a)efn.org

4 3

Re: SSL challenge -- broken !
by Pierre Uszynski 17 Dec '03

17 Dec '03

Says Joe Buck: > > >Should some bad person get hold of your card number and misuse > > >it, you're not out any money: > > > > I'm not so sure....Checked the fees/interest lately? > > "There ain't no such thing as a free credit card theft." > > Yes, it's true that this contributes to high interest rates (though > defaults cost more than fraud). Certainly not only that. In fact you pay directly for weak credit card security through taxes used to legislate, police, try, and jail fraudsters. Add to that the cost to society of keeping these people in jail instead of more productive occupations. Add the time wasted straightening out bogus transactions. Add the cost of delaying purchases and action because of the (maybe irrational) fear that no secure payment system is available. The argument that fraud existed before credit cards is only a technically correct statement. It does not bear. The point is, credit card transactions could be much more secure, at sometimes trivial cost, making much fraud disappear. Unfortunately, in this case, insecure credit cards are not an obstacle to banks making money, so why should they care? Credit card fraud does not prevent politicians from being re-elected, so why should they care? Same would apply to car manufacturers: easily stolen cars do not prevent them from making money, so why should they care? When 'bad persons' misuse credit cards, the cost to us is very real, just well hidden by all involved. Pierre. pierre(a)shell.portal.com

1 0

Re: SSL challenge -- broken !
by jordan＠Heuristicrat.COM 17 Dec '03

17 Dec '03

From pierre(a)shell.portal.com Thu Aug 17 18:29:41 1995 Unfortunately, in this case, insecure credit cards are not an obstacle to banks making money, so why should they care? At the risk of sounding like Perry, if you think that the major card issuers "don't care" about cutting (or eliminating) fraud, you're not talking to the right people. Fraud eats away a big chunk of revenue and can quite significantly affect competitiveness in a market with thin margins. /jordan

5 5

use PGP for http encryption instead!
by George P. Magiros 17 Dec '03

17 Dec '03

i don't mean to be extremely brash, but couldn't one use PGP to provide encrypted communication with the web. granted initially everyone with a browser would need there own key to communicate in an encrypted way - at least until such keys could be generated on the fly. since the http "client" format resembles rfc821 message headers and a body, one could easily use a "hal" remailer type "Encrypted: PGP" header line plus hash marks "::" to reassemble a compatible http client command. The same could be done on the server side. -george --- libgpmx(a)gsusgi2.gsu.edu (finger for PGP public key or use MIT keyserver) George P. Magiros Georgia State University Pullen Library PGP fingerprint of 59069039: D6 76 D4 FC 9B 25 6E DD DD 81 58 06 7B CD 03 AE

4 3