December 2003 - cypherpunks-legacy

Re: Important Digital Cash Question...
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>I think that the bankers name should be Ethel however. > > Phill Wait, wait! I have another one. I call digital cash bankers "underwriters", because they're basically underwriting digital certificates, like an underwriter in the capital markets does. So, we need a "U" name... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

3 2

DOD_com
by John Young 17 Dec '03

17 Dec '03

10-30-95. Wash Rag: "Pentagon Plans More Espionage. Business Fronts Abroad Would Expand Efforts Of a Unified Service." The Defense Department has merged its separate covert intelligence operations and plans to expand its espionage abroad, starting with establishment of phony businesses overseas as cover, and has formed the Defense HUMINT (Human Intelligence) Service, or DHS. Under the fiscal 1996 intelligence authorization bill, the DHS has been given a trial period of three years to carry on commercial activities "to provide cover security to intelligence collection activities undertaken abroad." The authority "to provide bona fide commercial cover," was so that DHS's covert operatives could "withstand detailed investigation by hostile foreign intelligence services as well as domestic scrutiny." ... scandal of the Army's Yellow Fruit op ... CIA case officers are working with DHS on the cover companies abroad; cooperation is needed because in recent years military spies overseas inadvertently had set up relations with foreigners known to be double agents. Sen. Bob Kerrey called on CIA Director John M. Deutch to "develop his human collectors, planning 10 or more years in advance for their peak usefulness," a reference to placing them abroad under deep cover for use in future crises. DOD_com (8 kb)

1 0

/dev/random for FreeBSD [was: Re: /dev/random for Linux]
by Mark Murray 17 Dec '03

17 Dec '03

> > > On this same track, I suggest that "/dev/random" devices for unix are > > > an excellent idea. Ted Tso did one for Linux that steals all the bits > > > of semi-random timing information it can. > > > > Anyone know where I can find more information on this wonderful device? > > I've just sent patches (versus the Linux 1.3.28 kernel) off to Linus. > There's a fairly long exposition at the beginning of > drivers/char/random.c which explain its theory of operation. A colleague drew my attention to this, and I was so pleased with it that I ported it to FreeBSD. I kept the interface as close to the original as I could, but made some changes for efficiency and ease: 1) I turned the huge comment at the top explaining the theory of operation into a man page (random(4)). 2) We felt that hooking all interrupts might be dangerous. IDE drives can interrupt at a heck of a rate, and so can some serial ports, and we felt that in these cases _not_ using the interrupt was a good idea. So I added an ioctl to allow the superuser to select his own set, appropriate to the hardware in use. It is nearly impossible to do this automatically. Gimme a yell if you want copies :-) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark(a)grumble.grondar.za for PGP key

2 1

Re: CJR returned to sender
by James A. Donald 17 Dec '03

17 Dec '03

At 10:16 PM 10/30/95 -0800, Jeff Weinstein wrote: > It [CJR application for T shirts] will force the bureaucrats > to make a decision, You cannot force bureaucrats to make a decision. They will act if it suits their purpose, and otherwise they will not act. Basic of principle of strategy in Go: If you give the other guy choices, you will lose. That is why go players always play asymmetrically if the stones are symmetric. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Keyed-MD5, ITAR, and HTTP-NG
by Simon Spero 17 Dec '03

17 Dec '03

To summarise: the consensus is that using keyed-MD5 for authentication is ok under ITAR, but using it for confidentiality is out. The reason I wanted to check is that I'm solidifying some of security paramaters for HTTP-NG so we can add them to the test implementation before the Dallas IETF. In addition to the slight problem of having half the development team on the other side of the Atlantic, I want to make at least a subset of the security schemes mandatory, and that means making the core stuff exportable. At the moment, I'm thinking of making the mandatory schemes be Keyed MD5 for authentication, and weakened RC4 with an IV for confidentiality, with the added stipulation being that the user must be informed when key weakening is being used. I may swap RC4 for DES; they're both public domain, but RC4 is simpler. They're both shared key, but I don't make PK stuff mandatory. The other pre-defined schemes I'm planning on getting at least speced are 3-DES and IDEA for confidetiality, SHA for hashing, and RSA & DH for key exchange, signatures, and authentication. Certificate format is currently X.509- PGP format will go in ASAP. 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))))

10 13

Re: Don't Kill the Messenger--A New Slant on Remailers
by Rev. Mark Grant 17 Dec '03

17 Dec '03

