- cypherpunks - lists.cpunks.org

Snowden and Compilers
by Rich Jones 16 Feb '14

16 Feb '14

In all of the Snowden docs that have been released so far, has anybody seen any mention of any NSA programs designed to subvert compilers? Compilers seems like an extremely prime target for manipulation, but as far as I am aware there hasn't been anything mentioned about this yet. Has anybody here heard anything that I haven't? R

17 21

Re: [Cryptography] Snowden Meets MacAskill, Poitras and Greenwald
by John Young 14 Feb '14

14 Feb '14

Page added. Thanks. At 07:38 PM 2/13/2014, Jerry Leichter wrote: >This one also seems to be missing a page - between "Snowden believed >that the US" and "struggled to make sense of the PRISM slides." > > -- Jerry > >On Feb 9, 2014, at 10:32 AM, John Young <jya(a)pipeline.com> wrote: > > > http://cryptome.org/2014/02/snowden-meet.pdf > > > > Snowden to MacAskill, vehemently: "GCHQ is worse than NSA. It's > even more intrusive."

1 0

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

Cryptocurrencies for Good: Revolutionizing Microdonations
by Odinn Cyberguerrilla 13 Feb '14

13 Feb '14

We've launched 'Cryptocurrencies for Good: Revolutionizing Microdonations' as an indiegogo project. This currently involves myself, Filipe Farinha, and technical support from Cryptostorm. Also, there's wine. Here's our page, launched today: http://igg.me/at/microdonations-using-cryptocurrencies As the world changes, so must we! :-)

2 1

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

FB's Conceal secure-storage API
by Griffin Boyce 10 Feb '14

10 Feb '14

Bullshit or not? It has some interesting elements to it, and would be a step in the right direction for more-secure app content storage. Though at its base, it has some conceptual flaws. If you root the device, you can get the private key. By design, there's no way to put the key on external media (there's only one external microSD slot, and that contains your encrypted files). Files could be cached once decrypted. And of course it doesn't prevent a Finfisher-style screenshot-taking backdoor from just viewing what's displayed on the screen. That's not going into the quality of encryption (which remains to be seen). Conceal uses a stripped-down version of OpenSSL for its encryption algorithms. Still, could be fun. =) ~Griffin https://code.facebook.com/posts/1419122541659395/introducing-conceal-effici… "Caching and storage are tricky problems for mobile developers because they directly impact performance and data usage on a mobile device. Caching helps developers speed up their apps and reduce network costs for the device owner by storing information directly on the phone for later access. However, internal storage capacity on Android phones is often limited, especially with lower to mid range phone models. A common solution for Android is to store some data on an expandable SD card to mitigate the storage cost. What many people don't realize is that Android's privacy model treats the SD card storage as a publicly accessible directory. This allows data to be read by any app (with the right permissions). Thus, external storage is normally not a good place to store private information. We saw an opportunity to do things better and decided to encrypt the private data that we stored on the SD card so that it would not be accessible to other apps. To do this efficiently, we built Conceal, a set of Java APIs to perform cryptography on Android and make storage more secure and lightweight. We created Conceal to be small and faster than existing Java crypto libraries on Android while using memory responsibly."

3 2

Snowden Meets MacAskill, Poitras and Greenwald
by John Young 09 Feb '14

09 Feb '14

http://cryptome.org/2014/02/snowden-meet.pdf Snowden to MacAskill, vehemently: "GCHQ is worse than NSA. It's even more intrusive."

1 0

Re: [cryptography] Snowden Drop to Poitras and Greenwald Described
by John Young 09 Feb '14

09 Feb '14

Correct, page 13 was missing. Thanks. Now added. Page begins with "his head. But Snowden told her:" Ends with "Even with Assange's" At 01:47 AM 2/9/2014, you wrote: >On 9/02/14 02:28 AM, John Young wrote: > > http://cryptome.org/2014/02/snowden-drop.pdf (7.6MB) > > >page 12: After all, coming forward would bring the law down on > >... > >Next page: skills, Snowden realised it would be difficult to punch > >Seems like a missing page? > >iang

