March 2003 - cypherpunks-legacy

Re: CHAUM CHIMES IN
by cme＠ellisun.sw.stratus.com 17 Dec '03

17 Dec '03

>Date: 08 Sep 93 16:30:55 EDT >From: Sandy <72114.1712(a)CompuServe.COM> >Subject: CHAUM CHIMES IN >Message-Id: <930908203054_72114.1712_FHF95-2(a)CompuServe.COM> ..From: > SANDY SANDFORT Reply to: ssandfort(a)attmail.com [ . . . ] >Of course, the next letter to the editor calls for the adoption >of systems to track every vehicle at all times. The genius who >wrote the letter, thinks it would be a good way to prevent >nuclear, biological or chemical terrorism. Geeeeez. It was signed by Dorothy Denning, right? Actually, they should take that to its full conclusion. We need implants in every individual, broadcasting to the local surveillance agency, giving not only location but also every word spoken in the vicinity. It could also do a chemical analysis of the air in the neighborhood. It should also have a radiation counter. It should also monitor the host body, looking for signs of anger or sexual arousal? How else will we be guaranteed safe from mad bombers, rapists and child molesters? How else will our big budget LE agencies be able to protect us? I know. When it's finally adopted, worldwide, they'll call it the Ellison Plan. :-( - Carl

2 1

Stegno and DAT and digital music...
by Peter Wayner 17 Dec '03

17 Dec '03

In this week's Sunday NYT, Hans Fantel, their music guy, writes at length about the new "dithered" CD's and how the guys have improved the sound. He says that the original CD format was limited to 16 bits of sound because of costs. But many audiophiles reacted very negatively to the tinny, metalic quality to the music. For this reason, the companies have developed 20 bit DAT recording tape and then come up with ways to "dither" this into 16 bits. I am curious if anyone knows the details of these algorithms. Also, his point suggests that flipping the least significant bit of 16 bit music may not be imperceptable to some ears. If the classical music starts to sound tinny then there might be something subversive in the least significant bits. -Peter Wayner

2 1

Remail: errors
by HFinney＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have been out of town for the last week, so I missed some CP mail. It looks like some good things are happening with remailers, though. Kudos to Karl, Sameer, and the others for their work! I have received many messages to my remailer in the last week which came from remail(a)tamsun.tamu.edu, which were PGP-encrypted apparently in an effort to get my remailer to send them. They did not work, though, because there was no "Encrypted: PGP" header to trigger the remailer's decryption. This can be arranged by creating the message something like this: ======================================================== :: Request-Remailing-To: hfinney(a)shell.portal.com :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- <rest of message> - -----END PGP MESSAGE------ ======================================================== This would then be sent to remail(a)tamsun.tamu.edu. I don't know whether the multiplicity of such erroneous messages is just due to one person stubbornly re-trying, or whether there is an error in one of the new programs for creating chained remailer messages. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLJaNuKgTA69YIUw3AQHrNwQAowMEQwuH6YyHoj6T7AqZFLNdTf+eqJ9L LhAatHS94nmC1smkfVNq0dZmigmkvBdMNEPlBZemmxALz+KJw6OSY/ULSBmuVNEq 5rJANh3XimoJWqLISy2lZiuC5Fw2R7UvRadcdM94pncSVvev92Fyf7CqEOOtrGAK PUzRds7BVNo= =FpLa -----END PGP SIGNATURE-----

2 1

more than spread spectrum
by cme＠ellisun.sw.stratus.com 17 Dec '03

17 Dec '03

There are alternatives to spread spectrum, if we're threatened with loss of freedom to communicate. We could lay our own wires/fibers. We could set up a mesh network of infrared lasers through the air. Last time I looked, there were no laws against shining lights out your window as long as they didn't bother anyone. An infrared laser could hardly bother anyone. We could produce a line of cheap cards to plug into a PC which would do packet routing, using a variety of physical links -- our own wires, lasers, very low range radio, .... Each card would connect to three or more neighbors and become part of the global mesh. Adaptive routing with no global map would suffice for the card and would keep the whole system peer-to-peer with no need for central control and no chance for central tapping. Of course all of these solutions require a high density of users. A college campus might be the right place to start. We could then branch out to cities. I suspect that a place like Chicago or NYC with high rise apartments might be the place to start -- many options for line-of-sight communications. The benefit isn't just for Cypherpunks. It's a free network for the masses -- like the original USENET (with each user donating routing and store/forward) but with unrestricted, low-range, continuously operating physical links. I'll volunteer to do the software for the node card. Does anyone have hardware design/fab to donate to the effort? - Carl

4 3

Re: art can make a difference, and traffic routing games
by Bill Stewart 31 Mar '03

31 Mar '03

At 09:42 AM 03/31/2003 -0800, Major Variola (ret) wrote: >PS Bill: How did management like the news >channels calling the Baghdad CO an "AT&T Building" :-) I didn't catch that one, but as the token phone company guy here, the fact that they started off Desert Scam by blowing up the phone company building with a cruise missile did piss me off... What our management _does_ need to clue into is the recent Michigan law banning VPNs/NAT/routers/etc. - the similar laws proposed in a number of other states only applied in cases of fraud or theft of service, but the Michigan one was badly worded.

