December 2003 - cypherpunks-legacy

tsu's bpf
by Mark 17 Dec '03

17 Dec '03

>> Shimomura on BPF, NSA and Crypto: >> >> One of the tools I modified for my work was a sophisticated >> piece of software called the Berkeley Packet Filter. ... >> Unlike the original BPF, my version was designed to bury > ^^^^^^^^^^^^^^^^^^^^^^^ >> itself inside the operating system of a computer and watch >> for certain information as it flowed through the computer >> from the Internet. When a packet from a certain address, or >> for that matter any other desired piece of information >> designated by the user flashed by, BPF would grab it and >> place it in a file where it could be kept for later >> viewing. > >This is *exactly* what BPF does, always did and was designed to do. As >for writing the packets to a file, everything but opening and closing >the file are described in the man page. You could code it in 10 lines. Get off your high horse Julian, he means it's a modloadable version of bpf, much like the modloadable NIT that is also available. There are at least two sniffers that can use both the modloadable NIT and bpf packet interfaces, maybe more. It certainly is easier than recompiling your kernel to include the functionality which is generally the way things were done. I prefer bpf as it is much more efficient, typically 10% of the impact that NIT has on a machine. Some rough figures are a NIT might use one or two minutes of CPU a day to monitor a reasonably quiet network, whilst bpf will only use several seconds cpu time. (Most of the work is hidden in the kernel anyway). Mark

1 0

RSA accellerators on ISA/PCI cards?
by Simon Spero 17 Dec '03

17 Dec '03

Does anybody have any recommendations for a good RSA accellerator available on an ISA/PCI card? I'm looking for something that can be used with numerous public/private keys, though the ability to have one tamperproof key would be a bonus. Thanks Simon ---- (defun modexpt (x y n) "computes (x^y) mod n" (cond ((= y 0) 1) ((= y 1) (mod x n)) ((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n)) (t (mod (* x (modexpt x (1- y) n)) n))))

1 0

Re: Novel use of Usenet and remailers to mailbomb from luzskru@cpcnet.com
by Bryce 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- An entity calling itself ABostick <abostick(a)netcom.com> probably wrote: > > -----BEGIN PGP SIGNED MESSAGE----- (BTW, it verified here.) > > If "digital postage" is ever implemented, this sort of > distributed-origin mailbomb-through-a-remailer would be stopped > immediately. All the messages that the horny net geeks send would > necessarily contain the same postage stamp, and the remailer would > notice this right away -- and throw away messages containing the used > postage stamp. > > One more motivation for e$-like digital postage for remailers. Unfortunately this is not the case. The perpetrator would simply have to convince the horny net geeks to pay their own postage. In fact, it is *in general* impossible to have both anonymity and prevention/control of mail-bombing. Of course digital postage will help the problem somewhat by making the bombers pay for it, and smarter filters on the recipient's end will help, but in general it is a problem we are going to have to live with if we want anonymity. Regards, Bryce PGP sig follows -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.01 iQCVAwUBMPgkE/WZSllhfG25AQFRhwQAnA9teB4oKYONpvSe++VaFR8vqi8t2Zs3 pI+qNPrFMyejrL84Vtwo7GKagUJCabEIYXuZ69X39kDjs3tiRIGllT0cqq9Ijb9Q pog4YklGDDSirnsgfYatkguRA2VWqNPr67hVyQ6KQLHTBHTnW5bfgWrwlT7PyxJ0 f9FOMrqrIPE= =zd6Y -----END PGP SIGNATURE-----

1 0

