December 2003 - cypherpunks-legacy

e$
by hughes＠ah.com 17 Dec '03

17 Dec '03

When you fly into the US, you must fill out a customs declaration. You are required to declare money in various forms (cash, checks, etc) What they ask for and what is required by law are two different things. It's not generally illegal to allow people to volunteer information that increases the power of the state. Banks are required to declare cash deposits and international movements of funds over either $5K or $10K, I forget which. In the US, the value is $10K, but that's only for cash transactions, and it's not just banks that are required to report. "International movements of funds" are not subject to reporting requirements as such. Eric

1 0

e$
by hughes＠ah.com 17 Dec '03

17 Dec '03

Yes. But my initial point was that a check for $1.00 does not constitute an alternative currency and you do not seem to be disagreeing with this. Merely the fact that an instrument is denominated in USA dollars is irrelevant to legality. What I was saying is that there are other activities that would be the ones ruled illegal. I think that whether the $5000 is transferred as greenbacks or as $e is irrelevant, if the creation of $e is handled correctly. Irrelevant to whom? As long as it's _not_ irrelevant to the government, it will be irrelevant to very few other parties. > A company engaged in the business of > issuing such notes [etc.] To clarify, I'm talking about a digital money company here, and since USA regulation is what is at issue, I'm talking about a USA digital money company. Every bank in the United States that allows checks to be made out to cash already does this. The one-at-a-time has never been an issue. And it's not banks that "allow" this, it's the Uniform Commercial Code. A second point, relating to this paragraph: obviously, a foreign bank cannot be constrained in the same way to report financial transactions to US authorities. Well, this is just what I've been talking about for some time. It's clearly possible to have the issuer in another country. Eric

1 0

Re: RemailerNet
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <2e452e79.nemesis(a)nemesis.wimsey.com> Stuart Smith writes: > In article <4068(a)aiki.demon.co.uk> you write: > >If you modify the proposed RemailerNet to allow reposting at gateways, > >you have all of the benefits of the system described above, without > >the risks. Reposted messages would be encrypted with the far gateway's > >public key. The near gateway would then have no idea of the ultimate > >destination of the message. In a well designed system, the far > >gateway would also not know the identity of the sender. > > But how could we do this if we followed your advice, and did not > allow the user to select their own chain, as you said > previously? I have assimilated criticisms made and modified the proposal. > By making users *trust* the remailnet as an entity, > you make it possible for that entity to be compromised. (a) I don't force the users to trust RemailerNet as a single entity, (b) how does their trust make it possible for the entity to be compromised?? It is not possible to guarantee that some or all components of a remailer network are not compromised. You can only take steps which reduce the probability. > If the > remailernet is not one entity, but a large group of independent > entities, compromise is *much* harder. It is NOT one entity, is IS a large group of independant (but cooperating) entities. > >Any traffic sent through this remailer network would have only a tiny > >chance of getting through without being compromised. If you picked > >5 remailers, the chances of all being non-FBI would be about .2^5, > >3 in 10,000. The other 9,997 messages would be copied immediately > >to Langley. > > > >The proposed RemailerNet could be attacked in much the same way. But > >if the network were widely distributed so that gateways were in > >different legal jurisdictions and different countries, and if most of > >the people involved knew one another, it would be more difficult to > >compromise it. > > But if the user does not know the people in the remailnet, how > can he or she trust *them*? In most cases, you do not want the person operating a remailer to know you personally. Ideally, you know them, because they have a widespread reputation (eg, julf(a)penet.fi) But they do not know you. As a practical matter, the fewer remailers there are, the more likely they are to have an accurate reputation, because more people will have had experience with them. > It's fine and dandy that the > remailnet operators trust each other, but the point is to give > the end user anonymity, not to form an old boys club of remail > operators. If they all know each other, I do *not* think that > makes the system more secure, I think it makes it weak. People have been building systems like this, that involve webs of trust, for millenia. Banks are such institutions. While it is true that familiarity between trusted individuals makes for collusion, it also makes for knowledge. Most people use banks. Few banks are corrupt. A cruder example is the dope dealer. The police regularly attempt to compromise them. Anyone buying dope learns to (a) be skeptical about all dope dealers but also (b) find one that he can trust and stick with him. Dope dealers apply the same sort of heuristic to their suppliers. They ask around all the time, they listen to gossip, they talk to their peers. > As is often stated, a mix-net like this should still be secure > if some of the remailers are compromised, so could we speculate > on just how easy or hard traffic analysis is with any given > percentage of a remailnet compromised? i.e. if we took it as a > fact of life that 90% of any announced remailers were > spook-mills, could we still trust the remailnet if we used > *long* chains in the hope that our messages would pass often > enough through *good* remailers to confuse the trail? RemailerNet v0.2 allows "empowered users" to participate as equals with established RemailerNet operators. This means that the gateway that they are connected to has no way of knowing whether they are originating any traffic, let alone who that traffic is addressed to. The gateway will know that the user is receiving traffic, but it will not know whether that traffic is intended for the user or whether the user is simply acting as a reflector. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Therefore, two users could communicate through a RemailerNet network with ALL nodes [gateways] compromised, and still be secure against most forms of attack. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- Jim Dixon [sorry about the delay in answering this posting. It is dated 7 Aug but I received it 10 Aug]