1 0

GPS phones confiscated from reporters in Iraq
by R. A. Hettinga 31 Mar '03

31 Mar '03

http://www.newscientist.com/news/print.jsp?id=ns99993567 New Scientist GPS phones confiscated from reporters in Iraq 15:26 31 March 03 Will Knight Satellite phones with built-in Global Positioning System (GPS) capabilities have been confiscated from journalists travelling with US troops inside Iraq, due to fears that they could inadvertently reveal their positions. Reporters "embedded" with the troops have been asked to hand over satellite telephones operated by Thuraya Satellite Telecommunications, a communications company based in Abu Dhabi. The restriction is limited to units near the war's front-line and is expected to be temporary, a spokesman for US central command in Qatar told New Scientist . A spokeswoman for the US Department of Defense added that reporters with unaffected satellite phones would be asked to share them and that military communications equipment would be made available when possible. Replacement phones could also be sent to the front line. Richard Langley, a GPS expert at the University of New Brunswick, Canada, says US military commanders may be concerned that positioning information embedded in signals sent by the Thuraya phones could be intercepted and used by Iraqi forces to locate and attack US troops. "It's not impossible, although it would be rather difficult," Langley told New Scientist . "The signals are line-of-sight [from handset to satellite] so very little would leak out and be interceptable on the ground." Ground station intercept It would be easier to intercept the signal as it arrives from the satellite at the network operator's ground station, he says. But even in this case, any interceptor would still have to crack the encryption protecting the signal. An alternative concern is that the US military are worried that computers used to store call information are vulnerable to cyber attack. "Perhaps the concern was that there would be a log of these positions kept on a computer somewhere," Langley says. Positional information captured by any means would only be useful for as long as the caller remained in the same place, he notes: "Anyone wanting to use the information would have to work quickly." Thuraya telephones can connect to GSM mobile phone networks when they are available, and a satellite network when in more remote areas. The phones can also be used as a GPS receiver, determining its position by communicating with satellites in the GPS constellation. If the GPS functionality is switched on, the caller's co-ordinates are automatically embedded in the voice signal sent to the communications satellites. -- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Re: Brumley & Boneh timing attack on OpenSSL (fwd)
by Eugen Leitl 24 Mar '03

24 Mar '03

Some clarification by Peter Gutmann <pgut001(a)cs.auckland.ac.nz> on why cryptlib doesn't do timing attack resistance default: Peter Gutmann <pgut001(a)cs.auckland.ac.nz>: cryptlib was never intended to be a high-performance SSL server (the docs are fairly clear on this), and I don't think anyone is using it to replace Apache or IIS. OTOH it is used in a number of specialised environments such as closed environments, embedded systems and mainframes. For example two real-world uses of the cryptlib SSL server are in embedded environment A and mainframe environment B. In A, the processing is handled by a low-power embedded processor. It takes 10-15s to perform an SSL handshake, and that's after the code has been optimised to death to squeeze every possible bit of performance out of it. Performing the necessary 1.5M queries at 15s each would take approximately 8 1/2 months at 100% CPU load (meaning that the device is unable to perform any other operations in that entire time). This is unlikely to go unnoticed, given that it's polled from other devices for status updates. In B, CPU resources are so scarce that the implementation uses null cipher suites because it can't afford the overhead of even RC4 for encryption (admittedly this required a custom code hack, cryptlib doesn't normally support null encryption suites). After about 100 or so attempts at a full SSL handshake, klaxons would sound and blue-suited troops would deploy onto the raised flooring to determine where all the CPU time is going. In neither of these environments (and various similar ones) would a side- channel attack requiring 1M or so queries (e.g. this one, or the Bleichenbacher attack, or the Klima-Pokorny-Rosa attack, which cryptlib shouldn't be vulnerable to since I'm paranoid about error reporting) be terribly feasible. OTOH blinding does produce a noticeable slowdown for a process that's already regarded by its users as unacceptably slow and/or CPU-intensive (I have some users who've hacked the key-exchange process to use fixed shared keys because they just can't spare the CPU time to do a real handshake, e.g. by injecting the shared key into the SSL session cache so you just do a pseudo-resume for each new connection). For this reason, cryptlib makes the use of sidechannel- attack-protection an optional item, which must be selected by the user (via use of the blinding code, now admittedly I should probably make this a bit easier to do in future releases than having to hack the source :-). This is not to downplay the seriousness of the attack, merely to say that in some cases the slowdown/CPU consumption vs.attack risk doesn't make it worthwhile to defend against. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Re: Brumley & Boneh timing attack on OpenSSL (fwd)
by Bill Stewart 24 Mar '03

