January 2014 - cypherpunks - lists.cpunks.org

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

07 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 17 Aug '16

17 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

QUANTUMINSERT "wide stack" covert network communication
by coderman 13 Mar '14

13 Mar '14

in the discussion regarding well positioned injection points on the backbone (QUANTUMINSERT) i have not yet seen discussion of using these well positioned injection points for covert network connections. consider that you are eavesdropping on return path for a given un-used, high address space of a third party (a lot of that 15.0.0.0/8 is idle :) consider that you can inject arbitrary packets into the egress for same net block (even if upstream, still sufficient to match route). you can now establish a covert TCP connection appearing to come from the high space of 15.0.0.0/8, of which HP only sees the returning (encrypted) martians. (and this assumes they're even watching!) this "wide stack" approach provides cover via multitudes of idle address spaces of third parties, while the actual communicators are hidden. anxiously awaiting the details on how this is used... *sacrifices chickens to the "Snowden Release Gatekeepers" (TM)*

1 2

Re: Jim Bell comes to Cypherpunks?
by Jim Bell 11 Mar '14

11 Mar '14

Twitter for me? My impression is that this is more for issues where seconds, minutes, or hours count. I don't know who I'd want to follow so closely as to monitor Twitter. As for me saying something? Well, I don't know if I have that much to say. It's not like I don't have opinions...I have many of them. But, right now the world is awash in opinions, from blogs to twitter. What would I talk about...uh...other than the obvious? What, in general, would people want ME to talk about? Further, right now my main interest is in promoting and developing my isotope-modified fiber optic invention. http://www.freepatentsonline.com/WO2013101261A1.html Jim Bell ________________________________ From: cypherpunks <cypherpunks(a)riseup.net> To: John Gilmore <gnu(a)toad.com> Cc: "barlow(a)eff.org" <barlow(a)eff.org>; Bell Jim <jamesdbell8(a)yahoo.com>; "cypherpunks(a)riseup.net" <cypherpunks(a)riseup.net> Sent: Wednesday, January 1, 2014 1:45 PM Subject: Re: Jim Bell comes to Cypherpunks? I've no idea if there're any physical cpunks meetings. Living in Europe and visiting some hacker conferences and hackerspaces from time to time. Guess - it would be you Golden State guys to do some. On the other side - Jim, how about open a twitter account and be part of the social media thingy too? :) --Michael Am 01.01.2014 um 20:08 schrieb John Gilmore <gnu(a)toad.com>: > Are there physical cypherpunks meetings these days? I don't know of any. > There are many hackerspaces in various cities that have regular meetings, > but I don't attend any and don't know which ones relate to cypherpunk > topics. > > We (or anybody) could restart such meetings, I suppose... > > John

7 11

consistent pcp/pbp formats (was: Curve p25519 Replacements for GnuPG?(x2 now) ..)
by Thomas von Dein 14 Feb '14

14 Feb '14

> consistent key formats are critical more than fine with me. > need to converge on: > - endianness I'm currently using big endian for multibyte values whereever they appear. It's already verified to work on little and big endian platforms (e.g. tested on aix/ppc) > - coordinate representation x, x&y, x and sign ... > or bits to show which of these ... perhaps borrow ANSI method Could you please explain this further? > - hint / indication of cipher suite / curve In pcp there's already such a hint included in exported keys, however I'm not using it, since there's no choice of different curves in libsodium so far. But it's on the list. > - text encoding of binary format (ascii) As already stated in the other subthread, I use Z85, while stef is using base85. Since Z85 is a subset of base85, I'm pretty sure we can agree on something. > - human readable format There's a human readable version of keys in pcp, but the tool itself doesn't use it (example attached). It uses the z85 encoded binary part of such a file. pcp has some more fields stored in a key than pbp: - a key id (e.g. 0x54E9C62E1852EBC5) which is required to identify a key - some text fields (owner, mail) - a serial number - key format version number I'm not sure, how stef solved the ed25519 issue (you can't use a curve25519 secret key to create an ed25519 signature directly). After some discussion on the libsodium mailinglist we came up with this: When the user generates a new key, the ed25519 secret key will be generated first. The curve25519 secret will be derived from that, since the ed25519 already contains a usable curve25519 key. In pcp I store both of them for easier access, so the ed25519 and curve25519 secret and public keys are stored, the secret keys are encrypted and I store the nonce as well (see include/pcp/key.h). Speaking of key encryption: @stef: according to your docs you're already using scrypt() for key derivation. I'd like to use that as well, but it's not part of libsodium (afaik), so I use my own method for this til scrypt() is implemented in libsodium. That's because I want to avoid writing crypto code myself. Maybe we should iron out the details off-list? bes, Tom -- PGP Key: https://www.daemon.de/txt/tom-pgp-pubkey.txt S/Mime Cert: https://www.daemon.de/txt/tom-smime-cert.pem Bitmessage: BM-2DAcYUx3xByfwbx2bYYxeXgq3zDscez8wC -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

6 23

and not a single Tor hacker was surprised...
by coderman 13 Feb '14

13 Feb '14

Scientists detect “spoiled onions” trying to sabotage Tor privacy network Rogue Tor volunteers perform attacks that try to degrade encrypted connections. by Dan Goodin - Jan 21 2014, 2:42pm PST http://arstechnica.com/security/2014/01/scientists-detect-spoiled-onions-tr… or reason #16256 to crypto end to end... --- Computer scientists have identified almost two dozen computers that were actively working to sabotage the Tor privacy network by carrying out attacks that can degrade encrypted connections between end users and the websites or servers they visit. The "spoiled onions," as the researchers from Karlstad University in Sweden dubbed the bad actors, were among the 1,000 or so volunteer computers that typically made up the final nodes that exited the Tor—short for The Onion Router—network at any given time in recent months. Because these exit relays act as a bridge between the encrypted Tor network and the open Internet, the egressing traffic is decrypted as it leaves. That means operators of these servers can see traffic as it was sent by the end user. Any data the end user sent unencrypted, as well as the destinations of servers receiving or responding to data passed between an end user and server, can be monitored—and potentially modified—by malicious volunteers. Privacy advocates have long acknowledged the possibility that the National Security Agency and spy agencies across the world operate such rogue exit nodes. The paper—titled Spoiled Onions: Exposing Malicious Tor Exit Relays—is among the first to document the existence of exit nodes deliberately working to tamper with end users' traffic (a paper with similar findings is here). Still, it remains doubtful that any of the 25 misconfigured or outright malicious servers were operated by NSA agents. Two of the 25 servers appeared to redirect traffic when end users attempted to visit pornography sites, leading the researchers to suspect they were carrying out censorship regimes required by the countries in which they operated. A third server suffered from what researchers said was a configuration error in the OpenDNS server. The remainder carried out so-called man-in-the-middle (MitM) attacks designed to degrade encrypted Web or SSH traffic to plaintext traffic. The servers did this by using the well-known sslstrip attack designed by researcher Moxie Marlinspike or another common MitM technique that converts unreadable HTTPS traffic into plaintext HTTP. Often, the attacks involved replacing the valid encryption key certificate with a forged certificate self-signed by the attacker. "All the remaining relays engaged in HTTPS and/or SSH MitM attacks," researchers Philipp Winter and Stefan Lindskog wrote. "Upon establishing a connection to the decoy destination, these relays exchanged the destination's certificate with their own, self-signed version. Since these certificates were not issued by a trusted authority contained in TorBrowser's certificate store, a user falling prey to such a MitM attack would be redirected to the about:certerror warning page." >From Russia with love The 22 malicious servers were among about 1,000 exit nodes that were typically available on Tor at any given time over a four-month period. (The precise number of exit relays regularly changes as some go offline and others come online.) The researchers found evidence that 19 of the 22 malicious servers were operated by the same person or group of people. Each of the 19 servers presented forged certificates containing the same identifying information. The virtually identical certificate information meant the MitM attacks shared a common origin. What's more, all the servers used the highly outdated version 0.2.2.37 of Tor, and all but one of the servers were hosted in the network of a virtual private system providers located in Russia. Several of the IP addresses were also located in the same net block. The researchers caution that there's no way to know that the operators of the malicious exit nodes are the ones carrying out the attacks. It's possible the actual attacks may be carried out by the ISPs or network backbone providers that serve the malicious nodes. Still, the researchers discounted the likelihood of an upstream provider of the Russian exit relays carrying out the attacks for several reasons. For one, the relays relied on a diverse set of IP address blocks, including one based in the US. The relays frequently disappeared after they were flagged as untrustworthy, researchers also noted. The researchers identified the rogue volunteers by scanning for server relays that replaced valid HTTPS certificates with forged ones. That might have helped to detect certificate forgery attacks such as the one used in 2011 to monitor 300,000 Gmail users—wouldn't be detected using the methods devised by the researchers. The researchers don't believe the malicious nodes they observed were operated by the NSA or other government agencies. "Organizations like the NSA have read/write access to large parts of the Internet backbone," Karlstad University's Winter wrote in an e-mail. "They simply do not need to run Tor relays. We believe that the attacks we discovered are mostly done by independent individuals who want to experiment." While the confirmation of malicious exit nodes is important, it's not particularly surprising. Tor officials have long warned that Tor does nothing to encrypt plaintext communications once it leaves the network. That means ISPs, remote sites, VPN providers, and the Tor exit relay itself can all see the communications that aren't encrypted by end users and the parties they communicate with. Tor officials have long counseled users to rely on HTTPS, e-mail encryption, or other methods to ensure that traffic receives end-to-end encryption. The researchers have proposed a series of updates to the "Torbutton" software used by most Tor users. Among other things, the proof-of-concept software fix would use an alternative exit relay to refetch all self-signed certificates delivered over Tor. The software would then compare the digital fingerprints of the two certificates. It's feasible that the changes might one day include certificate pinning, a technique for ensuring that a certificate presented by Google, Twitter, and other sites is the one authorized by the operator rather than a counterfeit one. Several hours after this article went live, Winter published this blog post titled What the "Spoiled Onions" paper means for Tor users.

8 14

Re: [p2p-hackers] The next gen P2P secure email solution
by grarpamp 02 Feb '14

02 Feb '14

On Fri, Jan 10, 2014 at 12:58 AM, James A. Donald <jamesd(a)echeque.com> wrote: > On Mon, Dec 30, 2013 at 12:34 AM, ianG <iang(a)iang.org> wrote: >> >> So sad. I have a clue and don't trust Skype. But I can't for the life of >> me migrate my friends off of it. It's as addictive as crack. It's just >> better than the alternatives. > > > Anything that is as good as skype is going to allow contact tracing, that > this person talks to that person. No... we are specifically talking about developing decentralized solutions here, so that that centralized lookup authority context and risk goes away. Yes... a low latency non-fixed-length non-chaffed network will still have some characteristic risks... timing, etc. Yet likely nowhere near the order of the above centralized issues. > But it does not have to allow mass interception (the original skype did not > allow mass interception), and it does not have to allow undetectable > interception, which the original skype did allow. That is just designing good applied crypto in the former, which nullifies the latter.

3 3