July 2018 - cypherpunks-legacy

Re: Fast MAC algorithms?
by John Gilmore 06 Jul '18

06 Jul '18

> >2) If you throw TCP processing in there, unless you are consistantly going to > >have packets on the order of at least 1000 bytes, your crypto algorithm is > >almost _irrelevant_. This is my experience, too. And I would add "and lots of packets". The only crypto "overhead" that really mattered in a real application was the number of round-trip times it took to negotiate protocols and keys. Crypto's CPU time is very very seldom the limiting factor in real end-user application performance. > Could the lack of support for TCP offload in Linux have skewed these figures > somewhat? It could be that the caveat for the results isn't so much "this was > done ten years ago" as "this was done with a TCP stack that ignores the > hardware's advanced capabilities". I have never seen a network card or chip whose "advanced capabilities" included the ability to speed up TCP. Most such "advanced" designs actually ran slower than merely doing TCP in the Linux kernel using an uncomplicated chip. I saw a Patent Office procurement of Suns in the '80s that demanded these slow "TCP offload" boards (I had to write the bootstrap code for the project) even though the motherboard came with an Ethernet chip and software stack that could run TCP *at wire speed* all day and night -- for free. The super whizzo board couldn't even send back-to-back packets, as I recall. Some government contractor had added the "TCP offload" requirement, presumably to inflate the price that they were adding a percentage markup to. As a crypto-relevant aside, last year I looked at using the "crypto offload" engine in the AMD Geode cpu chip to speed up Linux crypto operations in the OLPC. There was even a nice driver for it. Summary: useless. It had been designed by somebody who had no idea of the architecture of modern software. The crypto engine used DMA "for speed", used physical rather than virtual addresses, and stored the keys internally in its registers -- so it couldn't work with virtual memory, and couldn't conveniently be shared between two different processes. It was SO much faster to do your crypto "by hand" in a shared library in a user process, than to cross into the kernel, copy the data to be in contiguous memory locations (or manually translate the addresses and lock down those pages into physical memory), copy the keys and IVs into the accelerator, do the crypto, copy the results back into virtual memory, and reschedule the user process. In typical applications (which don't always use the same key) you'd need to do this dance once for every block encrypted, or perhaps if you were lucky, for every packet. Even kernel crypto wasn't worth doing through the thing. And the software libraries were not only faster, they were also portable, running on anything, not just one obsolete chip. Hardware guys are just jerking off unless they spend a lot of time with software guys AT THE DESIGN STAGE before they lay out a single gate. One stupid design decision can take away all the potential gain. Every TCP offloader I've seen has had at least one. John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Real ID = National ID
by Barry Steinhardt 06 Jul '18

06 Jul '18

Dave, Congressional passage of the "Real ID" legislation is now all but a done deal, House and Senate conferees having agreed to inclusion of language in an appropriations bill that is all but certain to pass. The name "Real ID" is, if anything, too modest. Despite deep public opposition over the years to a national identity card, and Congress's unwillingness to even consider the idea directly, our security agencies have now gotten what they want as proponents have succeeded in pushing through Congress a National ID-in-disguise. The "Real ID" Act is indeed a real (national) ID. Although individual states' driver's licenses may continue to exhibit cosmetic differences, they will now contain a standardized set of information collected by all 50 states, which means that underneath each state's pretty designs they are really a single standardized national card - backed up not only by biometrics, but also by a standardized "machine- readable zone" and by a national database of ID information. Local DMV offices may continue to appear to be state offices, but they will now become agents acting on behalf of the federal government, charged with issuing a national identity document without which one will be unable to function in America. National database creates powerful tracking tool. Real ID requires the states to link their databases together for the mutual sharing of data from these IDs. This is, in effect, a single seamless national database, available to all the states and to the federal government. (The fact that the database is a distributed one, maintained on interconnected servers in the separate states, makes no difference.) National database creates security risks. The creation of a single interlinked database creates a one-stop shop for identity thieves and terrorists who want to assume an American's identity. The security problems with creating concentrated databases has recently been demonstrated by the rampant number of data breaches in recent months in which information held by commercial database companies has fallen into the hands of identity thieves or others. The government's record at information security is little better and that is especially true at state Motor Vehicle Departments that have routinely been the targets of both insider and outsider fraud and just plain larceny. The "machine-readable zone" paves the way for private-sector piggybacking. Our new IDs will have to make their data available through a "common machine-readable technology." That will make it easy for anybody in private industry to snap up the data on these IDs. Bars swiping licenses to collect personal data on customers will be just the tip of the iceberg as every retailer in America learns to grab that data and sell it to Choicepoint for a dime. It won't matter whether the states and federal government protect the data - it will be harvested by the private sector, which will keep it in a parallel database not subject even to the limited privacy rules in effect for the government. This national ID card will make observation of citizens easy but won't do much about terrorism. The fact is, identity-based security is not an effective way to stop terrorism. ID documents do not reveal anything about evil intent - and even if they did, determined terrorists will always be able to obtain fraudulent documents (either counterfeit or real documents bought from corrupt officials). Negotiated rulemaking. Among the any unfortunate effects of this legislation is that it pre-empts another process for considering standardized driver's licenses that was far superior. That process (set in motion by the Intelligence Reform Act of 2004) included a "negotiated rulemaking" among interested parties - including the states and civil liberties groups - to create standards. Instead, the worst form of rules is being imposed, with the details to be worked out by security officials at DHS instead of through balanced negotiations among affected parties. "Your papers, please." In the days after 9/11, President Bush and others proclaimed that we must not let the terrorists change American life. It is now clear that - despite its lack of effectiveness against actual terrorism - we have allowed our security agencies push us into making a deep, far-reaching change to the character of American life. Barry Steinhardt Director Technology and Liberty Project American Civil Liberties Union ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] Real ID = National ID
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [gsc] Does anyone out exchange loom?
by Patrick Chkoreff 06 Jul '18

06 Jul '18

Graham Kelly wrote: > On Thu, 31 May 2007 13:48:17 -0500, "Arrakis" >> Obviously loom has a far way to go for usability, but I guess this is >> a process. I am getting two very different classes of reaction from users: 1. I cannot believe how easy this interface is! It's amazing! 2. I have no idea how to use this user interface! It sucks! I believe the problem is primarily conceptual. Here's a little background on how Loom works. Consider buying a shirt at a retail clothing store. You walk up to the counter with the shirt, the cashier rings it up, and says that will be 37 euros please. You take the 37 euros out of your wallet and put it on the counter. The cashier then picks up the 37 euros and puts it in the cash register. You are now the proud owner of a new shirt. Loom works in a similar way. When Alice wants to pay Bob some euros, she does *not* stuff the euros directly into Bob's wallet or cash register. Instead, Alice puts the euros in a place where Bob can reach them. Then Bob *himself* picks up the euros and puts them into his wallet or cash register. That place on the counter-top where Alice puts the euros is called the "drop point." It is a location where the ownership of the euros is up for grabs. If Bob refuses the payment, Alice can take the euros right back from the drop point and put them back in her wallet. So a payment in Loom is a two-step process. Note that I am using "euros" in this example simply to make it more familiar to readers. Loom itself knows nothing about specific asset types like "euros" or even "gold" -- Loom is basically just an online spreadsheet of sorts. So again, a payment in Loom is a two-step process. 1. Alice moves the euros from her personal stash to a drop point X. 2. Bob moves the euros from the drop point X to his personal stash. Now before Alice can pay Bob, they need to *establish* that shared drop point X, and add it to their own respective folders. It doesn't matter who dreams up the drop point first, but let's say Alice does it. In her folder, Alice clicks Locations, then clicks to add a new location, presses Random to generate a new random drop point, types "Bob" as her nickname for that location, and presses Save. Now when Alice wants to give something to Bob, she can easily select "Bob" from the drop-down menu in her folder. But at this point only half of the picture is complete. Bob has not yet added the drop point to his *own* folder. First, Alice obviously needs to tell Bob the new drop point she generated. Ideally she could copy and paste the location into a PGP-encrypted email, but alternatively she could send it via Skype, or read it to Bob over the phone, or even send it in a plain unencrypted email. (Most of the time the drop point will be empty, so anyone intercepting the email and looking at the drop point will not typically see any assets. Let the user beware.) That part, the *communication* of the shared drop point, is where people have to be the most careful. Once the drop point is established in both folders, then payments are extremely easy and secure. So now let's say that Bob gets a Skype chat from Alice saying "Hey Bob, let's use this as our drop point: 0f6f31b8eeeb795a7885ac670a344de1". Bob replies "OK Alice, hold on just a sec!" Bob logs into his folder, clicks Locations, clicks to add a new location, and pastes that big number into the box labeled "Location". He types in a nickname for this location, which in this case will be "Alice". He presses Save. Now, when Bob wants to give something to Alice, he can easily select "Alice" from the drop-down menu in his folder. Note that the SAME drop point 0f6f31b8eeeb795a7885ac670a344de1 is now installed in both Alice's and Bob's folder. But also note that Alice has nicknamed that location as "Bob," while Bob has nicknamed that same location as "Alice." It makes complete sense when viewed from the perspective of Alice's and Bob's folders. At that point, everything is configured and Alice and Bob now have a shared drop point. They have established an "economic relationship" if you will. And now payments between Alice and Bob are amazingly easy and fast. When I showed this to my wife, she could not believe how easy it was. I just tested making a payment last night, and it took me TEN SECONDS FLAT, *including* logging into my folder to begin with. So let's say Alice wants to pay Bob 5.6 grams of loom gold. Here's the process. Click the stopwatch. 1. Alice visits loom.cc, enters her folder passphrase, and presses Login. 2. She types the number 5.6 into the quantity field. (Note that when she logs in, her cursor is already sitting there conveniently in the Qty field, so she doesn't even have to bother clicking into it.) 3. She selects "grams loom gold" from the drop-down menu labeled "choose asset." 4. She selects "Bob" from the drop-down menu labeled "choose location." 5. She presses the button labeled "Give". I don't know about Alice, but I can do that in about 10 seconds, if I don't mistype my passphrase. But now here's where things get even easier. Let's say Alice wants to make another payment, this time paying 3.25 grams to Carol. Here's the process. 1. Type 3.25 in the Qty field. 2. Click "Carol" in the drop-down location menu. 3. Press Give. Note that this time, Alice didn't even have to select the asset type, since she had already selected "grams loom gold" before. But wait!, you may ask. That's too easy, and Alice might make a mistake. Let's say Alice entered 32.5 instead of 3.25. No problem. When Alice notices the mistake, she can just quickly press the Take button to take the assets right back. Then she can fix the number and press Give. (Now if Bob somehow managed to be in his folder RIGHT AFTER Alice made her mistake, and he saw the 32.5 grams sitting there, and he did a Take to grab all those 32.5 grams before Alice had a chance to take them back herself, then there's a problem. But that's unlikely. And if it happens, then Alice should (1) chide herself for being so careless and (2) tell Bob to give the money back.) That's it. Payments done in seconds flat, and no fumbling around for drop points stored in a notepad file or written on slips of paper, and no account numbers (just handy nicknames for drop points, completely at your discretion). Now at some point I'll put all that background information up on the Loom site under the Help link, for those who actually bother to click Help links and read what's there. Personally, I generally loathe Help screens, but I really do have some helpful information there. Mind you, I have been BUSY ENOUGH just writing and testing this code, so please bear with me as I improve the help and educational process here. Realistically, the background information I just gave you will best circulate by word of mouth. This is basic conceptual background here. It's like knowing what the steering wheel and accelerator are for in an automobile. Nobody ever reads that stuff in a manual: they learn it from their father. It's probably somewhat akin to creating a MySpace page. If I signed up at MySpace, I'd probably fumble around for quite a while before I became adept at editing and placing content. Meanwhile, long-time MySpace users have established a deep tradition and understanding of the site, and are even using advanced editing tools. The Loom model is a *conceptual* shift away from ordinary payment systems -- it is a totally different paradigm of how ownership of arbitrary "units" may be transferred. Now if you think the Location (drop point) feature is mind-bending, just wait till you realize that even ASSET TYPES themselves can be added to folders. Right now when you create a new folder, the system automatically adds a few known asset types for you. If I hadn't done that, people would be ESPECIALLY baffled about Loom right now, arriving at my door with torches and pitchforks. That's right folks, the basic Loom system itself KNOWS NOTHING about specific asset types or what they mean. With the exception of the predefined asset types automatically added to newly created folders, you must "introduce" a new asset type into your folder. For example, let's say your friend Joe creates a new asset type which you and your friends will use to settle up lunch money debts. He'll choose some random asset identifier such as 857ca0317f031689f6782c8b2c09bbda, add it to his folder under a nickname such as "Sandwich Credits," and become the issuer of that type. Now, before Joe can pay Bob any of these new "Sandwich Credits," Bob will have to be informed about this new asset type. Joe tells Bob all about it, and how they'll use it to settle up lunch debts. Bob says OK sounds good. Bob logs into his folder, clicks the "Types" link (which I'm working on now), clicks to add a new type, pastes in the new asset type 857ca0317f031689f6782c8b2c09bbda, and nicknames it "Sandwich Credits". Bob could actually choose a different nickname if he preferred, perhaps "Sandwich from Joe!". (Maybe other people Bob knows have issued sandwich credits as well and Bob wants to keep them all straight in his mind.) Now when Joe slides some Sandwich Credits over to Bob's drop point, Bob will see them and he can then Take them up into his personal stash. This example underscores the fact that the Loom code itself is *totally generic*, and knows ABSOLUTELY NOTHING about specific asset types except for usage tokens. Consequently, the biggest hurdle users have to overcome is CONFIGURATION, e.g. adding nicknamed locations and asset types to their folders. Once that is done, the payment process is unbelievably easy. And even the configuration is not so bad, once you understand the basic concept of payment through shared drop points. -- Patrick --- end forwarded text -- ----------------- 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'

1 0

Re: Fast MAC algorithms?
by John Gilmore 06 Jul '18

06 Jul '18

> >2) If you throw TCP processing in there, unless you are consistantly going to > >have packets on the order of at least 1000 bytes, your crypto algorithm is > >almost _irrelevant_. This is my experience, too. And I would add "and lots of packets". The only crypto "overhead" that really mattered in a real application was the number of round-trip times it took to negotiate protocols and keys. Crypto's CPU time is very very seldom the limiting factor in real end-user application performance. > Could the lack of support for TCP offload in Linux have skewed these figures > somewhat? It could be that the caveat for the results isn't so much "this was > done ten years ago" as "this was done with a TCP stack that ignores the > hardware's advanced capabilities". I have never seen a network card or chip whose "advanced capabilities" included the ability to speed up TCP. Most such "advanced" designs actually ran slower than merely doing TCP in the Linux kernel using an uncomplicated chip. I saw a Patent Office procurement of Suns in the '80s that demanded these slow "TCP offload" boards (I had to write the bootstrap code for the project) even though the motherboard came with an Ethernet chip and software stack that could run TCP *at wire speed* all day and night -- for free. The super whizzo board couldn't even send back-to-back packets, as I recall. Some government contractor had added the "TCP offload" requirement, presumably to inflate the price that they were adding a percentage markup to. As a crypto-relevant aside, last year I looked at using the "crypto offload" engine in the AMD Geode cpu chip to speed up Linux crypto operations in the OLPC. There was even a nice driver for it. Summary: useless. It had been designed by somebody who had no idea of the architecture of modern software. The crypto engine used DMA "for speed", used physical rather than virtual addresses, and stored the keys internally in its registers -- so it couldn't work with virtual memory, and couldn't conveniently be shared between two different processes. It was SO much faster to do your crypto "by hand" in a shared library in a user process, than to cross into the kernel, copy the data to be in contiguous memory locations (or manually translate the addresses and lock down those pages into physical memory), copy the keys and IVs into the accelerator, do the crypto, copy the results back into virtual memory, and reschedule the user process. In typical applications (which don't always use the same key) you'd need to do this dance once for every block encrypted, or perhaps if you were lucky, for every packet. Even kernel crypto wasn't worth doing through the thing. And the software libraries were not only faster, they were also portable, running on anything, not just one obsolete chip. Hardware guys are just jerking off unless they spend a lot of time with software guys AT THE DESIGN STAGE before they lay out a single gate. One stupid design decision can take away all the potential gain. Every TCP offloader I've seen has had at least one. John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Real ID = National ID
by Barry Steinhardt 06 Jul '18

06 Jul '18

Dave, Congressional passage of the "Real ID" legislation is now all but a done deal, House and Senate conferees having agreed to inclusion of language in an appropriations bill that is all but certain to pass. The name "Real ID" is, if anything, too modest. Despite deep public opposition over the years to a national identity card, and Congress's unwillingness to even consider the idea directly, our security agencies have now gotten what they want as proponents have succeeded in pushing through Congress a National ID-in-disguise. The "Real ID" Act is indeed a real (national) ID. Although individual states' driver's licenses may continue to exhibit cosmetic differences, they will now contain a standardized set of information collected by all 50 states, which means that underneath each state's pretty designs they are really a single standardized national card - backed up not only by biometrics, but also by a standardized "machine- readable zone" and by a national database of ID information. Local DMV offices may continue to appear to be state offices, but they will now become agents acting on behalf of the federal government, charged with issuing a national identity document without which one will be unable to function in America. National database creates powerful tracking tool. Real ID requires the states to link their databases together for the mutual sharing of data from these IDs. This is, in effect, a single seamless national database, available to all the states and to the federal government. (The fact that the database is a distributed one, maintained on interconnected servers in the separate states, makes no difference.) National database creates security risks. The creation of a single interlinked database creates a one-stop shop for identity thieves and terrorists who want to assume an American's identity. The security problems with creating concentrated databases has recently been demonstrated by the rampant number of data breaches in recent months in which information held by commercial database companies has fallen into the hands of identity thieves or others. The government's record at information security is little better and that is especially true at state Motor Vehicle Departments that have routinely been the targets of both insider and outsider fraud and just plain larceny. The "machine-readable zone" paves the way for private-sector piggybacking. Our new IDs will have to make their data available through a "common machine-readable technology." That will make it easy for anybody in private industry to snap up the data on these IDs. Bars swiping licenses to collect personal data on customers will be just the tip of the iceberg as every retailer in America learns to grab that data and sell it to Choicepoint for a dime. It won't matter whether the states and federal government protect the data - it will be harvested by the private sector, which will keep it in a parallel database not subject even to the limited privacy rules in effect for the government. This national ID card will make observation of citizens easy but won't do much about terrorism. The fact is, identity-based security is not an effective way to stop terrorism. ID documents do not reveal anything about evil intent - and even if they did, determined terrorists will always be able to obtain fraudulent documents (either counterfeit or real documents bought from corrupt officials). Negotiated rulemaking. Among the any unfortunate effects of this legislation is that it pre-empts another process for considering standardized driver's licenses that was far superior. That process (set in motion by the Intelligence Reform Act of 2004) included a "negotiated rulemaking" among interested parties - including the states and civil liberties groups - to create standards. Instead, the worst form of rules is being imposed, with the details to be worked out by security officials at DHS instead of through balanced negotiations among affected parties. "Your papers, please." In the days after 9/11, President Bush and others proclaimed that we must not let the terrorists change American life. It is now clear that - despite its lack of effectiveness against actual terrorism - we have allowed our security agencies push us into making a deep, far-reaching change to the character of American life. Barry Steinhardt Director Technology and Liberty Project American Civil Liberties Union ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] Real ID = National ID
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [gsc] Does anyone out exchange loom?
by Patrick Chkoreff 06 Jul '18

06 Jul '18

Graham Kelly wrote: > On Thu, 31 May 2007 13:48:17 -0500, "Arrakis" >> Obviously loom has a far way to go for usability, but I guess this is >> a process. I am getting two very different classes of reaction from users: 1. I cannot believe how easy this interface is! It's amazing! 2. I have no idea how to use this user interface! It sucks! I believe the problem is primarily conceptual. Here's a little background on how Loom works. Consider buying a shirt at a retail clothing store. You walk up to the counter with the shirt, the cashier rings it up, and says that will be 37 euros please. You take the 37 euros out of your wallet and put it on the counter. The cashier then picks up the 37 euros and puts it in the cash register. You are now the proud owner of a new shirt. Loom works in a similar way. When Alice wants to pay Bob some euros, she does *not* stuff the euros directly into Bob's wallet or cash register. Instead, Alice puts the euros in a place where Bob can reach them. Then Bob *himself* picks up the euros and puts them into his wallet or cash register. That place on the counter-top where Alice puts the euros is called the "drop point." It is a location where the ownership of the euros is up for grabs. If Bob refuses the payment, Alice can take the euros right back from the drop point and put them back in her wallet. So a payment in Loom is a two-step process. Note that I am using "euros" in this example simply to make it more familiar to readers. Loom itself knows nothing about specific asset types like "euros" or even "gold" -- Loom is basically just an online spreadsheet of sorts. So again, a payment in Loom is a two-step process. 1. Alice moves the euros from her personal stash to a drop point X. 2. Bob moves the euros from the drop point X to his personal stash. Now before Alice can pay Bob, they need to *establish* that shared drop point X, and add it to their own respective folders. It doesn't matter who dreams up the drop point first, but let's say Alice does it. In her folder, Alice clicks Locations, then clicks to add a new location, presses Random to generate a new random drop point, types "Bob" as her nickname for that location, and presses Save. Now when Alice wants to give something to Bob, she can easily select "Bob" from the drop-down menu in her folder. But at this point only half of the picture is complete. Bob has not yet added the drop point to his *own* folder. First, Alice obviously needs to tell Bob the new drop point she generated. Ideally she could copy and paste the location into a PGP-encrypted email, but alternatively she could send it via Skype, or read it to Bob over the phone, or even send it in a plain unencrypted email. (Most of the time the drop point will be empty, so anyone intercepting the email and looking at the drop point will not typically see any assets. Let the user beware.) That part, the *communication* of the shared drop point, is where people have to be the most careful. Once the drop point is established in both folders, then payments are extremely easy and secure. So now let's say that Bob gets a Skype chat from Alice saying "Hey Bob, let's use this as our drop point: 0f6f31b8eeeb795a7885ac670a344de1". Bob replies "OK Alice, hold on just a sec!" Bob logs into his folder, clicks Locations, clicks to add a new location, and pastes that big number into the box labeled "Location". He types in a nickname for this location, which in this case will be "Alice". He presses Save. Now, when Bob wants to give something to Alice, he can easily select "Alice" from the drop-down menu in his folder. Note that the SAME drop point 0f6f31b8eeeb795a7885ac670a344de1 is now installed in both Alice's and Bob's folder. But also note that Alice has nicknamed that location as "Bob," while Bob has nicknamed that same location as "Alice." It makes complete sense when viewed from the perspective of Alice's and Bob's folders. At that point, everything is configured and Alice and Bob now have a shared drop point. They have established an "economic relationship" if you will. And now payments between Alice and Bob are amazingly easy and fast. When I showed this to my wife, she could not believe how easy it was. I just tested making a payment last night, and it took me TEN SECONDS FLAT, *including* logging into my folder to begin with. So let's say Alice wants to pay Bob 5.6 grams of loom gold. Here's the process. Click the stopwatch. 1. Alice visits loom.cc, enters her folder passphrase, and presses Login. 2. She types the number 5.6 into the quantity field. (Note that when she logs in, her cursor is already sitting there conveniently in the Qty field, so she doesn't even have to bother clicking into it.) 3. She selects "grams loom gold" from the drop-down menu labeled "choose asset." 4. She selects "Bob" from the drop-down menu labeled "choose location." 5. She presses the button labeled "Give". I don't know about Alice, but I can do that in about 10 seconds, if I don't mistype my passphrase. But now here's where things get even easier. Let's say Alice wants to make another payment, this time paying 3.25 grams to Carol. Here's the process. 1. Type 3.25 in the Qty field. 2. Click "Carol" in the drop-down location menu. 3. Press Give. Note that this time, Alice didn't even have to select the asset type, since she had already selected "grams loom gold" before. But wait!, you may ask. That's too easy, and Alice might make a mistake. Let's say Alice entered 32.5 instead of 3.25. No problem. When Alice notices the mistake, she can just quickly press the Take button to take the assets right back. Then she can fix the number and press Give. (Now if Bob somehow managed to be in his folder RIGHT AFTER Alice made her mistake, and he saw the 32.5 grams sitting there, and he did a Take to grab all those 32.5 grams before Alice had a chance to take them back herself, then there's a problem. But that's unlikely. And if it happens, then Alice should (1) chide herself for being so careless and (2) tell Bob to give the money back.) That's it. Payments done in seconds flat, and no fumbling around for drop points stored in a notepad file or written on slips of paper, and no account numbers (just handy nicknames for drop points, completely at your discretion). Now at some point I'll put all that background information up on the Loom site under the Help link, for those who actually bother to click Help links and read what's there. Personally, I generally loathe Help screens, but I really do have some helpful information there. Mind you, I have been BUSY ENOUGH just writing and testing this code, so please bear with me as I improve the help and educational process here. Realistically, the background information I just gave you will best circulate by word of mouth. This is basic conceptual background here. It's like knowing what the steering wheel and accelerator are for in an automobile. Nobody ever reads that stuff in a manual: they learn it from their father. It's probably somewhat akin to creating a MySpace page. If I signed up at MySpace, I'd probably fumble around for quite a while before I became adept at editing and placing content. Meanwhile, long-time MySpace users have established a deep tradition and understanding of the site, and are even using advanced editing tools. The Loom model is a *conceptual* shift away from ordinary payment systems -- it is a totally different paradigm of how ownership of arbitrary "units" may be transferred. Now if you think the Location (drop point) feature is mind-bending, just wait till you realize that even ASSET TYPES themselves can be added to folders. Right now when you create a new folder, the system automatically adds a few known asset types for you. If I hadn't done that, people would be ESPECIALLY baffled about Loom right now, arriving at my door with torches and pitchforks. That's right folks, the basic Loom system itself KNOWS NOTHING about specific asset types or what they mean. With the exception of the predefined asset types automatically added to newly created folders, you must "introduce" a new asset type into your folder. For example, let's say your friend Joe creates a new asset type which you and your friends will use to settle up lunch money debts. He'll choose some random asset identifier such as 857ca0317f031689f6782c8b2c09bbda, add it to his folder under a nickname such as "Sandwich Credits," and become the issuer of that type. Now, before Joe can pay Bob any of these new "Sandwich Credits," Bob will have to be informed about this new asset type. Joe tells Bob all about it, and how they'll use it to settle up lunch debts. Bob says OK sounds good. Bob logs into his folder, clicks the "Types" link (which I'm working on now), clicks to add a new type, pastes in the new asset type 857ca0317f031689f6782c8b2c09bbda, and nicknames it "Sandwich Credits". Bob could actually choose a different nickname if he preferred, perhaps "Sandwich from Joe!". (Maybe other people Bob knows have issued sandwich credits as well and Bob wants to keep them all straight in his mind.) Now when Joe slides some Sandwich Credits over to Bob's drop point, Bob will see them and he can then Take them up into his personal stash. This example underscores the fact that the Loom code itself is *totally generic*, and knows ABSOLUTELY NOTHING about specific asset types except for usage tokens. Consequently, the biggest hurdle users have to overcome is CONFIGURATION, e.g. adding nicknamed locations and asset types to their folders. Once that is done, the payment process is unbelievably easy. And even the configuration is not so bad, once you understand the basic concept of payment through shared drop points. -- Patrick --- end forwarded text -- ----------------- 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'

1 0

Wikileaks: NSA funding of academics
by John Gilmore 06 Jul '18

06 Jul '18

https://secure.wikileaks.org/wiki/On_the_take_and_loving_it Grant code 'MDA904' - National Security Agency The NSA has pushed tens or hundreds of millions into the academy through research grants using one particular grant code. ... John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [dgc.chat] free?
by R. A. Hettinga 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 3:36 PM +1000 8/11/02, David Hillary wrote: > I think that tax havens such as the Cayman Islands should be ranked > among the freest in the world. No taxes on business or individuals > for a start. Great environment for banking and commerce. Good > protection of property rights. Small non-interventionist > government. Clearly you've never met "Triumph", the Fabulous Crotch-Sniffing Caymanian Customs Wonder Dog at extreme close range, or heard the story about the expat's college age kid, actually born on Cayman, who was literally exiled from the island when the island constabulary "discovered" a marijuana seed or three in his summer-break rental car a few years back. I mean, his old man was some senior cheese at Global Crossing at the time, but this was back when they could do no wrong. If that's what they did to *his* kid, imagine what some poor former junk-bond-hustler might have to deal with someday for, say, the odd unauthorized Cuban nightlife excursion. A discretely folded twenty keeps the stamp off your passport on the ground in Havana, and a bottle of Maker's Mark goes a long way towards some interesting nocturnal diversion when you get there and all, but still, you can't help thinking that Uncle's going to come a-knockin', and that Cayman van's going to stop rockin' some day, and when it does, it ain't gonna be pretty. Closer to home, conceptually at least, a couple of cryptogeeken were hustled off and strip-searched, on the spot, when they landed on Grand Cayman for the Financial Cryptography conference there a couple of years ago. Like lots of cypherpunks, these guys were active shooters in the Bay Area, and they had stopped in Jamaica, Mon, for a few days on the way to Grand Cayman. Because they, and their stuff, reeked on both counts, they were given complementary colorectal examinations and an entertaining game of 20 questions, or two, courtesy of the Caymanian Federales, after the obligatory fun and games with a then-snarling Crotch-Sniffing Caymanian Wonder Dog. Heck, I had to completely unpack *all* my stuff for a nice, well-fed Caymanian customs lady just to get *out* of the country when I left. Besides, tax havens are being increasingly constrained as to their activities these days, because they cost the larger nation-states too much in the way of "escaped" "revenue", or at least the perception of same in the local "free" press. Obviously, if your money "there" isn't exchangeable into your money "here", it kind of defeats the purpose of keeping your money "there" in the first place, giving folks like FinCEN lots of leverage when financial treaties come up for renegotiation due to changes in technology, like on-line credit-card and securities clearing, or the odd governmental or quango re-org, like they are wont to do increasingly in the EU, and the US. As a result, the veil of secrecy went in Switzerland quite a while ago. The recent holocaust deposit thing was just the bride and groom on that particular wedding-cake, and, as goes Switzerland, so goes Luxembourg, and of course Lichtenstein, which itself is usually accessible only through Switzerland. Finally, of course, the Caymans themselves will cough up depositor lists whenever Uncle comes calling about one thing or another on an increasingly longer list of fishing pretexts. At this point, the "legal", state-backed pecuniary privacy pickings are kind of thin on the ground. I mean, I'm not sure I'd like to keep my money in, say, Vanuatu. Would you? Remember, this is a place where a bandana hanging on a string across an otherwise public road will close it down until the local erst-cannibal hunter-gatherer turned statutorily-permanent landowner figures out just what his new or imagined property rights are this afternoon. The point is, any cypherpunk worth his salt will tell you that only solution to financial or any other, privacy, is to make private transactions on the net, cheaper, and more secure, than "transparent" transactions currently are in meatspace. Then things get *real* interesting, and financial privacy -- and considerably more personal freedom -- will just be the icing on the wedding cake. Bride and groom action figures sold separately, of course. Cheers, RAH (Who went to FC2K at the Grand Cayman Marriott in February that year. Nice place, I liked Anguilla better though, at least at the time, and I haven't been back to either since. The beaches are certainly better in Anguilla, and the "private" banking system there is probably just as porous as Cayman's is, by this point. If I were to pick up and move Somewhere Free outside Your Friendly Neighborhood Unipolar Superpower, New Zealand is somewhere near the top of my list, and Chile would be next, though things change quickly out there in ballistic-missile flyover country. In that vein, who knows, maybe we're in for some kind of latter-day Peloponnesian irony, and *Russia* will end up the freest place on earth someday. Stranger things have happened in the last couple of decades, yes?) -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVYS48PxH8jf3ohaEQKwtgCgw/XSwzauabEP/8jDvUVk/rgFdroAn0xf Owk90GoK+X5Pv+bGoKXCwzBK =1w9d -----END PGP SIGNATURE----- -- ----------------- 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' subscribe: send blank email to dgcchat-join(a)lists.goldmoney.com unsubscribe: send blank email to dgcchat-leave(a)lists.goldmoney.com digest: send an email to dgcchat-request(a)lists.goldmoney.com with "set yourname(a)yourdomain.com digest=on" in the message body --- end forwarded text -- ----------------- 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'

1 0