4,662 reputation
1722
bio website
location
age
visits member for 2 years, 2 months
seen 10 mins ago

1d
accepted Stateless hash based public key cryptography?
1d
comment Stateless hash based public key cryptography?
Indeed, thanks. Using a seeded deterministic PRF for the private keys will make it possible to recreate everything. I think it requires careful balancing of the parameters to get acceptable performance, though. Using a ten level fractal of hash trees with $2^8$ leaf nodes seems feasible.
1d
comment Stateless hash based public key cryptography?
Could you please expand a bit on the details? Clearly, with this approach you would still have to save all sub-trees in your fractal, because you can't rule out the possibility you might have to revisit them later. (If you could rule out that possibility, you would only need the top level tree, but then you would still have to save all nodes of that tree.)
1d
asked Stateless hash based public key cryptography?
Apr
16
comment SSL-like protocol with public-key hard-coded in the client
The trivial answer is to use a CA and hard code the public key of the CA in the client. I presume you thought of that already, so what is wrong with that solution?
Apr
15
comment Could program verification techniques prevent bugs of the genre of Heartbleed from occurring?
@Gilles: The specification will always be incomplete, so it is not false.
Apr
15
comment Could program verification techniques prevent bugs of the genre of Heartbleed from occurring?
@Gilles: No, I assert that it is possible to write an incorrect program that passes verification, unless the verification is based on the exact specification, in which case you are effectively just implementing it twice and comparing the two implementations.
Apr
15
comment Could program verification techniques prevent bugs of the genre of Heartbleed from occurring?
No, the gist of my comment is that it is perfectly possible to write code that a human will recognize as immensely complex, but that will still pass all automatic audits. If you must be allowed to write arbitrarily sized data to an output socket somehow, it will always be possible for you to output the wrong things in the right way.
Apr
15
comment Could program verification techniques prevent bugs of the genre of Heartbleed from occurring?
No, you can't prevent such errors with automatic verification alone. Suppose you write a C# program and decide to use a single byte[] variable for everything (in order to mimic how the stack is used in compiled C). It would be perfectly safe code (from a formal POV), but obviously ridiculously complex and impossible to verify.
Apr
3
comment TLS Key Block calculation - What is a PRF?
Nit-pick: "TLS's PRF" should actually be "TLS's TLS PRF". The construct you describe is called "TLS PRF" and is recommended, but not strictly mandatory for new cipher suites.
Mar
31
comment TLS/SSL's usage of Non-Ephemeral DH vs DHE
A diffie-hellman public key will, when encoded for a X.509 certificate, be coupled with it's domain parameters, which includes the prime modulus $p$, generator $g$, group order $q$ and (optionally) co factor $j = (p-1)/q$. An EcPublicKey is otoh commonly coupled with an object identifier signifying which standard group the key belongs to, such as P-256, P-521 etc.
Mar
31
answered TLS/SSL's usage of Non-Ephemeral DH vs DHE
Mar
29
comment In SSL/TLS, what part of a data packet is Encrypted and Authenticated?
AEAD datatracker.ietf.org/doc/rfc5246/?include_text=1 section 6.2.3.3. Your IV explanation seems adequate enough, but it depends on the context of course.
Mar
29
comment In SSL/TLS, what part of a data packet is Encrypted and Authenticated?
For TLS 1.0, this is correct. In TLS 1.1 (and later) you will also get an explicit IV between line 01 and 02 if a CBC mode cipher is negotiated. In TLS 1.2 an AEAD cipher might be negotiated, which means line 04 will depend on the cipher.
Mar
29
comment What might be assumed about a PRF if the key has been chosen?
@D.W. TLS 1.2 specifies a generic PRF based on HMAC with a configurable hash function. This composition is called TLS PRF. It is recommended with a "SHOULD" for new cipher suites, but might, technically, be replaced in additional cipher suites defined in other RFCs.
Mar
28
comment What might be assumed about a PRF if the key has been chosen?
FTR, I am personally not sure including the handshake hash in the master_secret is the right way to go, in order to prevent the secure-resumption family of attacks, in particular if the adversary might participate in the design of the cipher suites. I might however be over cautious and would appreciate some input.
Mar
28
revised What might be assumed about a PRF if the key has been chosen?
added 1451 characters in body
Mar
28
comment What might be assumed about a PRF if the key has been chosen?
@RickyDemer: So the answer is "no" and "no"?
Mar
28
revised What might be assumed about a PRF if the key has been chosen?
added 9 characters in body
Mar
28
revised What might be assumed about a PRF if the key has been chosen?
deleted 1 characters in body