1 0

GAK?
by bshantz＠spry.com 17 Dec '03

17 Dec '03

Forgive me for asking a naive question, but what exactly is GAK? I have seen it mentioned on the list several times in the last few days and don't recognize it. Brad

3 3

Re: broadcast encryption
by Perry E. Metzger 17 Dec '03

17 Dec '03

If you misspell things, they generally don't work. .pm Jim Dixon says: > In message <9408101422.AA26709(a)snark.imsi.com> perry(a)imsi.com writes: > > Read the drafts, show up at IETF meetings, and subscribe to the > > working group mailing lists. (The list subscribe address is > > ipsec-request(a)ans.net;... > > > > ===== transcript follows ===== > > > > While talking to ans.net: > > >>> RCPT TO:<ispec-request(a)ans.net> > > <<< 550 <ispec-request(a)ans.net>... Invalid recipient - Not registered > > >>> DATA > > <<< 503 Need valid RCPT (recipient) > > > > ===== Unsent message follows ==== > > Date: Wed, 10 Aug 94 19:08:45 GMT > > From: jdd(a)aiki.demon.co.uk (Jim Dixon) > ... etc ... > > -- > Jim Dixon > +-----------------------------------+--------------------------------------+ > | Jim Dixon<jdd(a)aiki.demon.co.uk> | Compuserve: 100114,1027 | > |AIKI Parallel Systems Ltd + parallel processing hardware & software design| > | voice +44 272 291 316 | fax +44 272 272 015 | > +-----------------------------------+--------------------------------------+

1 0

Re: The Terrorists are coming!
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408031132.ZM695(a)simple.sydney.sgi.com> Ian Farquhar writes: > Out of curiousity, is anyone aware of whether the USSR employed PAL's > (Permissive Activation Links) in their strategic nuclear weaponary? If so, > is anyone aware of how secure the PAL's the Soviets actually used were? > There was a rumor on USENET some time back that the Soviets were using RSA > in their PAL's, but it sounded too much like an urban myth to me. According to recent press reports in the UK, when Soviet bombers were loaded with nuclear weapons, they were actually dummies (because the generals, etc, didn't trust the crews). This suggests that the Soviets did not have reliable safeguards on the bombs. Various arguments between the Ukraine and the USSR about ICBM warheads, also reported in the press, suggest that the safeguards on the warheads were reliable, because both parties seemed to agree that the Ukrainians couldn't set them off, although they are otherwise technically competent in dealing with the missiles. -- Jim Dixon

1 0

Re: EDDB/RN
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408091536.AA22362(a)ah.com> Eric Hughes writes: > However, there should be a use for persistent store, for a remote > encrypted database accessible anonymously. > > The real questions are "how big is the market?" and "how much revenue > is there in it?". > > Something like this doesn't get made reliable by volunteers. I think that the market is potentially large. > Ideally, the data is stored on a distributed data base, with some > redundancy in case one or more gateways go down > > Look in Schneier for secret sharing. We won't have a copy of Schneier here for three weeks or so. Can you elaborate? However, almost certainly, the crypto aspects would be relatively minor. Most of the work would be in building a reliable widely distributed data base accessible over the Internet. When I last looked at this sort of problem, it was very complex. -- Jim Dixon

