- cypherpunks - lists.cpunks.org

Re: Cryptocurrencies for Good
by dan＠geer.org 18 Feb '14

18 Feb '14

http://www.bbc.co.uk/news/magazine-26169411 Why every household should have its own currency --dan

2 1

Chaotic Times on the Dark Nets
by Rich Jones 17 Feb '14

17 Feb '14

Rough week for the underground! Utopia has been seized by the Dutch police, BMR forums got seized by the Iranian police (anybody want to take any guesses at that one?), and now Silk Road 2.0 has been owned/possibly scammed everybody. I guess TMP will take the crown now, but for how long? I'm honestly not optimistic about the continued operation of _any_ service if Tor hidden service operators continue to operate in the manner instructed by the Tor project. There just isn't enough redundancy, servers need to be located in multiple regions simultaneously. We shall see what the future holds. R

8 10

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