bad PGP signatures
by Bryce 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Yet another bad PGP signature via e$pam. Date: Sat, 13 Jan 1996 12:13:03 +0600 To: cypherpunks(a)toad.com From: "David K. Merriman" <merriman(a)arn.net> Subject: Re: Digital postage and remailer abuse That's the third today (although the second was fixable by concatenating the Subject: onto one line.) Would everyone please get into the habit of formatting their messages to be much less than 80 columns? All Phil's travails are ill- rewarded when we can't get basic clearsigning to work via mailing lists. (Or if we don't bother to *use* clearsigning via mailing lists, but that is another topic...) On a related subject, cpunks traffic recently alerted me to how effective replay attacks can be against PGP. Don't PGP signatures include a time-stamp from the system clock? I'm going to get into the habit of including a time-stamp in the clear-text from now on. (I have sent so many PGP-clearsigned messages, and many of them quite short, that an attacker could almost hold up my end of a conversation using them. :-) ) Bryce PGP sig follows Sat Jan 13 14:48:23 MST 1996 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.01 iQCVAwUBMPgoy/WZSllhfG25AQGGlgP9HhxLLpfrsyTBc8ed9jjToJnUOl37S+3z 8zac6FJXk+3dsKhXe2UhiKQrLDx6wIodvy+6DkpBNEEWuzkaVlRkZ9QFiDIuKkm2 ixc8HaZ6yJQLKg5NX19vStpwyQGsDx9tCVAM8BtEYXHuzVqb7AuANVmS/EJWd5js yz+pz6COpxE= =PzVY -----END PGP SIGNATURE-----

1 0

FIN_sin
by John Young 17 Dec '03

17 Dec '03

The January 22 New York magazine, a local weekly, reports in "The Money Plane": Five nights a week, at least $100 million in crisp new $100 dollar bills is flown from JFK nonstop to Moscow, where it is used to finance the Russian mob's vast and growing international crime syndicate. State and federal officials believe it is part of a multi-billion-dollar money-laundering operation. The Republic National Bank and The United States Federal Reserve prefer not to think so. "That money is used to support organized crime; it's used to support black-market operations," says one federal official. "In my personal opinion, this is an abomination. Yet it appears that at least part of the federal government sees nothing wrong with it." FINCEN director Stanley Morris is more blunt: "Russia's banking system is a cesspool." FIN_sin

1 0

A pooled e-cash FOIA request
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I agree with Charlie Merritt and Declan that a well-placed FOIA request would be a good thing (tm). I am less interested in the identities of low-level Customs, etc. employees than I am in what orders were given, and which political appointees gave them. This action is an entirely reasonable one to take with regard to *our* employees. As a FOIA request can get a bit expensive, I'd suggest that those of us who are interested try to pool our efforts/$ as we did with the ZLDF. This method seems to have worked, :) and ecash should make it easy... JMR -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Freedom isn't Freeh. iQCVAwUBMPksuW1lp8bpvW01AQGzwwP+I0tKtaE22BjLbFaTNGePqjiFHwHUs3To s43nxKb8jroaCcvVM+5S5g9kl21/nTAqzPRQhk+7jntiQaCduNj7lRJ1dQiYRDgH pFq68ybG1J61zFLaYmbuiMFOjNZD1L6ZemZcd3RFXh7nx4bcnOy1piX5BH1lZTtr iXGNoHO+Xpo= =j5DH -----END PGP SIGNATURE-----

1 0

GNN on Crypto
by Jyri Kaljundi 17 Dec '03

17 Dec '03

