_tnull.de

Deriving Curve22519 public keys from a secret key with enacl

2016-07-29 00:00:00 +0200

djb’s nacl is a secure, fast and easy to use crypto library. libsodium is a more packageable fork of it. The enacl project provides Erlang bindings for the basic API functions of the latter one, however, it does not cover libsodium’s crypto_scalarmult_base() function to derive the adequate public key from a Curve22519 secret key.

I may at some point work on a pull request to include this functionality in enacl. I however found a decent workaround: one could use the offered enacl:curve25519_scalarmult(Secret, BasePoint) function. While the Secret variable refers to the secret key, the BasePoint was rather unclear at first. However, after some digging in the code and online I discovered that this is a case

where the constant basepoint is 9 followed by all zeros:

const unsigned char basepoint[32] = {9};

This means that deriving a public key can be done with enacl this way:

#{secret := Secret} = enacl:box_keypair().
Filler = binary:copy(<<0:8>>, 31).
BasePoint = <<9:8, Filler/binary>>.
Public = enacl:curve25519_scalarmult(Secret, BasePoint).

Mocking IPv6 Addresses With Erlang

2016-07-14 00:00:00 +0200

I started programming Erlang some time ago. It is a great language and to dive into functional programming is somewhat mindbending. I will from time post some code snippets here in order to remember them myself and as help for others.

In this case I’m building an Erlang module that will handle tuples { Address, Port } of ip addresses and ports of remote peers. While writing unit tests for it, I realized I wanted to mock some random generated addresses. Here is the code:

random_peer() ->
    AllowedChars = [$1,$2,$3,$4,$5,$6,$7,$8,$9,$a,$b,$c,$d,$e,$f],
    Random_char = fun() -> 
      lists:nth(rand:uniform(length(AllowedChars)), AllowedChars) end,
    Random_block = fun() -> 
      lists:map(fun(_) -> Random_char() end, lists:seq(1,4)) end,
    List = lists:join($:, lists:map(fun(_) -> 
      Random_block() end, lists:seq(1,8))),
    AddressString = lists:flatten(List),
    Address = inet:parse_ipv6_address(AddressString),
    Port = rand:uniform(65535),
    {Address, Port}.

The function does not exclude reserved address spaces and so on, it does however create a string which is accepted by inet:parse_ipv6_address/1. This should be enough to use the mocked-up addresses for testing with EUnit.

Forward Secrecy in BitTorrent Bleep

2014-12-12 11:05:28 +0100

Over at the BitTorrent Engineering Blog they posted an article about how authentication works in Bleep. They explain Bleep supports Forward Secrecy, so no old messages can be decrypted by an attacker, even if the private key gets stolen. This is a nice thing to have, but given they recently announced that Bleep will also support offline messaging, it will be interesting to see how they handle this together.

Forward Secrecy relies on temporarily used keys which get discarded after use or regularly. The key negotiation can only happen while both parties are online, so keeping Forward Secrecy while introducing offline messages is normally a challenge. Over at OpenWhisperSystems they handled this problem for the TextSecure app by generating 100 key exchange messages and storing them on the centralized server:

At registration time, the TextSecure client preemptively generates 100 signed key exchange messages and sends them to the server. We call these “prekeys.” A client that wishes to send a secure message to a user for the first time can now:

Connect to the server and request the destination’s next “prekey.”

Generate its own key exchange message half.

Calculate a shared secret with the prekey it received and its own key exchange half.

Use the shared secret to encrypt the message.

Package up the prekey id, the locally generated key exchange message, and the ciphertext.

Send it all in one bundle to the destination client.

The user experience for the sender is ideal: they type a message, hit send, and an encrypted message is immediately sent.

I think this is a solid workaround.

'Project Maelstrom' aims to make the Web distributed

2014-12-11 13:03:14 +0100

BitTorrent wants to make the Web distributed. They announced they’ve been working on a Browser (and included server it seems) which is based on a distributed Peer-to-Peer architecture:

Project Maelstrom begins to answer that question with our first public release of a web browser that can power a new way for web content to be published, accessed and consumed. Truly an Internet powered by people, one that lowers barriers and denies gatekeepers their grip on our future.

This is a great idea! Let’s hope they make this an open platform to build on, and open source so everyone can check what’s going on in the internals!

They are looking for participants in ‘Project Maelstrom’, so if you are interested to have a look at it as an alpha tester, developer, researcher, agency, publisher or artist, sign up for their mailing list.

Collision on 32bit PGP key ids

2014-12-03 10:31:45 +0100

Research shows that it takes only 4 seconds to create PGP keys with colliding 32bit key ids. This is presented on evil32.com:

Stop using 32bit key ids

It takes 4 seconds to generate a colliding 32bit key id on a GPU (using scallion). Key servers do little verification of uploaded keys and allow keys with colliding 32bit ids. Further, GPG uses 32bit key ids throughout its interface and does not warn you when an operation might apply to multiple keys.

