March 2014 - cypherpunks - lists.cpunks.org

Re: [Cryptography] Bruce Schneier has gotten seriously spooked
by Eugen Leitl 06 Sep '16

06 Sep '16

----- Forwarded message from Brian Gladman <brg(a)gladman.plus.com> ----- Date: Sat, 07 Sep 2013 09:33:28 +0100 From: Brian Gladman <brg(a)gladman.plus.com> To: Cryptography Mailing List <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] Bruce Schneier has gotten seriously spooked User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 07/09/2013 01:48, Chris Palmer wrote: >> Q: "Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions?" > > Why would they perform the attack only for encryption software? They > could compromise people's laptops by spiking any popular app. Because NSA and GCHQ are much more interested in attacking communictions in transit rather than attacking endpoints. Endpoint attacks cost more to undertake, only give access to a limited amount of data and involve much greater risks that their attack will either be discovered or their means of attack will leave evidence of what they have done and how they have done it. The internal bueaucratic costs of gaining approval for (adverarial) endpoint attacks also makes it a more costly process than the use of network based interception. There is significant use of open source encryption software in end to end encryption solutions, in file archivers, in wifi and network routers, and in protecing the communications used to manage and control such components when at remote locations. The open source software is provided in source code form and is compiled from source in a huge number of applications and this means that the ability to covertly substitute broken source code could provide access to a huge amount of traffic without the risks involved in endpoint attacks. I stress that I am NOT suggesting that this has happened (or is happening), simply that it has attractions from an NSA/GCHQ viewpoint. Fortunately, I think it is a difficult attack to mount covertly (that is, without the acqiecience of the author(s) of the software in question). On the more general debate here, in my view, 'security for the masses' through the deployment of encryption is a 'pipe dream' that isn't going to happen. Functionality (and the complexity that comes with it) is the enemy of security and it is very clear that the public places a much higher value on functionality than it does on security (or privacy). Every time a new device comes onto the market, it starts with limited functionality and some hope of decent security but rapidly evolves to be a high functionality product in which the prospect of decent security declines rapidly to zero. Raspberry Pis look interesting _now_ but I would be willing to bet that they won't buck the trend of increasing funtionality and declining security simply because this is what the majority in even this limited user community will want. To buck this trend we need an effort like the Raspberry Pi effort but one driven by our community with a strong commitment to simplicty and deliberately limited functionality in both hardware and software. Brian Gladman _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

8 14

Re: [liberationtech] Interesting things in keyservers
by Eugen Leitl 16 Aug '16

16 Aug '16

----- Forwarded message from micah <micah(a)riseup.net> ----- Date: Sat, 20 Jul 2013 10:05:42 -0400 From: micah <micah(a)riseup.net> To: Micah Lee <micahflee(a)riseup.net>, 'liberationtech' <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Interesting things in keyservers User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> Hi Micah! Micah Lee <micahflee(a)riseup.net> writes: > I'm working on a talk for OHM2013 about PGP. Can anyone send me examples > of interesting keys in key servers that you know of? Since you are preparing a talk about the subject, I'm going to be pedantic and correct your usage of "PGP", because it is important to get your terminology straight when giving a talk. I presume you aren't giving a talk about the commercial software, but instead you are actually giving a talk about OpenPGP which is the standard specified by RFC4880 that different programs like GnuPG, Seahorse, MacGPG, and PGP etc. all implement. If that is true, then you should refer to it as OpenPGP, and not PGP. I dont know what your talk will consist of, besides the funny enigmail XSS and goatse.cx stuff (thanks for that! always good to have some goatse early in the morning), but I would like to point out a few things that might be useful to mention. One is a wiki page that I created with some people: https://we.riseup.net/riseuplabs+paow/openpgp-best-practices - it contains some useful hints about using OpenPGP, maintaining a good key and some general good practices that people often dont know about (such as the importance of keeping your keys updated to get critical revocation and expiration extension certifications!) One thing mentioned on that page that I wanted to highlight, because you used pgp.mit.edu links in your original email, is that the keyserver pgp.mit.edu is not a good one to use/promote. Everyone uses it as their 'goto' keyserver, but it is a really bad idea! As a keyserver, it has been broken for years. For a long time it was just dropping revocations, subkey updates and expirations on the floor. That is *really* bad. Eventually, they upgraded their keyserver software, but it is *still* running an older version of SKS, a version that fails to handle 16-digit subkeyid lookups (among other failings). So, please don't rely on pgp.mit.edu for your security, and please don't include them in your slides! If you are looking for one to use, I highly recommend using the SKS pool address (hkp://pool.sks-keyservers.net or http://hkps.pool.sks-keyservers.net/ - or if you want a more close geographical pool, have a look at http://sks-keyservers.net/overview-of-pools.php) Finally, there seems to be some amazing misconceptions about keyservers, keys and the web of trust. In particular this http://cryptome.org/2013/07/mining-pgp-keyservers.htm circulated recently and it pained me to see because it suggested various wreckless conclusions that were dangerously off the mark[0] (and used pgp.mit.edu, hah). While it is true that we've jokingly called the OpenPGP web of trust "the original social network" because of the exposed social relational graphing that can be done by querying keyservers, and it is for this reason that many activists I know do not want to have signatures uploaded to keyservers (and instead use the bulky local-only signature work-around)... ... but for some reason people seem to think that if it is on a keyserver, is true, or it means something that it doesn't. People don't realize critical things, such as the fact that I can create a key with the UID Nadim Kobeissi and upload it to the keyservers[1]. That doesn't mean that is the real Nadim's key (this is what exchanging key fingerprints and doing certifications is for, so you can know, with a certain degree of certainty, that this person is the person who controls that secret key material). Or people think that because I signed your key and that signature is on the keyserver that indicates: I trust you; we met in person at that date; we know each other; we are involved in a criminal conspiracy with each other; or many other wrong assumptions about what that certification means. I can sign Edward Snowden's key and send that to the keyservers[1]. Hell, I can sign Snowden's key with my fake Nadim Kobeissi key[1] and then send it to the keyservers. Does that mean that Nadim and Snowden have met in person?! No, it does not at all. Anyways, I can keep going... but I dont know what the focus of your OHM talk is about, so going on like this isn't particularly useful to you and your talk... however, I'd be happy to provide more feedback about your talk if you would like![2] After all, we Micahs need to stick together, micah 0. "the cryptome article just sounds like impenetrable bullshit from someone with no interest in actually understandning what's happening" - I'm not saying who said this... 1. no, I didn't do that, nor did I upload the edward snowden or bradly manning keys. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

