- cypherpunks-legacy - lists.cpunks.org

Re: Solution for US/Foreign Software?
by jim bell 17 Dec '03

17 Dec '03

At 06:28 PM 12/6/95 -0600, you wrote: > >Bill Stewart writes: > > I had interpreted the suggestion differently - rather than a system with > > user-accessible crypto hooks, the manufacturer could ship a binary patch > > upgrade for US customers to install. The internal design would presumably > > have crypto hooks (i.e. subroutine calls); they can't ban that. > >No, they can't *ban* it, but there's no reason to suspect that they >won't revoke the export license after the scheme becomes clear. And >of course the patch itself would not be exportable. If there's a >"wink wink nudge nudge" implication that the patch would make its way >overseas, I don't understand why that's really any more likely than >the US-only version getting out. It isn't that it's "more" likely. It's probably JUST AS likely. But remember, the goal is to allow the US company to actually MAKE MONEY, not to bootleg its products. The system I've described would be intended to allow a manufacturer to continue to sell its exportable product legally.

1 0

Re: GAK
by Daniel Miskell 17 Dec '03

17 Dec '03

Scott Binkley writes: >I heard a while back about being able to "split" up a PGP key. What >about >splitting up the key into many parts, and giving them out to multiple >INDEPENDANT >agencies. ie: One piece goes to the FBI, one to the NSA, one to some >other committee, and >so on. That way, no goverment body could just tap your conversations >without getting >approval from others, and gaining the pieces of your key. > >just a thought Why give them your key in the first place? Personally, I wouldnt trust any government agency with even a fraction of my key - what makes you think they arent *allready* working together? Then you have effectively given your key, and all of your private mail, to the government, no restrictions. --- _________________________________ *!Cheese Doctrine:!* Though cultured over time, and aged to perfection, one must not yield to produce mold. One must also not belittle themselves by conforming to the "whiz", but melt over the unprocessed ideas of Ghuda. _________________________________

1 0

NIST GAK, Escrow Agent Criteria available
by pfarrell＠netcom.com 17 Dec '03

17 Dec '03

At the meeting, the NIST/NSA folks presented their criteria for being an acceptable escrow agent criteria. They had hardcopy, and Geoff had slides. The slides didn't exactly match the hardcopy. I have typed in the text from my hardcopy. It is on my clipper2 page (which is under construction at <a href="http:/www.isse.gmu.edu/~pfarrell/nist/clipper2.html">) url for the criteria for escrow agent entities is <a href="http:/www.isse.gmu.edu/~pfarrell/nist/escagent.html"> I will _not_ post it (about 4 pages) to the list. If you can't use the web, email me and I'll forward a copy. I've got some notes on Geoff's presentation that I'll post later on. Pat Pat Farrell grad student http://www.isse.gmu.edu/students/pfarrell Infor. Systems and Software Engineering, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer

1 0

re: Re: Secret Clearance (was: re: NIST GAK export meeting, sv)
by Christopher Kleiman 17 Dec '03

17 Dec '03

Bill Stewart <stewarts(a)ix.netcom.com> said: >>BS> secret clearances are _expensive_, usually take a long time to get, >>BS> and the military only gives them to people who need them. > Strange, the military processed a SECRET clearance on me even >before I signed on the dotted line. Now a TS, that's expensive, but >they didn't have much on me other than my SSAN and, I think, my prints >to process the SECRET, so they couldn't have done much more than run be >through the FBI criminal database. >#include <disclaimer.h> /* Sten Drescher Actually, you filled out some paperwork when you signed up that was sent forward; it wasn't much more than a check against all of the govts "evil type people" databases. However, I understand that it depends on what Level of background check as well. A limited background investigation involves filling out a long form saying that you've been a good boy/girl; it goes up from there. "Civilians" are different from military as well; after all, in one they own you, in the other, you can actually go home at night.;-) ** Nothing I say can be held as the viewpoint of my employer; I'm a short-timer any, so I really don't care what they think! Chris **

1 0