With this it is relatively easy to fool a target into importing the wrong PGP key and therefore gain his/her trust.

Solution: using the Web of Trust circumvents this. Also, checking fingerprints ensures you got the right key. But still, this seems like one more nail in the coffin of PGP: As its usability and distribution is getting worse and worse, everyone waits for a new solution to replace PGP once and for all. To quote Matt Green:

It’s time for PGP to die.

New Free CA 'Let's Encrypt'

2014-11-20 12:10:52 +0100

There is a new Free CA: Let’s Encrypt, a collaboration project of Mozilla, Akamai, Cisco, EFF and IdenTrust (so far). On their blog they published their key principles:

Free: Anyone who owns a domain can get a certificate validated for that domain at zero cost.

Automatic: The entire enrollment process for certificates occurs painlessly during the server’s native installation or configuration process, while renewal occurs automatically in the background.

Secure: Let’s Encrypt will serve as a platform for implementing modern security techniques and best practices.

Transparent: All records of certificate issuance and revocation will be available to anyone who wishes to inspect them.

Open: The automated issuance and renewal protocol will be an open standard and as much of the software as possible will be open source.

Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the entire community, beyond the control of any one organization.

This will be great, if it just works as they advertise!!

Recent attacks on Tor anonymity

2014-11-20 11:44:09 +0100

After Operation Onymous probably succeeded in deanonymizing Tor users, namely the guy behind SilkRoad 2.0, the Tor project is puzzled how they did it: > ### How did they locate the hidden services? > > So we are left asking “How did they locate the hidden services?”. We don’t know. In liberal democracies, we should expect that when the time comes to prosecute some of the seventeen people who have been arrested, the police would have to explain to the judge how the suspects came to be suspects, and that as a side benefit of the operation of justice, Tor could learn if there are security flaws in hidden services or other critical internet-facing services. We know through recent leaks that the US DEA and others have constructed a system of organized and sanctioned perjury which they refer to as “parallel construction.”

Naked Security had an article about it, too.

There was an other claim about Tor security in the last days: Proffessor Sambuddho Chakravarty co-authored a paper called “On the Effectiveness of Traffic Analysis Against Anonymity Networks Using Flow Records”, in which the authors claim to deanonymize Tor users at a high rate using data from Cisco’s NetFlow traffic analysis functionality. However, Roger Dingledine of the Tor project responded at the Tor Blog, concluding: > In summary, it’s great to see more research on traffic confirmation attacks, but a) traffic confirmation attacks are not a new area so don’t freak out without actually reading the papers, and b) this particular one, while kind of neat, doesn’t supercede all the previous papers.

And in the comments Chakravarty clarified: >I am here to myself clarify all misconceptions. Firslty, they have blow it a bit out of proportion by saying that “81% of Tor traffic”, which is not true. It was only 81.4% of our experiments, and we have spoken about this upfront in our paper. Secondly, its only a case of experimental validation and the challenges involved in it that is the highlight of the paper. In my thesis I have also tried to address how to solve this particular attack, which might work for other attacks as well…

So it seems the results of the paper aren’t news. Still, traffic analysis is something to keep in mind.

'Wirelurker' explained

2014-11-07 16:48:42 +0100

Jonathan Zdziarski takes a look at the recent ‘WireLurker’ malware for OS X / iOS:

WireLurker is a trojan that has reportedly been circulated in a number of Chinese pirated software (warez) distributions. It targets 64-bit Mac OS X machines, as there doesn’t appear to be a 32-bit slice. When the user installs or runs the pirated software, WireLurker waits until it has root, and then gets installed into the operating system as a system daemon. The daemon uses libimobiledevice. It sits and waits for an iOS device to be connected to the desktop, and then abuses the trusted pairing relationship your desktop has with it to read its serial number, phone number, iTunes store identifier, and other identifying information, which it then sends to a remote server. It also attempts to install malicious copies of otherwise benign looking apps onto the device itself. If the device is jailbroken and has afc2 enabled, a much more malicious piece of software gets installed onto the device, which reads and extracts identifying information from your iMessage history, address book, and other files on the device.

'notogotofail' network security testing tool released

2014-11-05 18:11:16 +0100

Google released nogotofail, a network security tool:

Nogotofail is a network security testing tool designed to help developers and security researchers spot and fix weak TLS/SSL connections and sensitive cleartext traffic on devices and applications in a flexible, scalable, powerful way. It includes testing for common SSL certificate verification issues, HTTPS and TLS/SSL library bugs, SSL and STARTTLS stripping issues, cleartext issues, and more.

Secure Messaging Scorecard

2014-11-04 22:34:52 +0100

The Electronic Frontier Foundation created a new project: the Secure Messaging Scorecard - a really nice security- and privacy-focused overview of messaging apps:

In the face of widespread Internet surveillance, we need a secure and practical means of talking to each other from our phones and computers. Many companies offer “secure messaging” products—but are these systems actually secure? We decided to find out, in the first phase of a new EFF Campaign for Secure & Usable Crypto.

Have a look!