1 0

Re: <null>
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <9408070032.AA17321(a)ah.com> Eric Hughes writes: > One assumption here is that someone in one country can easily pay > someone in another country, and an automatic currency conversion can > take place. The prerequisites to happen generally for that are the > electronification of retail money in both jurisdictions and a > retail-level currency exchange system. None of this really exists > yet, although the first beginnings are here. Also, for anonymous > payment for such overseas services, anonymous transfer in at least one > of the two currencies is necessary. The last point is certainly not true. If user X communicates with service A (a gateway) in one country to purchase something from service B in another country, X can settle accounts with A anonymously (say in US$) and then A and B can settle accounts with one another (say in sterling) openly. In fact, few Europeans would object to simply trading in digital money denomenated in US dollars. No currency conversion is necessary. Many European companies have US dollar bank accounts because the banks charge so much money for conversion of currencies. -- Jim Dixon

1 0

Re: RemailerNet v0.2
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408090347.UAA24150(a)jobe.shell.portal.com> Hal writes: > What is the goal of the RN as far as defeating traffic analysis? Is it > just to get messages from one "gateway" to another? Or is there also > a desire to prevent traffic analysis from one non-gateway end user to > another? The goal is to completely defeat traffic analysis, while allowing the user the freedom to make use of the system through ordinary email. If email is used, the risk taken by that user goes up, but without reducing the security of other users. > What are the allowed capabilities of the opponent? Can he watch all of > the links? Can he subvert some gateways? In the real world, it would be very difficult to watch all of the links but fairly easy to subvery some gateways to some extent. However, as I have argued elsewhere, I think that all of the central gateways could be compromised and it would make no difference, so long as the number of users was reasonably large and so long as all of the users used gateways. From the opponent's point of view, the problem is that he cannot tell whether there is any traffic at all. Everyone could be whiling away a hot summer afternoon sending noise. The only attack would be to destroy or modify the incoming traffic. If there are any gateways functioning correctly, RN software should detect the damaged packets and route around the gateways that don't work right. This is exactly what the Internet does. > Does every user expose the source and destination information of his > messages to the initial gateway? What other information is sent by the > user to the RN? A user sending encrypted messages via email reveals his source address. He should encrypt his message. The message can be to a 'far' gateway which then remails it; in this case the 'near' gateway does not know the destination address. Messages can be nested to an arbitrary depth. If a user is using a gateway, the other gateways know that the message originated at the gateway, but they cannot tell whether that is the true source of the message. If the destination is another gateway, the other gateways do not know whether that is the true destination. > Are there any limitations on the information which spreads through the > RN? E.g. are gateways allowed to send source/dest information > along with the messages? If the message is to be acknowledged back to the source, the source gateway must be able to receive the acknowledgement. This creates a trail of pointers through the network back to the source. Only the final gateway, which reassembles the message, knows the ultimate destination. > Here are some questions related to Jim's specific points: > > >1.6 the order of dispatch of packets is randomized > For 1.5 you defined what randomized means. What does it mean here? Each gateway must dispatch a certain number of packets. There are a certain number of slots to be filled and a certain number of packets queued for dispatch. Packets are assigned an output slot (that is, they are delayed for a certain amount of "time") according to some sort of probabilistic distribution function. Empty slots are filled with noise packets. Inter-gateway administrative traffic is queued just like any other packet. If a gateway is always connected to the internet, packets can be dispatched at more or less equal intervals (measured in seconds) or they can be batched. > >1.7 on average, all gateways are required to send and receive the same > > number of packets per unit of chronological time > Do you mean that all gateways send the same number of packets per time > all the time? E.g. all gateways send 100 packets per hour all the time Yes, on average, as qualified by 1.8 and 1.9. > >1.8 the dispatch randomization function adjusts the average latency > > and the distribution of latencies so that the preceding commitment > > is met, introducing noise packets as required > This could be accomplished by adding no latency at all during times when > the incoming traffic load happens to equal the desired internal traffic > level. But presumably some latency is actually used to provide reordering. > What rule would determine how much latency would be used in that case? Assume that there are only two links, one in and one out. Packets will be coming in at a more or less fixed rate. Some will be consumed locally, either because they are being used to build messages or because they are noise. So per unit time N come in and C are consumed, on average. The remaining (N-C) packets are available for dispatch. In the same time interval, G packets are generated locally. So a total of N-C+G packets are to be dispatched. The system uses a random number generator to assign a packet a dispatch time slot when it becomes ready. When the clock ticks, the next packet in the queue is dispatched. If there is no next packet, a noise packet is dispatched. The system knows how long the output queue is. If the length of the queue is increasing, the rate at which packets are dispatched will be increased. [I have used the term "latency" here to be provocative.] > >1.10 gateways are required to exchange the same number of packets in > > any session > What is a session? Do you mean, during every session exactly (say) 1000 > packets will be exchanged, or do you mean, during any session the > number of packets exchanged by each gateway will equal the number ex- > changed by every other gateway (but this number may vary from session to > session)? If your gateway connects by dial-up, then the length of time that you are connected to RN is the session time. There must be some handshaking at the beginning of the session and at the end. For machines that are always on line, a session lasts from one breakdown in inter-machine connections to the next. If two machines A and B are connected, then if A sends B 100 packets per unit time, B must send A 100 packets. > >2.4 message delivery is reliable, in the sense that the destination > > gateway will report delivery of incomplete or damaged messages > > to the gateway > To which gateway? The source gateway? To the gateway which packetized the message, the source gateway. Assuming that 'MIRVing' of messages is permitted, the second message in a group could be an acknowledgement back to the originator. > >4.2 where gateways are operated by users, the requirement that gateways > > should exchange the same number of packets per unit time would be > > weakened in some as yet unspecified way > Why do this? I think that you must allow for the possibility that the gateways carry very heavy traffic, say a T1 load (about 1.5Mbit/s). Then if a user's machine was talking down a 14.4Kb/s line, allowing the user to connect would effectively stop the network. There must be some provision for inequality in traffic rates along different links. > >5.1 in either case, users may have accounts with gateways and may be > > charged for usage > What gateways would be in a position to charge users? Only the source > gateway? The destination gateway? Others in between? I assume that in a commercial network, the gateways have accounts with one another that are settled periodically. Essentially they charge each other for non-noise incoming packets at some agreed rate and then pay the accumulated difference every so often. Users should pay the gateway which fragments a message. The charge should be proportional to the size of the message in packets. If messages are nested, you need to include postage. This requires anonymous ecash. > >6.0 RN gateway software should be available only from trusted sites by FTP > What are you trying to prevent by this, and what would happen if someone > wrote his own version of the RN software? I am trying to prevent the inevitable. Weaken this requirement, eliminating the word 'only'. Publish the specs as well, and then say "RN gateway specs should also be available from trusted sites..." > >7.1 established gateways would be encouraged to rate new gateways > What kind of information would be available to them to create the ratings? Gossip, rumors, route announcements and 'hello, here I am' messages from the operators of the new gateways, experience in RN data communications with them, reports from commercial credit agencies, ... whatever information they could lay their hands on. The technical information would be published in some standard format, for example a matrix of claimed lost message rates. -- Jim Dixon

1 0

Re: e$
by frissell＠panix.com 17 Dec '03

17 Dec '03

At 01:51 PM 8/9/94 -0400, Perry E. Metzger wrote: > >> > Yes it does. Bearer bonds are illegal in the US. >If the check is written to "cash" and is used to avoid federal >transfer reporting requirements, it is CURRENTLY illegal. I suspect >that checks made out to "cash" would be illegal in all cases if they >were widely used to avoid reporting requirements. > >Perry > Bearer bonds are not illegal in the US. Under the Tax Equity and Fiscal Responsibility Act of 1982 (TEFRA), any interest payments made on *new* issues of domestic bearer bonds are not deductible as an ordinary and necessary business expense so none have been issued since then. At the same time, the Feds administratively stopped issuing treasury securities in bearer form. Old issues of government and corporate debt in bearer form still exist and will exist and trade for 30 or more years after 1982. Additionally, US residents can legally buy foreign bearer securities. DCF "Who promises the Black Caucus that if they will help kill the Crime Bill, he will support affirmative action in executions -- starting with the White Guys responsible for the Waco Massacre."

2 1