4 3

HavenCo - Rebirth?
by grarpamp 07 Apr '15

07 Apr '15

Highly doubt Ryan, Avi or any cpunks are involved, or that much of anything will actually be in SeaLand. Seems like a news driven oppurtunistic biz to cover tower operation and maintenance costs. Anyone have any facts? Such as who's behind it and why? http://www.sealandgov.org/sealand-news-1/HavenCo http://www.havenco.com/

2 1

Stealthy Dopant-Level Hardware Trojans
by Eugen Leitl 23 Jun '14

23 Jun '14

http://people.umass.edu/gbecker/BeckerChes13.pdf Stealthy Dopant-Level Hardware Trojans ? Georg T. Becker1 , Francesco Regazzoni2 , Christof Paar1,3 , and Wayne P. Burleson1 1University of Massachusetts Amherst, USA 2TU Delft, The Netherlands and ALaRI - University of Lugano, Switzerland 3Horst ortz Institut for IT-Security, Ruhr-Universiat Bochum, Germany Abstract. In recent years, hardware Trojans have drawn the attention of governments and industry as well as the scientific community. One of the main concerns is that integrated circuits, e.g., for military or critical infrastructure applications, could be maliciously manipulated during the manufacturing process, which often takes place abroad. However, since there have been no reported hardware Trojans in practice yet, little is known about how such a Trojan would look like, and how dicult it would be in practice to implement one. In this paper we propose an extremely stealthy approach for implementing hardware Trojans below the gate level, and we evaluate their impact on the security of the target device. Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against "golden chips". We demonstrate the ectiveness of our approach by inserting Trojans into two designs | a digital post-processing derived from Intel's cryptographically secure RNG design used in the Ivy Bridge processors and a side-channel resistant SBox implementation and by exploring their detectability and their ects on security. Keywords: Hardware Trojans, malicious hardware, layout modifications, Trojan side-channel

5 4

The next gen P2P secure email solution
by grarpamp 02 Jun '14

02 Jun '14

