Viewing profile — sdevlin
sdevlin
HN member- Joined
- Mon, Jul 06, 2009, 5:06 PM UTC
- HN karma
- 1,326
- Public activity
- 248 items
- HN profile
- View on Hacker News ↗
About sdevlin
No profile information was provided.
Recent public activity
-
comment
Comment #20872683
> We talked English professors through the "number-theoretic" attacks on RSA in cryptopals set 6. The English professor finished set 8 as well!
-
comment
Comment #19175693
> Using "one-time-use combinations of three English words" is "fine" only if your definition of "fine" includes allowing someone with a minimal budget to find out the password in l…
-
comment
Comment #18549577
Emacs Lisp is most certainly not a Scheme.
-
comment
Comment #17914897
Probably `M-x eww`.
-
comment
Comment #16137642
They're not reading data out of the cache line. Often the contents of the cache are public anyway. What they're detecting is whether a piece of memory is in the cache or not. This …
-
comment
Comment #15361224
These are great details, but they don't really answer my question.
-
comment
Comment #15359923
You do have the choice. You don't need session tickets at all to run TLS. The cost of geographically-distinct STEKs would simply be an additional handshake if the client hops regio…
-
comment
Comment #15359441
So it would be correct to say that if any of Cloud Flare's endpoint servers is compromised, the adversary can decrypt traffic passively on a global scale?
-
comment
Comment #15359162
What is Cloud Flare's policy for managing STEKs? Are they distinct per geographic region as the article recommends?
-
comment
Comment #15073539
I guess it depends what you mean by “crack”. Given f(1), which I assume is public, you can predict all future outputs.
-
comment
Comment #14642616
It's impossible to bootstrap a secure connection without some preexisting trusted relationship. Otherwise, you'd always be vulnerable to middle-person attacks. Browsers solve this …
-
comment
Comment #14528369
It's true that the space of valid RSA keys is sparse relative to size, but this isn't why we need big keys. As a counterexample, classic DH keys are also big (or they can be), even…
-
comment
Comment #14528065
> More specifically, because of the RSA dependency on prime numbers, the RSA effective key space is very sparse (which is why going from 2048-bit RSA to 4096-bit RSA only increases…
-
comment
Comment #13148380
Just read his blog.
-
comment
Comment #13145090
ESR is a racist and a misogynist. And that document might as well be called "how to be ESR".
-
comment
Comment #12721804
You were the first to finish set 7. I assume most people don't know, so: Filippo was one of our earliest adopters of cryptopals. He is a monster. He demolished everything we put in…
-
comment
Comment #12721562
Our goal was to be accessible. If we were unsuccessful, we're happy to help fill the gaps. My email is spd@toadstyle.org.
-
comment
Comment #12721349
I'm an author. My personal mail is spd@toadstyle.org. I'm happy to help you get unblocked.
-
comment
Comment #12720838
Quick plug: set 8 is out. It's all about attacks on elliptic curves and GCM. This set is huge. There's as much content as in any two or three other sets. This set is tough. It's ea…
-
comment
Comment #12357407
You are talking about quantum attacks, whereas tptacek is talking about classical attacks.
-
comment
Comment #12354630
I don't think their bound is related to nonce-management issues. From the documentation: > The GCM security limit is 2^56 bytes because: > This is 2^52 AES blocks (each block is 16…
-
comment
Comment #12354339
Where are you getting that number?
-
comment
Comment #12329591
I think the free version of Burp Suite will handle all of this for you.
-
comment
Comment #11976499
Not specifying the group/generator is a weak link, which is what David is taking advantage of. Curve25519 is a good counterexample of a DH function that leaves nothing to the imagi…
-
comment
Comment #11884326
Yes, the posited attacker is an unprivileged spy process sharing a cache with the victim. The FLUSH+RELOAD cache-timing algorithm they use relies on a shared cache. See section 2.2…