Re: Still more on the Digicash protocol
by Hal 17 Dec '03

17 Dec '03

From: Mark Twain Ecash Support <support(a)marktwain.com> > Let us contemplate in which type of situation the payee will send such a > wildcard coin. To pay a shop via TCP? No. The payment request comes in with > the shop ID. The resulting payment won't be done with a wildcard coin. > > So when will the user pay with a wildcard coin? To make a payment to a party > that is (pseudo-) anonymous to the payor. That is, if the payor sends the > payment via anonymous remailer, in which case the messages should be > encrypted anyway. There might be some situations where it is useful to send a wildcard coin even via a TCP connection. For example, a pseudonymous server might pop up at some internet address different from its real one, make some transactions, and then go away. Or someone might set up an anonymous account at some public server (like c2.org) and conduct business anonymously on an ongoing basis. In either case the payee would be anonymous to the payor even though they communicated via TCP. The shop would have to send its payment request using "@" as the shop_accID field (I have heard of an undocumented "-X <payee>" switch in the Unix ecash program which allows the shop software to control this field in the payment request). We have also discussed the "pipe-net" which would allow anonymous TCP connections. This does not look like it can be as secure as the remailer net but for occasional or short-term use it can provide considerable privacy protection. I am glad that DigiCash supports this type of cash which anyone can deposit. Actually, I am surprised and puzzled that it does, given Chaum's apparent reluctance to endorse schemes to allow payee anonymity (due to political problems, apparently). It would be interesting to hear how DigiCash envisions this feature being used, and whether they plan to continue to allow it. Since it is not well documented (if at all) it's possible that they don't plan to keep it. But if they do, I think it would be good to adapt the protocols so this feature is usable over TCP connections. Hal

1 0

Re: FW: websurfer 4.6
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

On 7 Dec 95 at 18:06, Enzo Michelangeli wrote: > On Sat, 2 Dec 1995, Michael Froomkin wrote: > > > so much for compatibility....guess I'm sticking with netscape > > for now. > > These guys at Netmanage's support seem to confuse Trumpet's > version number with the Winsock version... Trumpet 2.0b (as, > AFAIK, any other Winsock package presently available) is > Winsock 1.1 compliant. Not surprising. They confuse random doodling with software, too. The real problem with NetManage is a severe case of brain death. The Sampler TCP/IP sucks, the paid-up TCP/IP is so-so, but of the clients, only ftp is fair, and the rest bite. All the NetManage clients I've tried crater, Mail can't rebuild its index structures if they are corrupted (uh, what was it that rebuild was supposed to do, Harvey?), the version of WebSurfer I evaluated took longer and longer to load and shut down, revealed on inspection to be due to loading/storing a very wordy global history in its, ahem, config file! Delete it and your config is gone. I wouldn't concern myself with what crypto is or isn't in a NetManage product -- they are not players as far as I'm concerned. They've been riding the wave of their TCP/IP not crashing as often as some others, but otherwise they're vacuum packed, untouched by coherent human thought.

1 0