This thread pertains specifically to the use of P2P/DHT models to replace traditional email as we know it today. There was a former similarly named thread on this that diverged... from the concept and challenge of P2P/DHT handling the transport and lookups... back to more traditional models. This thread does not care about those antique models, please do not take it there. In short, we're attempting to examine and develop some form of new transport that looks somewhat like a mix between secure anonymous networks, string@pubkey node addressing, massive decentralized dht-like scaling and finally a user facing daemon that moves messages into and out of local spools for use by normal user/system tools. Pasting in a very rough and unflowing thread summary to date for interested people to pick up and discuss, draft, etc. ===== grarpamp... > [pgp/smime email encryption, etc] > What is the gap we have to close to turn this on by default? How many times has this been rehashed the last six months? You can't fix email as we know it today using todays bolt-ons, protocols and corporate stakeholders/services trying to profit from it. The only way to have any real global seamless success is to go ground up with a completely new model. IMO, that will be some form of p2p message system where every address is a crypto key, masked for grandma by her contact list, decrypted out your p2p daemon and piped into your local mail processing (MUA/filter/lists) and filesystem (encryption). At least that way your local mail tools will still work (no one will give those up anyway). The problem is the antique centralized backend, it needs bypassed. You've got neat stuff like Tor, bittorrent, bitcoin, etc already... so boost email into the 2020's the same way. Then let the old world email services try to keep up, and slowly die like everything else. ===== grarpamp... On Mon, Nov 25, 2013 at 1:01 AM, ianG <iang(a)iang.org> wrote: > On 23/11/13 15:30 PM, Ralf Senderek wrote: >> On Sat, 23 Nov 2013, David Mercer wrote: >> >>> But of course you're right about actual current usage, encrypted email >>> is an >>> epic fail on that measure regardless of format/protocol. >> >> Yes, but it's about time we do something about that. Do we *exactly know >> why* it is such a failure? > > It's an interesting question, and one worth studying for pedagogical > motives. From my experiences from both sides, it is clear that both sides > failed. But for different reasons. > Hence, I've concluded that email is unsecurable. Obviously. It will never be able to escape the non-body header content and third party routing, storage and analysis with any form of patching over today's mail. And it's completely ridiculous that people continue to invest [aka: waste] effort in 'securing' it. The best you'll ever get clients down to is exposing a single 'To:' header within an antique transport model that forces you to authenticate to it in order to despam, bill, censor and control you. That system is cooked, done and properly fucked. Abandon it. What the world needs now is a real peer to peer messaging system that scales. Take Tor for a partial example... so long as all the sender/recipient nodes [onions] are up, any message you send will get through, encrypted, in real time. If a recipient is not up, you queue it locally till they are... no third party ever needed, and you get lossless delivery and confirmation for free. Unmemorable node address?, quit crying and make use of your local address book. Doesn't have plugins for current clients?, so what, write some and use it if you're dumb enough to mix the old and new mail. The only real problem that still needs solved is scalability... what p2p node lookup systems are out there that will handle a messaging world's population worth of nodes [billions] and their keys and tertiary data? If you can do that, you should be able to get some anon transport over the p2p for free. Anyway, p2p messaging and anonymous transports have all been dreamed up by others before. But now is the time to actually abandon traditional email and just do it. If you build it, they will come. ===== fabio... I'm strongly against most the ideas to abbandon current email systems, because the results will be to create wallet garden. We need something interoperable with existing systems or the system will just be used by a bunch of paranoid people or fostered by the marketing of few cryptography company acquiring customers, not user. ===== grarpamp... It would be interoperable with current end user interfaces/tools, but not directly with you(a)some.dotcom. As with everything else, today's seeds grow into tomorrows garden, sometimes you just have to thorougly plow under last year's chaff first, that's by design. ===== viktor... E-mail is basically business correspondence. - E-mail is stored. - E-mail is sent to many people outside your personal social network. - Business recipients of email are often subject to corporate and/or regulatory policy constraints that are in conflict with end-to-end encryption. The above list of features can be greatly expanded, and the consequences elaborated, but I doubt may on this list truly need to be re-educated about email. So I will confidently predict that end-to-end secure email will remain a niche service used by a tiny minority. ... Even businesses that one might expect to implement at least encryption to the "gateway", are in many cases choosing to out-source their gateway to 3rd-party providers (anti-spam and anti-virus offerings only work with un-encrypted email, and in many cases the provider also operates the entire mail store). .... [and others also said: tls, dane, skype, smime, ca's, smtp, etc] ===== Jerry... Medical, Financial ===== grarpamp... Nothing here changes, only the backend transport between nodes. Once your node decrypts the message to your local system pipes, you can do all this and more with it. Including running a 'business' node and doing whatever you want with the plaintext after your node daemon passes it to you. This is not about those ancient protocols. It's also about 'messaging' not strictly 'email'... those lines are already well blurred, no need to distinguish between them anymore. A 'light' messaging client could simply ignore the non transport email headers, or use your standard msg@nodekey address. Please do not continue to talk about antique tradional centralized systems in this thread, except of course to bash and route around them. The speed of a real P2P/DHT replacement at scale is a research challenge. ===== coderman... this would make an interesting bet! i too believe this to be impossible given the constraints. ===== grarpamp... I'm not so sure about this, look at all the global resources being poured into traditional email, and attempts to 'fix' it. Now redirect fractional 1% of those resources and put them into a P2P replacement. That's ftw. ===== natanael... Say hello to Bote mail on I2P. I2P provides encrypted anonymizing networking, Bote mail provides DHT based serverless encrypted mailing with public crypto keys as addresses (ECDSA or NTRU). http://i2p2.de and i2pbote.i2p (if you don't have I2P installed, add .us to visit it via an inproxy). There is also I2P Messenger that is encrypted P2P IM within I2P also using public keys as addresses. ===== cane... You may have a look of "I2P Bote" it is severless, encrypted mail system, address is the public key, P2P based... nice tool. https://en.wikipedia.org/wiki/I2P#E-mail ===== grarpamp... > You may have a look of "I2P Bote" it is severless, encrypted mail > system, address is the public key, P2P based... nice tool. As in another post of mine, I'll be looking at that again. My first take was that it stores the messages in the DHT, which didn't seem scalable or reliable at all. I may be wrong as I read more later. > Afterwards you can add the "I2P Bote plugin", the serverless mail > system. SMTP- and POP3 support was on the ToDo list some times ago, I I think that's working now. And is the general idea, create a strong overlay network with a frontend MUA's can speak to. As an aside: If you can make that overlay net present an IPv6 tunnel interface on the local host, that lets you use any IPv6 enabled app over it. I'm doubting the world needs a dozen application specific overlay networks. More like just a few classes of network. - message based store and forward - low latency IPv6 transport - data storage and retrieval ===== natanael... Bote mail doesn't have to be used for it's anonymous properties, for me that is just a bonus. For many people it is more than enough to be able to know that it is impossible for anybody else than the intended recipient to read the message thanks to public key addressing. Guaranteed end-to-end security if you can verify the address. I don't think anything that doesn't fundamentally rely on public key addressing is the (long term) future. There will inevitably issues otherwise, including more issues of the type we have with CA:s today. For those who want to make it more user friendly, nothing stops you from adding a transparent "address translation layer" where servers are involved. When you want to send a message to a person with a human readable address at a server, then the server could then reply with the public key based address to the mail client, and the user would have the option to see what that address is. It could even be logged by the client, with TOFU/POP style trust system that reduces the amount of trust you have to place in the server. No need to trust anybody with plaintext. ===== grarpamp... I suggest such interfacing with the current legacy system will only prolong it's long past due extinction. Build a better system and let them come to you, not the other way around. And bolting in exits will only make it harder to do correctly and optimally what you need to do as a P2P system. Please, just forget about interfacing with the legacy transport system. If you really need that you can run your own p2p daemon node that acts as your automated gateway between the two. This is mostly about design of the p2p side, not that. ===== james... It is my understanding of the proposed replacement for email. Magic email addresses that in fact correspond to an identifier of a public key, for example the hash of a rule that identifies the public key, and which result in your message not in fact being passed along by email protocols. ===== grarpamp... If you're not going to send directly to the very long account@nodepubkey, then yes, you'll need to create another layer on top to hold your h(key). However, the key must still be obtainable behind that since that is what the messages will ultimately be encrypted and routed to. It's not much of a stretch beyond that to ensure userland mail tools can handle say 8k long addresses. I'm not against such a [vanity/shorthash] layer. ===== natanael... Bote mail and I2P messenger are two pieces of serverless software that ALREADY is public key addressed within I2P. Have you tried them? You need to add the public keys of the recipients to be able to send a message to start with, although the DHT based search system Seedless allow you to publish Bote mail addresses to the network. (IMAP support for Bote mail is planned but not yet implemented, right now it has a local web interface.) Maybe Namecoin could work together with them to enable you to register your key addresses to your nickname in a secure manner, but then you still have to have a globally unique nickname and tell people the exact spelling. ===== > ralf... > If you are so sure, can you tell us how the next generation secure email > solution will solve the "trust problem", please. grarpamp... Though unclear, that sounds like the old trust of a CA/PKI system problem. > How does the p2p daemon > find the correct crypto key, so that every user can rely on its invisible > performance? In general I suggest that people wish to use messaging with each other once they already know them (or have some other trusted web to them). As in, Hey John, nice to meet ya today, what's your key (address), I'll message you later. Or Hey Jane, what's John's address. Same for employers, businesses, etc. Such peer groups bootstrap and grow very fast. Thus the perceived need for a cold lookup of Ralf, isn't much of a real one. Once you know the address (node crypto key), you put it 'To: <key>', mua hands to spool, p2p daemon reads spool, looks up key in DHT and sends msg off across the transport to the far key (node) when it is reachable. Hopefully the transport looks like I2P/Tor in being a secure random hop layer. In fact, those could probably be used today, they have the keys as nodes and user facing ports for inbound/outbound daemons. They just need scaling work to n-billion nodes (users, aka: the hard part). People are already plugging postfix, bittorrent, etc into these networks. Tor is not currently addressible at the user level by the full key, it 'shortens' the key into a 16char onion address. As you may be hinting at... yes, that is bad... collisions, and needing secondary lookup layers into the full key. Tor may be moving to full key addressibility soon, see tor-dev for that. I2P (and Phantom, and probably GnuNet) are addressible with full keys. So you can send to 'account@key' with them if you want, and keep the John/Jane/Ralf human style lookups in your MUA addressbook (once you know them) without needing a secondary lookup layer into the full key. No, I am not sure. But when looking at some of the p2p transport layers that have come along so far, it seems like a fairly strong possibility for a new backend transport model while retaining user level mail tools... mutt, maildrop, mailman, Thunderbird, etc. Most of what you'd need there is support for very long addresses and split horizon handoff to local daemon/spool based on recognizing what the destination net is... .onion, .i2p, etc. I'd like to read what Pond and I2P-Bote are doing with some parts of this as well. I don't believe you need a trusted CA/PKI service to successfully bootstrap users and their addresses/keys into a new global messaging system. If I want to know what some unknown like Bruce's key is, I'll look it up on his website, social net, list posts, etc. If that's what you mean. ===== bill... I feel like I walking in halfway into a conversation, I'm guessing this started on the cryptography list that I'm not on. Your DHT comment caught my attention though. What in particular about DHTs don't seem scalable or reliable? Seems like DHTs are regularly in the 5-10M range and I don't see any reason that DHTs couldn't be 10 times that. Any reasonable churn rate and reliability could be handled with replication. The bit-torrent DHT for instance claims that 45% of users that bootstrap from a central node are reachable 15 minutes later. So typical setups involve 8 nodes per bin, and 20 bins. So every 15 minutes you ping 160 hosts, only reach 45%, and do some work to repopulate the missing slots. Given the simplicity of the bit-torrent DHT I think there's plenty of room for improvement. Larger routing tables are obvious (at the cost of more network bandwidth to track peers). The most promising idea for DHT improvements I've seen is to divide peers into 3 latency groups. High, medium, and low. Much like L1 cache, L2 cache, and main memory. That way common queries are very fast, yet all queries still to find keys globally. ===== grarpamp... Bittorrent is already in the 100m node range. That's not enough. This needs to replace every possible messaging user on the planet over the duration of their actiive lifetime. That's at least a couple billion nodes. Don't forget, you can always use disk to cache things. ===== > james... > Need a system for handing one's keys around that protects end users from > the horrifying sight of actual keys or actual strong hashes of keys. john... But at the same time the system has to not say, "I can't deliver your message to that person because an invisible gnotzaframmit that I won't describe to you seems to be unavailable to me in the flabogrommit." grarpamp... Address books as usual. Name layer if need be. We are humans, we learn new lexicons, we write manuals, that part is nothing to be afraid of. Being afraid only holds you back. ===== > grarpamp... > I don't believe you need a trusted CA/PKI service to successfully > bootstrap users and their addresses/keys into a new global messaging > system. If I want to know what some unknown like Bruce's key is, I'll > look it up on his website, social net, list posts, etc. If that's what you > mean. > guido... > You can use an untrusted CA to bootstrap. I show how it can be done at: > > http://eccentric-authentication.org/Brucon-Eccentric.pdf ralf... This is an interesting idea, because it provides certificates on demand for ordinary users, if they decide to sign up to a certain site. The certs are then being used for other purposes, so the site does act as a bootstap for using crypto. The one thing that this proposal relies on is the availability of a common piece of software (user agent) that stores the private key for the user. It's this part of the picture where things get tricky. grarpamp... There can be no non-distributed/redundant elements in this p2p system, aka: no 'sites', certainly none with a realworld IP on them, and none where very high percentages of them vanishing will disrupt the system for others. This must replace email, therefore system disruption is intolerable. =====

9 29

Strangecoin
by Bryan Bishop 07 Apr '14

07 Apr '14

No proposed implementation but here's some fun ideas: http://digitalinterface.blogspot.com/2014/03/strangecoin-proposal-for-nonli… """ What's unique about Strangecoin? - Strangecoin transactions can be *nonzero sum*. A Strangecoin transaction might result in *both* parties having more Strangecoin. - Strangecoin transactions can be *one-sided* and can be conducted entirely by only one party to the transaction. - The rate of change of one's Strangecoin balance is a more important indicator of economic influence than the balance itself. - Optimal investment strategy in Strangecoin aims to *stabilize* one's balance of Strangecoin. - A universal account provides all users a basic Strangecoin income, effectively unlimited wealth, and direct feedback on the overall prosperity of the network. .... As the example suggests, the dynamics of Strangecoin might be usefully thought of in terms of a "reputation system" rather than a strictly financial tool, even though the basic mechanics involve the regular method of exchanging currency for goods perceived by both parties to be of equal value. Because of the nonlinear relationships among Strangecoin users, each user effectively draws on a network of support in each economic transaction, coupling its activity to the successes (and failures) of the that network of activity. The result is a model of the complex interdependencies within a community of economic agents, and the dynamics by which those networks develop and decay. For this reason, Strangecoin might have implications for quantifying the role of individual choices and responsibility in the context of corporate action, and for resolving other difficult issues in the management and ethics of collective economic action. """ https://news.ycombinator.com/item?id=7494709 """ Other comments suggest that this can be implemented with existing tools, which I take as a virtue of the proposal. In any case, John von Neumann proved a long time ago that any nonzero sum game with n players can be modeled as a zero sum game with n+1 players, where the n+1 player represents the global state. TUA is simply an implementation of this proof. http://en.wikipedia.org/wiki/Zero-sum_game#Extensions I tried to explain inhibition in another comment in this thread. https://news.ycombinator.com/item?id=7496858 I give an an analogy in the proposal of the popularity of a celebrity couple being a nonlinear relationship to the popularity of each celebrity individually. I think our intuitive understanding of our social relationships is nonlinear in this way generally, and I think Strangecoin can model those nonlinear relationships well. So, for instance, I'm imagining a family, spouses, close friends, and so on entering into extended coupling transactions, so that as a community their prosperity rises and falls together. I might also enter into such transactions with certain business with whom I want to couple my activities, and these coupling transactions might serve in lieu of direct billing or payment. A coupling relationship with a business is effectively a contract, but with traditional currency you need the whole legal framework of contracts to support the transaction, and with Strangecoin the transaction is built directly into the currency, and the interface looks almost exactly like a point-of-sale cash transaction. And I can enter into less serious relationships of varying degrees with other parties. The effect is a way of managing not just financial transactions, but also reputation, investment, and other dynamics social constraints on the economy via the currency itself. Money is memory ( http://www.minneapolisfed.org/research/sr/sr218.pdf) but our existing currencies only represent some aspects of our economic activity, and therefore put limits on the memory stored in the economy. A nonlinear coin like Strangecoin can embed that social knowledge in the currency itself, providing a more robust memory framework on which we can conduct our economic transactions. I only hint at this in the proposal, but I suspect a system like this is required to resolve the twisted legal artifice the corporate veil, because it quantifies explicitly the role individuals have in collective economic activity, and thereby gives a method for explicitly holding persons proportionally responsible (in both credit and blame) for their contributions to that activity. But I think that's a much more radical proposal than the one I've offered for Strangecoin, and I should probably only be defending that here. =) """ - Bryan http://heybryan.org/ 1 512 203 0507

3 2

Let's Make a Deal
by dan＠geer.org 31 Mar '14

31 Mar '14

If I were Obama, I would offer Putin and Netanyahu a three way deal, we get Snowden, Israel gets Jonathan Pollard, and Russia gets Gregory Londin (or equivalent). But wait, Obama is going to give Pollard away for far less http://news.yahoo.com/u-could-free-israeli-spy-deal-save-peace-164934422.ht… --dan

1 0

"Nicely done Steve and kudos! All points . . . are as accurate as I've ever seen,"
by coderman 30 Mar '14

30 Mar '14

http://www.bostonglobe.com/metro/2014/03/29/the-inside-story-mit-and-aaron-… The inside story of MIT and Aaron Swartz More than a year after Swartz killed himself rather than face prosecution, questions about MIT's handling of the hacking case persist By Marcella Bombardieri | Globe Staff March 30, 2014 CAMBRIDGE -- The mysterious visitor called himself Gary Host at first, then Grace Host, which he shortened for his made-up e-mail address to "ghost," a joke apparently, perhaps signaling mischievousness -- or menace. The intruder was lurking somewhere on the MIT campus, downloading academic journal articles by the hundreds of thousands. The interloper was eventually traced to a laptop under a box in a basement wiring closet. He was Aaron Swartz, a brilliant young programmer and political activist. The cascade of events that followed would culminate in tragedy: a Secret Service investigation, a federal prosecution, and ultimately Swartz's suicide. But in the fall of 2010, Swartz was still a stranger in the shadows, and the university faced a hard question: How big a threat was the "ghost" downloader? And a harder one: What should be done about him? Answering those questions would prove a particularly knotty puzzle for the Massachusetts Institute of Technology, a place long supportive of the free flow of information and so famously friendly to pranks, known in MIT lingo as hacks, that a book published by the MIT Museum in the 1990s offered pranksters such tips as "always have two ways to run." And yet, MIT is a cradle of world-class scientific research with unpublished data and unpatented inventions on its network, and its leaders felt vulnerable to the rising tide of high-tech espionage. "There is some speculation that this might have been an MIT student experimenting with a robot," one MIT employee noted in an e-mail after a second breach by Swartz was discovered. But another pointed out that "sinister foreigners'' may have stolen credentials or compromised a computer. MIT's efforts to track down Swartz, while under intense pressure from JSTOR, the not-for-profit that ran the journal database, eventually would lead to felony computer crimes charges that might have brought years in jail. Swartz, 26, was under indictment when he committed suicide in January 2013. Critics, both on campus and around the world, have accused MIT of abandoning its values celebrating inventive risk-taking by helping to doom a young man whose project -- likely an act of civil disobedience to make information freely available -- didn't in the end cause serious harm. MIT has insisted it maintained an appropriate, even compassionate, neutrality toward a determined hacker who stole 4.8 million articles and eluded numerous efforts to stop him before the college sought help from police. But MIT's brand of neutrality proved one with notable limits, according to a Globe review of more than 7,000 pages of discovery documents -- many of them e-mails -- from Swartz's court case. In the wake of his death, both MIT and JSTOR posted online documents that they had turned over to authorities, a trove that drew little if any notice at the time. The Globe also obtained a number of e-mails related to the case not available publicly. Only with a patient review of the complete record does the full picture of the dilemma MIT faced become clear. The aftershocks of the choices the institution made in the wake of the "ghost" continue to reverberate, on campus and off, more than a year after Swartz's death. Most vividly, the e-mails underscore the dissonant instincts the university grappled with. There was the eagerness of some MIT employees to help investigators and prosecutors with the case, and then there was, by contrast, the glacial pace of the institution's early reaction to the intruder's provocation. MIT, for example, knew for 2 1/2 months which campus building the downloader had operated out of before anyone searched it for him or his laptop -- even as the university told JSTOR they had no way to identify the interloper. And once Swartz was unmasked, the ambivalence continued. MIT never encouraged Swartz's prosecution, and once told his prosecutor they had no interest in jail time. However, e-mails illustrate how MIT energetically assisted authorities in capturing him and gathering evidence -- even prodding JSTOR to get answers for prosecutors more quickly -- before a subpoena had been issued. In a handful of e-mails, individual MIT employees involved in the case aired sentiments that were far from neutral. One, for example, gushed to prosecutor Stephen P. Heymann about the quality of the indictment of Swartz. "Nicely done Steve and kudos! All points . . . are as accurate as I've ever seen," wrote the information technology employee. "(I only say that because every time I've ever given an interview, details are always slightly to horribly munged; not that I ever expected any less, it's just a true relief and very refreshing to see your accuracy and precision)." Yet if MIT eventually adopted a relatively hard line on Swartz, the university had also helped to make his misdeeds possible, the Globe review found. Numerous e-mails make it clear that the unusually easy access to the campus computer network, which Swartz took advantage of, had long been a concern to some of the university's information technology staff. Some at MIT believed that officials had failed to pay serious attention to what one person called "poor, limited, or outdated security protections" on resources like the JSTOR database. The documents also put JSTOR's role in the case in a new light. In contrast to MIT, the journal archive organization has been widely hailed for publicly distancing itself from Swartz's prosecution, declaring that once Swartz returned the documents, it "had no interest in this becoming an ongoing legal matter." But a number of JSTOR's internal e-mails show a much angrier face in the months that Swartz eluded capture, with employees sharing frustration about MIT's "rather tepid level of concern." JSTOR officials repeatedly raised the prospect, among themselves, of going to the police, e-mails show. "What's wrong with us . . . alerting the cyber-crimes division of law enforcement and initiating an investigation, having a cop search a dorm room and try to retrieve any hard drive that contains our content?" asked one JSTOR official, whose name -- like most -- was redacted in the released documents. In the end, JSTOR neither called the police nor asked MIT to do so, according to its president. Eric Grimson, who recently stepped down as chancellor of MIT, defended the university's handling of the case as a judicious effort to protect the community without seeking retribution. MIT's first steps, he said, were simply to deny the downloader access to the network. They didn't search for the laptop for many weeks because they thought he had been thwarted. When Swartz proved undeterred, he said, MIT had to do more. "We were confronted with a situation of an unknown user accessing our network," he said in an interview, "using it to download massive amounts of material . . . for a three-month period, and evading our efforts to try and stop it." MIT was harmed in the process, Grimson said, with 10,000 researchers denied an important resource for several days as JSTOR sought to cut off the mass downloading. Helping investigators pursue the campus intruder was the only reasonable course, he said. "I think we should as a matter of principle cooperate with law enforcement in an investigation of an alleged crime being committed on our campus," he said. "That's protecting our community." After Swartz's arrest, Grimson said, the university went out of its way to be fair to the defense, voluntarily making staff members available to answer questions from Swartz's attorneys. "I would like to suggest we took a path to try to balance being empathetic to Aaron's situation while acknowledging that there was a legal process involved," he said. Allure of openness Swartz was an Internet prodigy. By age 19, he had helped to build RSS, a service that allowed users to create personalized news feeds; to develop the social news website Reddit; and to establish Creative Commons, an alternative to traditional copyright more friendly to sharing. In his 20s, the restless Stanford dropout turned his energies to political activism. He helped launch several progressive political groups and was a major force behind a national wave of protest against the Stop Online Piracy Act, which targeted unauthorized sharing of videos and music, but which Swartz and others saw as an attack on free speech. While Swartz's motive for downloading the JSTOR archive remains unknown, there is one simple and plausible possibility: to make academic research freely available to the public. In 2008, he published a "Guerrilla Open Access Manifesto" in which he avowed a "moral imperative" to share scholarship locked behind exorbitant subscription walls. "It's time to come into the light and, in the grand tradition of civil disobedience, declare our opposition to this private theft of public culture," he wrote. But why use MIT as his gateway -- or, to some eyes, his victim? He had a fellowship at Harvard at the time, which gave him access to JSTOR, but apparently worried about getting himself or his colleagues in hot water, since bulk downloading is forbidden by JSTOR. Since MIT had been known for generations for its idealistic devotion to the spirit of openness, venturing a couple of miles down Massachusetts Avenue may have seemed irresistible to Swartz. He had no formal tie to the university but had friends there and had been involved in campus activities. A blog entry Swartz wrote in 2009, titled "Honest Theft," neatly details his view of the school as a haven for rebelliousness. He described friends who he said secretly lived for free on campus, sleeping on couches in common rooms and stealing food from the cafeterias -- and using the money they saved "to promote the public good." "MIT has a notoriously relaxed security policy," he wrote, so his friends "likely wouldn't get in too much trouble." Indeed, MIT's own 180-page internal report on the Swartz case, released in July by a panel led by professor Hal Abelson, described a "culture of creative disobedience where students are encouraged to explore secret corners of the campus, commit good-spirited acts of vandalism . . . and resist restrictions that seem arbitrary or capricious." Student "hacks" have included putting a faux firetruck on the MIT Great Dome and turning a high-rise facade into a working Tetris game. They are meant to be public and harmless, but often involve trespassing and "borrowing" materials without permission, like a 3-ton cannon brazenly snatched from Caltech. The ethic of openness extends to MIT's computer network, where anyone on campus can get onto the wired network for 14 days by logging on as a guest, an extremely unusual perk for visitors to a university campus. As an MIT manager of network security noted in an e-mail reviewing the downloading case as it unfolded in October 2010, misuse of the MIT network was made possible by the fact that there was "no authentication of visitors" and "no identity verification." The open-door policy meant Swartz could easily sign in, as he did, as an anonymous guest with fake names and disposable e-mail addresses. Between 5 p.m. on Sept. 25, 2010, and 4 a.m. the next morning, the code Swartz wrote, which he called "keepgrabbing," downloaded 450,000 JSTOR articles. It was the opening salvo in a cat-and-mouse game that would extend over three months. JSTOR would cut off the Internet protocol address Swartz was using; he would switch to another. MIT detected and shut down the registration for his computer; he altered his computer's identifying information. Officials would conclude the ghost downloader had moved on, then he'd reappear weeks later. The maddening pursuit prompted some MIT technology personnel to say, essentially, I told you so. Databases like JSTOR's, some said, should have been kept behind a virtual gate -- though this would inconvenience legitimate users. "I frankly don't know why it's not used more," an employee wrote about such a security measure. Another employee in network security lamented that only the Swartz case prompted MIT to smarten up. "I hope it helps enlighten them to the need to really think long and hard about these issues. Kind of silly that it took a JSTOR crawling issue to get everyone a little frenzied." MIT and JSTOR did agree to a security upgrade after Swartz's second round of downloading was discovered in October 2010, requiring those seeking access to have MIT credentials. But it took JSTOR weeks to prepare for the change, the e-mails show. That delay would prove fateful. Aaron Swartz had only gotten started. Drawing concern at JSTOR Given the institution's global stature, MIT inevitably drew most of the public focus. But what Swartz did was more of a threat to JSTOR, a small organization in a precarious position. Its business is selling access to journal articles, but it doesn't own those articles. If it can't protect them, the journals could yank their material out of the library and threaten JSTOR's survival. Swartz ultimately downloaded 80 percent of JSTOR's archive, 4.8 million articles. At one point his downloading was so rapid, JSTOR e-mails said it created "a monstrous amount" of traffic that was "threatening the website." The stakes for MIT were murkier. The university's contract with JSTOR promised that it would guard against misuse, so there was some risk of losing an important library resource. And a rogue stranger poking around MIT's network could be truly dangerous. The discovery shortly before Swartz's arrest that his computer was being contacted from China raised passing fears of a foreign cyberattack, e-mails show, although such probing from overseas is quite routine. Yet MIT was used to seeing excessive downloading -- albeit on a much smaller scale -- and some staff downplayed the threat. "There will always be one person a semester who, regardless of intent, will write a script to crawl through some catalog," an MIT employee wrote when JSTOR first cut off the portion of campus where Swartz was operating. The MIT worker called JSTOR's move "draconian" and "knee-jerk." The result of their differing vulnerabilities, e-mails indicate, was that JSTOR was far more bellicose toward the interloper than was MIT -- at least until the days right before Swartz's arrest. JSTOR pressed again and again for MIT to find the downloader. Some of the archive's employees said MIT was being cooperative, but other staff members were irate at the university. "I am sure that if they had lost an equivalent number of books from their library overnight (what 25,000-30,000 books) they would not be so nonchalant," someone at JSTOR wrote in an e-mail. "This is an astronomical number of articles -- again, real theft," another wrote. "Does the university contact law enforcement? Would they be willing to do so in this instance?" When Swartz popped up again in late December after weeks of quiet, the tension was even plainer. "I might just be irked because I am up dealing with [the downloader] on a Sunday night," a JSTOR employee wrote, "but I am starting to feel like [MIT needs] to get a hold of this situation and right away or we need to offer to send them some help (read FBI)." These were "heat of the moment" reactions by officials anxious about an unknown threat, said Kevin M. Guthrie, president of ITHAKA, JSTOR's parent organization. "You get a report that 100,000 articles have been downloaded on a Saturday, you're trying to figure out what to do," he said in an interview. As for JSTOR's internal comments about calling the police, he said, "We talked about it, but we made a decision -- no, this wouldn't be appropriate; it's not our role to indicate that law enforcement should be called." When it came to Swartz's prosecution, JSTOR was notably reticent. It insisted on being served with a subpoena before it would provide information to the government and then, according to Abelson's report, tried to limit its answers. Guthrie told the Globe that the not-for-profit was simply trying to be careful. As for its decision to publicly oppose prosecution, he said, once Swartz returned the files, the journal provider was no longer interested in the matter. JSTOR was "trying to balance our obligation both to be good stewards of the content for the content owners and publishers, for our own viability, for broad access to information, and then the personal situation, the human situation," Guthrie said. JSTOR's very existence, he said, is all about broadening access to scholarly journals. Its fees go to support the archive, and it provides free access in developing countries. E-mails from before Swartz was captured suggest that JSTOR might also have been worried about its public image. The archive is already viewed in some quarters as a greedygatekeeper constricting the pursuit of knowledge. One JSTOR employee, in an e-mail addressing the possibility of bringing in law enforcement, noted several technical obstacles after opening with, "aside from the considerations about the PR of it all . . . " A sudden shift If MIT was initially slow to react to the "ghost," even tepid about the whole thing as some at JSTOR surmised, that changed drastically after the university learned of another breach in December 2010. After the laptop Swartz was accused of setting up to download JSTOR articles was found in a wiring closet at MIT, investigators left the computer up and running and installed a hidden camera. On the night after Christmas, JSTOR discovered a new round of downloading. It had actually started some 10 weeks earlier, but Swartz had slowed the process enough to avoid tripping alarms. Out on a furlough, MIT staff did not get the urgent messages from JSTOR until Jan. 3, 2011. "This is a heck of a way to start the new year," one person at MIT wrote. "We need to escalate the seriousness of our response. This looks like grand theft." And escalate MIT did. The academic building where the activity seemed to emanate from had been pinpointed in mid-October. But only on the morning of Jan. 4 did a network engineer began searching Building 16. He quickly discovered a laptop, hidden under a cardboard box, connected to the network from a wiring closet in the basement. MIT police decided they needed more help, and called a Cambridge police detective who belonged to a regional electronic crimes task force. He showed up with another task force member, a Secret Service agent named Michael S. Pickett. Seeking not only to find the downloader but to collect as much evidence as possible, they set up a hidden camera in the wiring closet. And instead of shutting down the laptop, the authorities decided to "leave it up and running for a couple of days while the investigation continues," a library employee wrote in an e-mail. "Now a federal case," the library staffer wrote in separate notes she took on a conversation with an MIT security analyst. "We [MIT] are considered the victim. All we provide is by choice -- not subpoenaed." That cooperation with law enforcement also extended to a senior MIT network engineer who monitored traffic to and from Swartz's laptop and appeared to be looking to Pickett for instructions. On Jan. 5, having collected 70 gigabytes of network traffic, he e-mailed the agent, "I was just wondering what the next step is." Swartz's lawyers argued that MIT, by monitoring Swartz and turning over materials to law enforcement without a court order, violated his Fourth Amendment rights. Abelson, who wrote MIT's own review, disagreed, and legal experts interviewed by the Globe differed on whether those arguments had merit. They were never ruled on by the judge in the case. Grimson, the former university chancellor, acknowledged in an interview that it would have been "cleaner" to ask prosecutors to seek a court order sooner. Turning over evidence without a subpoena raised, in some eyes, painful questions about MIT's avowed neutrality. Swartz was identified by the hidden camera and arrested on Jan. 6 after allegedly trying to flee police on Massachusetts Avenue in Cambridge. The startling discovery that the "ghost" downloader was a well-known activist prompted a few MIT employees to share their opinions with Pickett, the Secret Service agent, or their colleagues. "Looks like he is a big hacker, i googled him," one wrote to Pickett at midnight the morning after Swartz's arrest. That afternoon, someone from the IT security department wrote to Pickett, deeming Swartz a "really intelligent kid that just got buried under an avalanche of dumb." A few days later, Swartz took to Twitter to ask his followers if they knew anyone at JSTOR, presumably hoping he could defuse the situation. One person at MIT responded by circulating among colleagues a made-up message purporting to be what Swartz wanted to say to JSTOR. "hi, jstor, I'm still a few million pdf's shy of grabbing your whole db; really had high hopes on collecting the whole set by 1/1/11," it read. "could you tell me what number I left off at, because I don't currently have access to my lappy that was keeping track. k thnx bye." The MIT employee's commentary on his or her own fictional tweet: "LOL." The documents say little about what MIT was thinking and doing once the case morphed from an investigation into an active prosecution. But MIT's own report on the case raises serious questions about the wisdom of MIT's neutrality stance. The report noted that some within MIT believe "there has been a change in the institutional climate over recent years, where decisions have become driven more by a concern for minimizing risk than by strong affirmation of MIT values." The Computer Fraud and Abuse Act has been widely condemned as extreme in both its sweeping scope and its grave punishments. Sentencing guidelines suggest Swartz faced up to seven years in prison. To his supporters, MIT bears some responsibility for that fact. MIT officials privately told the prosecutor that the university had no interest in jail time, but refused to oppose his prosecution publicly or privately, despite repeated entreaties from Swartz's father, his lawyers, and a couple of faculty members, who argued MIT had the institutional heft to influence the US attorney's office. MIT may have also missed an opportunity to point out a potentially serious flaw in the case against Swartz. The Computer Fraud and Abuse Act charges centered on the claim that Swartz had unauthorized access to MIT and JSTOR's networks. But even if he was doing something improper, Swartz was logged on at MIT as a guest, leading Abelson and some legal observers to conclude that his access could be construed as authorized. It was hardly a clear-cut case, and the judge may not have agreed. But either way, MIT -- resolute about not getting drawn into a criminal case to which it was not a named party -- "paid little attention to the details of the charges," Abelson found. The institute simply did not consider whether Swartz may have been an authorized user under the terms of the law, according to the report. The defense didn't raise it, either, until close to Swartz's death. MIT was helping the prosecution "understand how to prosecute, what information is necessary to prosecute, but not taking steps to help them understand the limits to their prosecution," said Lawrence Lessig, a Harvard Law School professor who was close to Swartz. "Nobody would call that neutral. That's aiding and abetting the prosecution.'' Grimson defended MIT's decision to leave it up to the justice system to decide Swartz's fate, given that MIT leaders believe he harmed the school. And he disagreed that MIT is less driven by its ideals than it once was. He pointed to the Abelson report as an example of MIT's willingness to soul-search and learn from a tragedy. Still, he said, MIT will be second-guessing itself for a long time, and the university is still considering some policy changes in light of what happened to Swartz. Its first concrete move, last month, was to set up a presidential committee that will create an online data privacy policy. A famously sensitive person, Swartz had some history with depression. Yet loved ones insist that he was not clinically depressed before he hanged himself in his Brooklyn apartment on Jan. 11, 2013, but overwhelmed by the threat of years injail and the toll of fighting the charges. His father, Bob Swartz, believes that MIT's lack of compassion helped destroy his son's life. "We can't bring Aaron back, he can no longer be the tireless worker for good," he said at a memorial service for his son held at MIT last spring. "What we can do is change things for the better. We can work to change MIT so that it . . . once again becomes a place where risk and coloring outside the lines is encouraged, a space where the cruelties of the world are pushed back and our most creative flourish rather than being crushed."

1 0

if only "There is one mode; it is secure." ... maybe one day?
by coderman 30 Mar '14

30 Mar '14

"Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS" - https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-00 """ dldhe8192 ... Its hexadecimal representation is: XXX ...still calculating... XXX ... """

1 0

DOJ Pushes to Hack Cyber-Criminals (Torizens)
by grarpamp 28 Mar '14

28 Mar '14

http://blogs.wsj.com/law/2014/03/27/doj-pushes-to-expand-hacking-abilities-… http://arstechnica.com/tech-policy/2014/03/feds-want-an-expanded-ability-to… http://news.slashdot.org/story/14/03/28/0242232/doj-pushes-to-expand-hackin… http://yro.slashdot.org/story/14/03/28/195200/cispas-author-has-another-pri… http://edition.cnn.com/2014/03/27/living/student-money-saving-typeface-gara…

1 0