Hey! I'm David, the author of the Real-World Cryptography book. I was previously a crypto architect at O(1) Labs (working on the Mina cryptocurrency), before that I was the security lead for Diem (formerly Libra) at Novi (Facebook), and a security consultant for the Cryptography Services of NCC Group. This is my blog about cryptography and security and other related topics that I find interesting.
If you are interested in crypto, I'll be talking about backdoors and Diffie-Hellman. This will be the occasion of explaining what my latest whitepaper that was released today is about.
John Downey will also be talking about "Cryptography Pitfalls".
By the way, if you're interested in such events in Chicago. OWASP was today (and we even learned how to brew beer there). There are also other security related events that you can get update on from this twitter.
Sorry i am using DTLS 1.2 instead TLS 1.2. Kindly explain the structure of finished message, like how many bytes for "nonce", how many bytes are encrypted data and how many bytes for authentication tag.
I'm writing this because I want to clear things up: you can ask me pretty much anything and I'll do my best to answer here. So please ask away if you have a question in crypto! There is also a contact form for that.
Differences between DTLS and TLS
TLS is an application layer protocol. Some people say that it's a transport layer protocol. This is false. It runs in whatever program you are using on top of TCP/UDP. Although it is used to transport the real content of the application: it can be seen as an intermediate transport layer running in the application layer.
The TLS we know, the one that runs in our browser, typically runs on top of TCP. But in some situations, the developer might want to use UDP to exchange packets. Since UDP forgives packet loss (think multiplayer video games or audio/video conferences), it is important that TLS is setup accordingly to forgive those packet loss as well. For this, we use a similar but different specification than TLS: DTLS.
DTLS is what you use if you need TLS on top of UDP.
errors (duplicates, loss, out of order) are tolerated
no stream cipher can be used (no state can be used if errors are tolerated)
protections against DoS attacks (apparently DTLS has some problems with DoS attacks)
...
Finished messages
The simplest TLS handshake goes like this:
the client sends its ClientHello packet
the server replies with his ServerHello packet
the client sends (his part of) the shared secret in a ClientKeyExchange packet
Now I omitted a bunch of packets that are usually part of the handshake as well. For example:
the server usually sends his certificate after the ServerHello message.
the server might also take part in the creation of the shared secret in some modes (including ephemeral modes)
But this is not what is interesting to us here.
After enough messages have been sent to compute the shared secret, a ChangeCipherSpec message is sent by both the client and the server to announce the beginning of traffic encryption. Followed directly by an encrypted Finished message authenticating all the previous handshake messages.
In my knowledge, the Finished message is the only encrypted message of a handshake. It is also the moment where the handshake is "authenticated" and where Man-In-The-Middle attacks usually stop.
Now what is in that Finished message?
Exactly the same things as in TLS. The TLS 1.2 RFC shines a bit more light on the subject:
struct {
opaque verify_data[verify_data_length];
} Finished;
verify_data = PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1];
finished_label =
For Finished messages sent by the client, the string "client finished". For Finished messages sent by the server, the string "server finished".
Don't forget that this Finished structure is then encrypted before being sent in a record. The Hash and the PRF we already defined in previousposts, the handshake_messages value is what interest us: it is the concatenation of all the binary data received and sent during the handshake, in order, and not including this Finished one.
Now DTLS has the particularity that some messages are re-sent, out of order, etc... so duplicates must be ignored, real order must be preserved.
How do I know that?
Besides reading the RFC, you might often want to know what's happening for real. To be a bit more informative, let me tell you how I quickly get that kind of information when I'm curious:
I setup a server key + certificate: openssl req -x509 -new -nodes -keyout key.pem -out server.pem.
I start the server: openssl s_server -dtls1 -key key.pem -port 4433 -msg.
I connect to it with a client: openssl s_client -dtls1 -connect localhost:4433 -msg.
The -msg argument will print out the exact content of the messages sent. In the case of the Finished message, it will show the unencrypted hexadecimal data sent. If you want to see the real encrypted data that is sent, you can use the -debug option.
You might also want to have a bit more information about every records. A good way to do this is to record the traffic with tcpdump: sudo tcpdump udp -i lo0 -s 65535 -w handshake.pcap and to open the .pcap file in Wireshark and enter udp && dtls in the filter area.
It's 2 days crash course on our knowledge as crypto consultants. There will be a lot of general culture, protocols, side-channels, random numbers, ... as well as deep segments and exercises on common crypto attacks.
If you're not interested, you can still hit me up for drinks around Black Hat or Defcon, I'll be in Vegas. Otherwise I'll be in Santa Barbara a few week after for CRYPTO and CHES. If you're in need of crypto conference, there is also SAC happening in Canada between Defcon and CRYPTO (I won't be there).
Just realized that each ePrint paper has a BibTeX snippet to reference the paper in your own work. If you don't know what I'm talking about, I'm talking about that:
Go on any paper's page and click on the BibTeX Citation link. The snippet needs to be included in a .bib file and referenced from the your main .tex
@misc{cryptoeprint:2015:767,
author = {Daniel J. Bernstein and Tanja Lange and Ruben Niederhagen},
title = {Dual EC: A Standardized Back Door},
howpublished = {Cryptology ePrint Archive, Report 2015/767},
year = {2015},
note = {\url{http://eprint.iacr.org/}},
}
I believe Craig Steven Wright is the person who invented Bitcoin.
First. How weird is it that instead of just signing something with Satoshi's public key and releasing it on the internet, Mr. Wright decides to demo a signature verification on closed door to TV channels, magazines and some bitcoin dev on a trip to London? From reddit, Gavin wrote:
Craig signed a message that I chose ("Gavin's favorite number is eleven. CSW" if I recall correctly) using the private key from block number 1.
That signature was copied on to a clean usb stick I brought with me to London, and then validated on a brand-new laptop with a freshly downloaded copy of electrum.
I was not allowed to keep the message or laptop (fear it would leak before Official Announcement).
That last sentence... is the rule number one in a magic trick or scam.
Now people are pointing out from the blogpost this intentional mistake in Wright's script to verify a signature:
Looks like the signature is also taken from an old transaction, so Wright is re-using a signature to prove he verified "something". Except he swapped the something.
Another way he might have done it, on his website he also has a oneliner:
myvar = "foo"
myvаr = "bar" # This is a *different* variable.
print("first one:", myvar)
print("second one:", myvаr)
The amount of sleigh of hands that could have been done here is actually really interesting. We have cryptographic signatures so that we don't need to believe in human lies, but if the human is in between you and the verification of the signature, then good luck!
Also that python script makes me think of using this as a proof of concept backdoor.
WhatsApp just announced their integration of the Signal protocol (formerly known as the Axolotl protocol). An interesting aspect of it is the use of a TLS-like protocol called Noise Pipes. A protocol based on the Noise protocol framework, a one-man work led by Trevor Perrin with only a few implementations and a moderately long specificiations available here. I thought it would be interesting to understand how protocols are made from this framework, and to condense it in a 25 minutes video. Here it is.
The paper is available on eprint. titled A Systematic Analysis of the Juniper Dual EC Incident, it contains some background on Dual EC, IKE and a timeline of event that should read like a nice story. This is the paper you're going to read next week! So go print it now =)
CVE-2016-3959 also called the golang infinite loop just triggered a new version of the language Go. The cherry on the cake is that it was discovered by me!
A: Anything that uses the big.Exp function concurrently where the modulo parameter can be controlled by an attacker. For crypto this means mostly DSA and RSA which are used for example in TLS and SSH, as well as many other cryptographic applications, like recently in the Let's Encrypt client (hope they patched). ECDSA also use the big.Exp function but this elliptic curve version of DSA usually does not use custom curves so the attacker has usually no known way to make someone compute calculations over his curves parameters if they are non-standard.
A: Programming languages have int types that can usually hold integers up to 64bits (For example, in C this type is called uint64_t). But crypto needs numbers that are much bigger than that, up to 4000 bits sometimes. So big number libraries are the libraries used to play with numbers of such sizes without getting a headache =)
Q: What was the problem with big.Exp?
A: It was a pretty simple one, the lack of a zero check for the modulus made the calculation turn into an infinite loop. Interestingly the developers of Go did not patch the vulnerability by adding the zero check inside of big.Exp but did it inside of the implementations of DSA, RSA and ECDSA. This means that other cryptographic functions or non-cryptographic functions that employ this big.Exp function, concurrently, with the third parameter controlled by the user, might still be subject to DoS attacks.
If you have any other questions feel free to ask! The comment section is here for that ;)