24 Mar '03

At 09:51 AM 03/22/2003 +0100, Eugen Leitl wrote: >Some clarification by Peter Gutmann <pgut001(a)cs.auckland.ac.nz> on why >cryptlib doesn't do timing attack resistance default: > >Peter Gutmann <pgut001(a)cs.auckland.ac.nz>: >cryptlib was never intended to be a high-performance SSL server (the docs are >fairly clear on this), and I don't think anyone is using it to replace Apache >or IIS. OTOH it is used in a number of specialised environments such as >closed ... > For this reason, cryptlib makes the use of sidechannel- >attack-protection an optional item, which must be selected by the user >(via use >of the blinding code, now admittedly I should probably make this a bit easier >to do in future releases than having to hack the source :-). This is not to >downplay the seriousness of the attack, merely to say that in some cases the >slowdown/CPU consumption vs.attack risk doesn't make it worthwhile to defend >against. If it's not meant to be a high-performance server, then slowing it down another 20% by doing RSA timing things is probably fine for most uses, and either using compiler flags or (better) friendlier options of some sort to turn off the timing resistance is probably the better choice. I'm not sure how flexible things need to be - real applications of the openssl code include non-server things like certificate generation, and probably some reasonable fraction of the RSA or DH calculations don't need to be timing-protected, but many of them are also things that aren't CPU-consumption-critical either. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Keysigning @ CFP2003
by Douglas F. Calvert 24 Mar '03

24 Mar '03

GPG/PGP Keysigning @ Computers, Freedom and Privacy 2003 April 2nd, 9:45pm (First BoF Session) I will be organizing a keysigning session for CFP2003. Please submit your keys to cfp-keys(a)anize.org and I will print out sheets with key information in order to speed up the process. Bring a photo ID and a copy of your key information so that you can verify what is on the printout. A list of submitted keys and a keyring will be available on: http://anize.org/cfp2003/ Thank you... -- + Douglas Calvert dfc(a)anize.org http://anize.org/dfc/ + | Key Id 0xC9541FB2 http://anize.org/dfc-keys.asc | | [X] User wants to receive encrypted mail | +| 0817 30D4 82B6 BB8D 5E66 06F6 B796 073D C954 1FB2 |+

1 0

Re: Spammers Would Be Made To Pay Under IBM Research Proposal
by Steve Schear 24 Mar '03

24 Mar '03

>Spammers Would Be Made To Pay Under IBM Research Proposal > >By Tony Kontzer, InformationWeek, InternetWeek >Mar 20, 2003 (8:45 PM) >URL: http://www.internetweek.com/story/showArticle.jhtml?articleID=7900141 > >Companies and consumers alike have been looking to two primary aids in the >battle to stem the flood of spam. On the practical side, they're turning >to a seemingly endless parade of filters and other software products >designed to slow the tide of unwanted E-mail by doing things such as >checking messages against known spam, using textual clues to glean whether >a message is spam, or blocking the IP addresses of known spammers. On the >more hopeful side, they're pressuring legislators for federal laws banning >spam. > >IBM researchers say both approaches miss the target--that the software >approach amounts to a constant game of trying to stay one step ahead of >spammers, while legislation, if and when it comes, won't be able to >address spam coming from outside U.S. borders. As a result, they've come >up with another approach: Make spammers pay to send messages. It sounds >absurdly simple, and Scott Fahlman, a research staff member at IBM's >Watson Research Center, says it is. Fahlman is trying to build momentum >behind a concept he's calling the "charity stamp" approach, which would >force anyone sending unsolicited messages to pay to reach recipients >participating in the program unless they had an authenticated code. >Of course none of this is news to many readers on this list. A number of >people in the crypto/cypherpunk community (e.g, Adam Back, Eric S. >Johansson and Ben Laurie) have worked for some time to develop the >mathematics and code to launch proof-of-concept e-stamp systems based on >either Proof-of-Work algorithims or real value. Recently Microsoft also >unveiled a similar project PennyBlack >http://research.microsoft.com/research/sv/PennyBlack/ steve --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0