Re: 1)Age etc CA 2)Swedish Digicash
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"jk(a)digit.ee" "Jyri Kaljundi" 7-DEC-1995 12:45:37.27 What about Estonia :) The taxes are low, there are a very few government regulations, the currency is very stable (based on German mark) ... One interesting law in Estonia is that the state budget must be balanced, so there is no way for the government to spend more money than it really has. Technological level here is also quite good, and Internet is more popular than in any other Eastern Europe or ex-USSR country. I think Estonia is an ideal place for such projects: high-tech companies testing their new technological ideas, inventions and business assumptions in real-life conditions. Just get yourself here ! -------- The various Eastern European countries have been targeted before as banking secrecy (read tax haven in the Feds' opinion) countries. Some others might include Malta, although the Catholic influence there may make pornography-related ventures problematic. On the other hand, using Malta would make the conspiracy theorists go nuts... -Allen

1 0

Re: Solution for US/Foreign Software?
by jim bell 17 Dec '03

17 Dec '03

At 10:26 AM 12/7/95 -0600, you wrote: >jimbell(a)pacifier.com (jim bell) said: > >jb> 1. Write a program limited to keysize, carefully constructed to >jb> isolate those portions of the program which define key size, >jb> GAKedness, etc. > >jb> 2. Get it export approved. Export it. > >jb> THEN > >jb> 3. Announce that a "US-only" version of the same program is being >jb> released, and include the minimal component which replaces the >jb> limited software. Release it, only in the US of course! > > As has been pointed out, this would prolly doom geting export >approval for version 2.0. However, let's keep the developer/publisher >out of the loop. How about someone developing a 'binary diff', using >the functionality of nm to find subroutine entry points, and then doing >the binary diff from those starting points? Presumably, for most of the >program the diff would mostly be changed entry points, with the bulk of >diff being the crypto module. Then the bdiff gets exported, and >bpatch-ed into the export binary. Of course, this wouldn't work if they >strip the binary, but who is going to force them to do that? Okay, that was basically what I was suggesting. A full binary difference file wouldn't even need to have any information about the internals of the program anyway. Basically, what needs to be achieved is a way to allow the software manufacturer to sell an approved product outside the country, but allow the foreign buyer to (easily) convert it into a GOOD encryption product. Once that works, laws against the export of encryption are meaningless. In fact, the legally-exported program obviously wouldn't even need to HAVE encryption in it at all, so it won't fall under ITAR classification, and thus won't need any kind of export license.

1 0

Re: Still more on the Digicash protocol
by daw＠guaymas.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <Pine.3.89.9512071804.A21520-0100000(a)unicorn.com>, Rev. Mark Grant <mark(a)unicorn.com> wrote: > I think he means you shouldn't use a stream cipher like RC4 that XORs the > plaintext with the generated keystream, since if you know part of the > plaintext, you can XOR those bytes with (the id you want) XOR (the id > being sent) and change the encrypted data so that the payment goes into > your account and not theirs. Right. RC4 encryption doesn't provide message integrity. And I should mention that block ciphers like DES in chaining modes like CBC don't provide message integrity either -- it's a bit harder, but an active attacker can still tamper with the ciphertext to modify the plaintext in a predictable way, like with RC4. I admit it's a more difficult to mount this attack against a block cipher in chaining mode, and the success probability may go down (depending on the circumstances), but hey! paranoia is your friend; and my point remains valid: Don't count on encryption to give you message integrity. If you need message integrity, use a MAC. If you want a citation for this basic crypto design principle, I'll be happy to provide one. > This is a tough, but potentially feasible > attack if you use that kind of encryption scheme. Tough!? It's trivial for an active attacker, in the stream cipher case. He just xors some bits: no clever cryptanalysis needed. (Or did you mean it's tough to mount an active attack? I agree: that requires significant knowledge or motivation.) > Is there anywhere that you could use a similar attack on SSL ? Not in SSL v3.0; it explicitly uses a (cryptographically strong) MAC (message authentication code) on each message to prevent tampering and modification. Dave Wagner, speaking for himself, but thankful for all those behind the scenes who are helping to improve and open up Digicash communications. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMMdVCCoZzwIn1bdtAQHEvQF/c1wmuVWCpmMo+4jY0cNlrrKD/5vYb/st xC2dFLgb1ydJm6kfWRw0Hz8vF55tzj9t =N+Gr -----END PGP SIGNATURE-----

1 0

Re: Still more on the Digicash protocol
by jim bell 17 Dec '03

17 Dec '03

At 10:03 AM 12/7/95 -0800, you wrote: >I am glad that DigiCash supports this type of cash which anyone can >deposit. Actually, I am surprised and puzzled that it does, given >Chaum's apparent reluctance to endorse schemes to allow payee anonymity >(due to political problems, apparently). I, on the other hand, think one of the best uses of digital cash is to drastically reduce and eventually eliminate the whole concept of "government." I see payee-anonymous digital cash as being absolutely essential.

1 0