November 2013 - 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

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

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

Omidyar influence in new Greenwald venture [was: SRF: cryptic]
by coderman 07 Jan '14

07 Jan '14

On Sun, Oct 20, 2013 at 6:11 PM, coderman <coderman(a)gmail.com> wrote: > ... this should be tempered with appropriate caution: > "Six Degrees of Omidyar" > http://tomslee.net/2013/09/six-degrees-of-omidyar.html > who will surely show up in any Open Data effort making progress... also involved in: """ Glenn Greenwald, who has published many of the most important scoops from the Edward Snowden leaks, is leaving The Guardian and setting up a new media venture with long-time journalist Laura Poitras and Jeremy Scahill from The Nation. The venture is being funded by eBay founder Pierre Omidyar, who has suggested that he's prepared to invest more than $250 million in the new venture. """

4 7

Open phones for privacy/anonymity applications, Guardian
by grarpamp 10 Dec '13

10 Dec '13

A few links... http://neo900.org/ http://projects.goldelico.com/p/gta04-main/ https://jolla.com/ http://www.fairphone.com/ http://hardware.slashdot.org/story/13/11/02/1637236/openphoenux-neo900-bill… More interesting platforms for even Guardian or other OS than any Nexus 5 or alike hardware, no? https://guardianproject.info/hardware/ http://unrevoked.com/rootwiki/doku.php/public/root_friendly http://wiki.cyanogenmod.org/w/Devices

8 10

good clocks (not using GPS) and multi-channel hw [was: sidebands of great justice]
by coderman 09 Dec '13

09 Dec '13

On Thu, Nov 7, 2013 at 11:32 PM, coderman <coderman(a)gmail.com> wrote: > ... > SDR MIMO kit leaves much to be desired, however. let me clarify: the hardware available for SDR MIMO development leaves much to be desired. ... the blocks and implementations for OFDM coding in software are OK :) USRP N2X0 can do it, other setups require external reference clock with high fidelity. any recommendations for non-GPS clocks performing at 50-100ppb or better?

3 4

Re: [Full-disclosure] Secure whistleblowing feedback / reporting systems in the content of compartmented information, endpoint security [was: [NSA bitching] [formerly Re: PRISM][]]
by coderman 06 Dec '13

06 Dec '13

On Fri, Oct 18, 2013 at 4:40 AM, <dan(a)geer.org> wrote: >... > http://geer.tinho.net/geer.uncc.9x13.txt an interesting discussion :) "This is perhaps our last fundamental tradeoff before the Singularity occurs: Do we, as a society, want the comfort and convenience of increasingly technologic, invisible digital integration enough to pay for those benefits with the liberties that must be given up to be protected from the downsides of that integration?" -- dan i would argue that there is an alternative in design and architecture, mainly those which decentralize and protect end-to-end. however, there is a cost attached to these efforts as well, which so far most opt-out of paying... best regards,

2 2

ntru-crypto - Open Source NTRU Public Key Cryptography Algorithm and Reference Code
by coderman 03 Dec '13

03 Dec '13

https://github.com/NTRUOpenSourceProject/ntru-crypto """ Security Innovation, Inc., the owner of the NTRU public key cryptography system, made the intellectual property and a sample implementation available under the Gnu Public License (GPL) in 2013 with the goal of enabling more widespread adoption of this superior cryptographic technology. The system is also available for commercial use under the terms of the Security Innovation Commercial License. NTRU represents a significant improvement in the Public Key cryptography world—it’s faster, stronger and smaller than virtually any other system in use and it’s quantum computer resistant, making it the best choice for current projects with lifetimes that extend into the post quantum computer age.... NTRU is a lattice-based public key cryptosystem from Security Innovation and the leading alternative to RSA and Elliptic Curve Cryptography (ECC) due to its higher performance and resistance to attacks from quantum computers. NTRU was developed in 1996 as a visionary solution to cyber security challenges for the twenty-first century. NTRU is based on a mathematical problem called the “Approximate close lattice vector problem” and comprises three algorithms: NTRUEncrypt, NTRUSign, and PASSSign. It has been reviewed and published in scholarly journals and presented at Crypto, Eurocrypt, and RSA, and has been adopted in IEEE and X9 standards Because it is based on different math from RSA and ECC, the NTRU algorithm has different cryptographic properties. At comparable cryptographic strength, NTRU performs costly private key operations much faster than RSA or ECC. In addition, NTRU's comparative performance increases with the level of security required. As key sizes increase by a factor of n, RSA's operations/second decrease by about n3 whereas NTRU's decrease at n2. """

4 4

Re: bitcoin as a global medium of exchange (was Re: Interesting take on Sanjuro's Assassination Market)
by Bill Stewart 03 Dec '13

03 Dec '13

At 05:43 PM 11/25/2013, David Vorick wrote: >Bitcoin has a lot of problems. >Andy, the problem isn't the denomination, the problem is that >Satioshi has 5% of all the currency, and the Winklevoss twins have >another 0.5%. If bitcoin becomes worth 100 trillion dollars, they've >got a solid 500 billion for being nobody and doing nothing. That's a >problem to me. Satoshi gave us the technology and got people to start using it. If he gets fabulously wealthy by owning 5% of it, I'm not jealous (well, ok, a bit jealous, but I'm not going to contend that he shouldn't have it just because of jealously.) The Winklevossen are just speculators; I don't particularly like using a currency whose value is mostly from speculation, but experimentation is a critical part of rolling out something like a new type of currency, so whatever. At least they pumped some cash into the system early on. And that guy in Norway who was an early experimenter, then kind of forgot about his bitcoins until he suddenly noticed they were worth $800K? Cool, good for him! It wouldn't be surprising if the first people to do GPU-based mining also got a large pile of bitcoins compared to the CPU-based miners. >I'm working on one right now. It's not built but the idea is to use >proof-of-contribution instead of proof-of-work, where contribution >is disk storage contributed to a distributed network. I think "proof of useful contribution" is a much better thing than "proof of wasted electricity"; good luck getting it off the ground. I'd recommend reading all of Zooko's Tahoe-LAFS work for getting some ideas about privacy and reliability issues, both of which are harder than they look. The other catch is that storage costs do keep decreasing, and storage in a cloud is always a lot slower than local storage, so you'll have to think hard about business models. One of the cool things Bitcoin did was created a way to have the proof-of-work turn into currency without needing a banker in the middle; that means that users and miners don't have to worry (much) about the creator absconding with the value or being shut down, and there's built-in protection against hyperinflation, unlike some of the dotcom silly currencies like Beenz and Flooz that appeared and vanished along with the dogfood-on-line dotcoms. It's been interesting to watch Bitcoin's value surviving after the loss of the Silk Road site (which got around the "Nothing To Buy With It" hurdle that helped kill the original Chaumian Digicash.)

11 20