On Sun, 29 Oct 1995, Bill Stewart wrote: > More of a problem with this system is that it's only useful for terminal > remailers; to use it in the middle of a chain, the next remailer would > need to be configured to auto-accept such messages, or else your remailer > would need to have a list of known remailers and use direct delivery > for all mail sent to them. That's not a problem with Mixmaster, as it already knows whether the message is the last hop of a chain or not. I was hoping to get my hack finished this weekend, but got caught up in CTCP instead (which I'll release once I find out why it kills my xterm on exit 8-().. Mark

1 0

Keyed-MD5, and HTTP-NG
by baldwin 17 Dec '03

17 Dec '03

Simon, There are a few different ways to add key material to MD5 to make it suitable as a shared-secret authenticator function. Some of these are less resistant to attacks than others. For example, the keyed MD5 mechanism that is part of the current IPsec specifications can be attacked using 2**60 chosen messages. Fortunately, the IPsec specs also require that the shared MD5 key be changed every 2**32 messages, so this attack is unlikely to succeed. Specifically, IPsec uses MD5 as follows: X = MD5(key | keypad | Message), where "|" means concatenation and the "keypad" pads out the key to 512 bits. Basically, this function is the same as standard MD5 with a different initialization vector for the compression operation on the first block of the message. RSA Labs recommends that a people use an authenticator like X = MD5(key1, MD5(key2, Message)). This resists the chosen plaintext attacks that were published at the crypto conference in Spring 1995. There are also some very fast MAC algorithms being proposed these days. As Phill Hallam mentioned, you may want to look at the work of Phil Rogaway. At a minimum, make sure that your standard allows people to migrate from a current solution based on MD5 to a future solution based on new functions. However, I would be relunctant to require new functions until they have had a chance to be tested by the cryptographic research community. --Bob Baldwin

3 2

[joanne@theory.lcs.mit.edu: MIT TOC SEMINAR--DAN BONEH--Thursday, November 2--4:15pm!!]
by lethin＠ai.mit.edu 17 Dec '03

17 Dec '03

From: joanne(a)theory.lcs.mit.edu (Joanne Talbot) Date: Mon, 30 Oct 95 12:23:33 EST To: theory-seminars(a)theory.lcs.mit.edu Reply-To: theory-seminars-request(a)theory.lcs.mit.edu Subject: MIT TOC SEMINAR--DAN BONEH--Thursday, November 2--4:15pm!! MIT TOC SEMINAR Thursday, November 2, 1995 Refreshments at 4:00pm, Talk at 4:15pm in NE43-518 ``Quantum Cryptoanalysis of Hidden Linear Forms'' by Dan Boneh Princeton University ABSTRACT Recently there has been a great deal of interest in the power of Quantum Computers. The driving force is the recent beautiful result of Shor that shows that discrete log and factoring are solvable in random quantum polynomial time. We use a method similar to Shor's to obtain a general theorem about quantum polynomial time. We show that any cryptosystem based on what we refer to as a `hidden linear form' can be broken in quantum polynomial time. Our results imply that the discrete log problem is doable in quantum polynomial time over any group including Galois fields and elliptic curves. Joint work with Richard Lipton. Host: Shafi Goldwasser

1 0

Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
by Mark Murray 17 Dec '03

17 Dec '03

> Date: Mon, 30 Oct 1995 20:16:24 +0200 > From: Mark Murray <mark(a)grondar.za> > > A colleague drew my attention to this, and I was so pleased with it that > I ported it to FreeBSD. > > Which version did you grab? More recent versions of the driver use a > more efficient mixing algorithm suggested by Colin Plum. There's also > the beginnings of support for user-mode deamons to add randomness into > the random pool by writing to /dev/random. I also added support for > reading the instruction timing register for x86 platforms that support > it. Version 0.92 21st Sept 1995. Something I didn't mention earlier; we felt that letting the unwashed masses read /dev/*random was not a good idea, as they could deplete the pool of entropy all to easily for attack purposes. For the same (or similar) reason, giving the said unwashed masses _write_ privelige might allow them to set /dev/*random to a known state. You've probably already thought of this, but I just had to say it :-). > 2) We felt that hooking all interrupts might be dangerous. IDE drives can > interrupt at a heck of a rate, and so can some serial ports, and we felt > that in these cases _not_ using the interrupt was a good idea. So I > added an ioctl to allow the superuser to select his own set, appropriate > to the hardware in use. It is nearly impossible to do this automatically. > > Indeed; I can't emphasize this enough. The clock interrupt, for > example, is a very bad irq to try to use. In the Linux driver, only > device drivers who register their interrupt driver with the > SA_SAMPLE_RANDOM flag actually have the interrupt timings sampled for > the random number generator. (Hmm.. Thinks of ways of doing something similar. I'm not functioning too well right now.) > People have suggested using making it possible to select at run-time > which interrupts to sample, instead of at compiling it into the device > drivers. I've generally not been convinced this is a good idea, because > most system administrator won't likely know which irq's are good and > which are bad for random number generation. For example, although it > may not be obvious, the network interrupt may not be a good choice, > since an adversary who is monitoring the ethernet cable can make a > pretty good guess about the timing of your network interrupts, and hence > what the likely inputs are to the random number pool might be. Are you sure about this? The stochastisity if this would be pretty hefty. Not only would our attacker have to get the _time_ that the interrupt occurred (if it interrupted our machine), he would then have to process in brute-force mode all possible times in his error range. What is more, more interrupts are coming in... > Gimme a yell if you want copies :-) > > Sure, why not. I'd be interested to see what you did. Hokay! Please also send me _your_ latest. (BTW - did Linus put it in his latest kernel?) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark(a)grumble.grondar.za for PGP key

3 2

Re: Keyed-MD5, ITAR, and HTTP-NG
by Rich Salz 17 Dec '03

17 Dec '03

>At the moment, I'm thinking of making the mandatory schemes be Keyed MD5 >for authentication, and weakened RC4 with an IV for confidentiality, with >the added stipulation being that the user must be informed when key >weakening is being used. I may swap RC4 for DES; they're both public >domain, but RC4 is simpler. They're both shared key, but I don't make PK >stuff mandatory. The licensed version of RC4, or the software that was posted anonymously? Do you really feel comfortable basing an IETF standard on that? When you use the term RC4 do you mean the real version or the posted one, what will you do if they ever conflict? Can you even use the name RC4 for the posted version? It seems to me that RC4 means the RSA licensed code, which presumably you wanted to avoid when you wrote no mandatory PK. Where would you swap RC4 for DES? I assume your added stipulation is a "should" not a "must" item. How are you going to handle key management and naming? /r$

2 1