1 0

Re: Proof of Stake...
by Sean Lynch 09 Feb '14

09 Feb '14

Sorry, meant to include the list before. Switching to inline reply since I want to reply to separate points separately. On Fri, Feb 7, 2014 at 12:40 PM, Lodewijk andré de la porte <l(a)odewijk.nl>wrote: > 2014-02-07 Sean Lynch <seanl(a)literati.org>: > > Substitute "CPU power" for "wealth," and your claim about trust equally >> applies to the current proof-of-work function. I don't accept your premise >> that giving more power to wealthy people is somehow worse than giving more >> power to people with lots of CPU power (i.e. wealthy people). > > > Ah, yes. But now you're confusing some things. > > I can calculate that a certain transaction is no longer worth falsifying. > Let's say that there's 10,000 USD (10kusd) required to fake a single block. > > Now my transaction is buried 5 blocks. Setting apart a block just for the > sake of luck-prevention I can say that if my transaction is <40kUSD it is > now entirely safe. It is not worth it to revert it. > > Unless someone wants to mess with me (specifically me) it will not be > done. If I suspect someone wants to mess with me I only have to estimate > how much he can spend messing with me. > > Block reward kind of throws a wrench into the story. It drastically > reduces the actual cost of mining a block. Still I can say with math that > it isn't worth it after a while. > > With proof of stake I cannot do such math. I'm subjected not to the will > of the rich to mess with me. Not the will of the rich to waste money on me. > And the cost of faking a chain does not grow with it's length, unless it's > a proof-of-work-and-stake. In which case I'm really wondering why you're > taking two risks. > Either way, this is not equivalent to introducing trust into the system where it did not exist before. My claim about proof-of-stake not being trust any more than proof-of-work is stands. I was proposing using coin days destroyed as part of the "difficulty" computation, which would mean they actually DO have value, since you cannot use the same coin days more than once, and they would reduce the number of CPU cycles you need to burn in order to produce a block. The idea is to reduce the cost of mining in terms of pure CPU cycles by giving value to something that currently has no value: coin days. So you actually CAN do such math still. This is not a pure proof-of-stake system, though. I am as skeptical of pure proof of stake as you are. > I'm more strongly in favor of using citizen's ID's as provided by > governments for the purpose of voting on blocks than in proof of stake. > Not knowing you, this doesn't tell me much, since the same could be said of the most statist friend I actually tolerate, the one who thinks Bitcoin should die in a fire. I'm guessing that this means "not in favor of it at all." There are a couple of problems people are trying to solve with proof-of-stake. The first is that the value of mining will eventually go down, meaning people will be willing to devote less computing power to it, reducing the cost of an attack. The second is that, even if it didn't go down, we don't necessarily want a huge fraction of the world's computing power devoted to mining. The goal is to take some limited resource that doesn't depend on a trusted third party and that is difficult to corner and use that to distribute voting authority. In addition, we'd like the people doing the voting to have an economic incentive to vote correctly. Bitcoin does that by paying them to vote and revoking the payment if their block doesn't end up in the main chain. Proof-of-stake does it by hoping that the voters care about the integrity of the system, similar to only allowing landowners to vote, only (hopefully) without the ability to prevent others from becoming stakeholders, which I think is your main worry about it. Incidentally, the coin days are from ALL of the transactions in the block, not just your own. I'm not sure if I was clear about that before. You could maybe override a transaction that had fewer coin days, but you'd have to burn a similar amount (though less) of CPU time in addition. Speaking of which, is there any reason peers couldn't watch for forks and incorporate any still-valid transactions into new blocks and permanently blacklist any outputs that get double-spent? You could create a special "blacklist" transaction that just incorporates the two separate spends into the main chain, so that everyone could validate that the account holder attempted to double spend.

3 2

Snowden Drop to Poitras and Greenwald Described
by John Young 08 Feb '14

08 Feb '14

http://cryptome.org/2014/02/snowden-drop.pdf (7.6MB)

1 0