sdevlin

15 ms·

61.
by sdevlin 11y ago
> Also in the crypto/cipher package, there is now support for nonce lengths other than 96 bytes in AES's Galois/Counter mode (GCM), which some protocols require. This should be "96 bits".
62.
by sdevlin 11y ago
Interesting notes, I didn't realize the competition was so old. Thanks!
63.
by sdevlin 11y ago
Building around S-box lookups also seems like a weird choice in 2015. I looked and couldn't find any considerations for cache-timing side channels. There really wasn't much advice for implementers at all. I'm not sure this is
64.
by sdevlin 11y ago
Ed25519 and Curve25519 are not encumbered by any patents, see http://cr.yp.to/ecdh/patents.html and http://ed25519.cr.yp.to/software.html . You should prefer state-of-the-art elliptic curve systems to R
65.
by sdevlin 11y ago
None of the mistakes people make in crypto are intentional. We need better interfaces to help them not make those mistakes.
66.
by sdevlin 11y ago
I was mainly commenting on the design. I actually haven't looked at the implementation. Also, I would put AES side channels somewhat low on the list of practical vulnerabilities.
67.
by sdevlin 11y ago
There's no a priori need for password-derived key material in a library like this. To require it unilaterally is to introduce a security risk, since people have proven to be poor sources of entropy. I don't really understand the s
68.
by sdevlin 11y ago
I wouldn't say this is bad or anything, but it is focusing on the wrong problem. Block ciphers like AES are the very strongest piece of the puzzle. This is kind of like putting three huge locks on your front door. It doesn't hurt,
69.
Android Wallet Security Update(blog.blockchain.com)
2 points by sdevlin 11y ago|0 comments
70.
by sdevlin 11y ago
Given a message M and a secret key K, we have: MAC(K, M) -> T To validate a pair (M, T), we verify: T = MAC(K, M) Ideally, the execution time in this verification is independent of T. But many languages use string-compar
71.
by sdevlin 11y ago
This is a forgery attack, not a key-recovery attack.
72.
Big Mouth Strikes Again(simonpegg.net)
18 points by sdevlin 11y ago|0 comments
73.
by sdevlin 11y ago
You're breaking the tables.
74.
by sdevlin 11y ago
The two collision examples I used both rely on the key expansion step in HMAC, which I glossed over in my explanation. If you go look up the HMAC spec, it should be pretty clear why these work.
75.
by sdevlin 11y ago
SNARK REDACTED
76.
by sdevlin 11y ago
> And yet. This is novel No. EDIT: I've been told to elaborate. This is just direct fallout from the way Merkle-Damgard hash functions work. MD hash functions look like this: function MD(C, h, M): M <- pad(M)
77.
by sdevlin 11y ago
Here's another attack scenario to think about. Consider the original protocol: server sends a t-bit nonce N, client signs it. Suppose that Eve can passively observe Alice's authentications to Bob's server, but she can't
78.
by sdevlin 11y ago
To be clear, Alice is intentionally authenticating to Eve in this scenario. So a secure channel does not impede the attack. For example, suppose Eve is Facebook and Bob is Google. Alice logs into Facebook, but what she doesn't know is
79.
by sdevlin 11y ago
Alice is an end user. Eve and Bob each host legitimate servers. Alice authenticates to Eve, and Eve impersonates Alice to Bob like so: A E B -hello-> -hello-> <-nonce- <-
80.
by sdevlin 11y ago
> signed data include session id that is derived from result of first DH key exchange and thus unpredictable to either side of connection The unpredictability of DH output depends on the group parameters and public key validation perform
81.
by sdevlin 11y ago
The scheme you outline still allows trivial impersonation attacks.
82.
by sdevlin 11y ago
CBC-MAC and CMAC are similar, but not the same.
83.
by sdevlin 11y ago
This is a library of supplemental crypto algorithms. You won't see things like AES, SHA-2, or the NIST curves in here. Those things are part of the standard library in Go.
84.
by sdevlin 11y ago
I can't speak for Cloudflare, but I would guess that they want these changes to be merged upstream. If that happens, the benefit is that consumers of the stdlib crypto API will get increased security and performance for free in a futur
85.
by sdevlin 11y ago
Neat, I didn't even notice this. Vlad Krasnov is also a co-author of this paper on state-of-the-art P256 implementation: https://eprint.iacr.org/2013/816.pdf .
86.
by sdevlin 11y ago
A couple points on this. First, as some have noted, serious crypto primitive implementations are written in assembly. This is both to achieve state-of-the-art performance as well as data-independent execution times. The latter is important
87.
by sdevlin 11y ago
When people describe crypto code as "constant-time", they typically just mean its execution time is data-independent.
88.
by sdevlin 11y ago
> something serious What do you recommend? Autotools, bespoke shell scripts, or something else entirely?
89.
by sdevlin 11y ago
I think it's fine. For the limited threat model FDE is equipped to handle, XTS does the job. I'm not sure what the best answer is to your second question. I wouldn't use TC for that. I would typically use PGP, but I don'
90.
by sdevlin 11y ago
The context of the thread is a report with my name on it. My professional opinion is my own. The developer's opinion is also relevant (to people who don't buy into nonsensical conspiracy theories), so I mentioned it.

More ›