Global Network Navigator Web Review (http://gnn.com/wr/) has their main story this week on crypto. The articles are: Spymaster meets webmaster:NSA's Fortezza: stronger encryption or Internet spy strategy http://gnn.com/gnn/wr/96/01/12/features/nsa/index.html The Seduction of Crypto AG: How the NSA held the keys to a top-selling encryption machine http://gnn.com/gnn/wr/96/01/12/features/nsa/crypto.html Familiar faces, familiar places: Look who's working to implement Fortezza in the US and Europe http://gnn.com/gnn/wr/96/01/12/features/nsa/triteal.html What's that smell: Is the NSA sniffing your email? http://gnn.com/gnn/wr/96/01/12/features/nsa/sniff.html A back door for the NSA: Balancing the need for intelligence with privacy http://gnn.com/gnn/wr/96/01/12/features/nsa/conclude.html Juri Kaljundi jk(a)digit.ee Digiturg http://www.digit.ee/

1 0

Hate Speech Ban Metaphor
by Bruce Baugh 17 Dec '03

17 Dec '03

Saw this on news.admin.net-abuse.misc: In article <ebohlmanDL3M0I.B2J(a)netcom.com>, ebohlman(a)netcom.com (Eric Bohlman) wrote: <snip> :Banning this sort of discussion accomplishes nothing positive. It :creates the *appearance* of having fought bigotry without actually having :done so. It doesn't address the problem, it sweeps it under the rug, and :bigotry that's been swept under the rug has a nasty habit of catching :fire. Banning hate speech is sort of like sending a business card to :Craig Shergold; it lets you feel like you've done your good deed for the :day, even though you really haven't. <snip> That gets _my_ vote for metaphor of the day. Bruce Baugh bruceab(a)teleport.com http://www.teleport.com/~bruceab

1 0

How to make someone else lose ecash
by Ian Goldberg 17 Dec '03

17 Dec '03

I don't recall seeing this on cypherpunks or on ecash(a)digicash.com; it's being sent to both places, so set your replies appropriately. Dave and I were discussing the ecash protocols when we discovered what seems to be a way for Eve (a passive eavesdropper) to cause anyone to lose money. Note that she doesn't gain anything from it. Eve watches for any message that contains pcoins (a list of onl_coin). These messages are the Payment (from user to shop) and Deposit (from shop to mint). Neither of these are required to be encrypted. An onl_coin is the following: onl_coin = [ int keyversion ; low 5 bits are denomination MPI n ; coin number MPI sig ; encrypted coin signature ] sig is (f(n)^(1/h) XOR f(payment_hdr)), encrypted in the mint's public key. The reason sig is encrypted is so that the payment header can't be changed and so that Eve can't learn f(n)^(1/h). However, n is sitting there all nice and cleartext. Therefore: when Eve sees such a message, she uses the same value of n to withdraw a coin from her bank account, and then spends it (she could just pay it to herself). Eve does not gain or lose anything, but if she can deposit the coin before the original coin that she saw gets to the mint, the original coin will not clear. If Eve has the ability to drop or delay packets, she can accomplish this easily. The result is that whoever withdrew the coin originally has lost the use of that coin. Note that this is the same problem as if two users just happen to use the same value of n when they withdraw coins. We don't really care about that, since the probability is trivial. However, this attack lets Eve produce the same effect _on purpose_. How can we prevent this? Well, since a shop has no way of using the value n except for just sending it on to the mint, we lose nothing by encrypting it. Thus, an onl_coin should be: onl_coin = [ int keyversion ; low 5 bits are denomination Encrypt_with_mint_public_key( MPI n ; coin number MPI sig ; (f(n)^(1/h) XOR f(payment_hdr)) ) ] Note that it's not really necessary to have sig already encrypted if we're going to encrypt it again. Actually, I think an onl_coin should have an additional field (bankID) to the fields listed above, but that's another argument for another time. - Ian "Back from the North and ready to party!"

1 0

Re: A pooled e-cash FOIA request
by cmerritt＠intellinet.com 17 Dec '03

17 Dec '03

Jim Ray said in part: >a well-placed FOIA >request would be a good thing (tm). I am less interested in the >identities of low-level Customs, etc. employees than I am in what >orders were given, and which political appointees gave them. >As a FOIA request can get a bit expensive, I'd suggest >that those of us who are interested try to pool our efforts/$ as >we did with the ZLDF. This method seems to have worked, :) and >ecash should make it easy... I'm ready. I'm willing to put in some bucks. We need a lawyer, a [virtual] center. I think the easiest part to get would be a financial accounting (partial I bet). I'm sure the DOJ has a (cya) policy of never identifing goons of a failed persecution. It has been suggested to me that individual law suits against the the low level people that CAN be identified might be an approach. Sue for violation of constitutional rights. The depositions would work like a grand jury invrestigation. "Well, Agent Smith, if you were just following orders WHO gave them to you?" Sue your way up the line. Lotsa Ebucks :-(

2 1