6 ms·

We wrote a blog post for that: https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html https://latacora.micro.blog/2018/04/03/cryptographic-righ

by lvh 7y ago

We wrote a blog post for that: https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html https://latacora.micro.blog/2018/04/03/cryptographic-right-a... To answer your specific comments: firstly, you don't need public key crypto. If both you and your sender can agree on a secret key, you can use secret key crypto just fine. For that, use libsodium's secretbox. If you really need public key crypto for some reason, libsodium's box is what you want. What's the "untrusted channel" here? Is this really about encryption in transit, or encryption at rest?

IggleSniggle 7y ago
Suddenly I’m more confused. How can you agree on a secret key, remotely, without some foundational source of trust? I don’t trust the default CA packages anymore, given the prevalence of untrustworthy vendors like Comodo.
- tptacek 7y ago
  He’s saying that if you can get away with generating something like a random API key and just having the client save that, that’s much safer than using public key cryptography.
  - fireflash38 7y ago
    Minor clarification: > that’s much safer than using public key cryptography. It's much harder to screw up than using PKC (thereby making it safer). It's something that is really important for UX - you want to make the easiest path the safest path.
    - tptacek 7y ago
      No. Don't go looking for reasons to use public key where the underlying design doesn't necessitate it.
- lvh 7y ago
  Yes, you need some foundational source of trust, but you were going to communicate that public key one way or another. If you don't trust that medium (let's say it's WebPKI TLS and an adversary gets a bad cert from Comodo somehow), the adversary could just lie about the public key too. A MITM adversary that's in a position to unseal and reseal libsodium secretbox messages can also do that with libsodium box. (For everyone else: just because I'm playing along with this misissuance scenario doesn't mean I don't think ~everyone should trust WebPKI.)
- deleted 7y ago
  [deleted]
- curryst 7y ago
  In a private scenario (i.e. most B2B usage), you can communicate the key through a different channel. One option would be to write it down on a piece of paper, and fly someone to the other business to deliver it. Now both sides have a copy of the key, and transmission is guarded by your trust in your employee to not skim the key. Mail is another option, depending on how secure you think that is.
  - tabletopneedle 7y ago
    It's much safer to just send the public key over whatever medium and then use an authenticated channel to verify the authenticity of said public key.
    - Natanael_L 7y ago
      How often do you have a reliable tamper resistant authenticated channel that isn't also secret?
      - tialaramex 7y ago
        I might be confident that bad guys won't realise what's going on and somehow break into my email system replacing your public key with their own in, say, six hours it takes to receive and act on the message; whereas I can't be reasonably confident that all my mail systems and all backups of mail systems will remain unbreakable for the foreseeable future or until I've deleted all trace of the symmetric key. Cryptography is often not about "uncrackable" but about confidence in security over a foreseen interval. On the 4th of June 1943 the details of Operation Neptune ("D-Day") were a priceless secret of the Allied Command, a break that allowed Berlin to know the plan could have resulted in the invasion force being expected by a heavily prepared and well-reinforced German defence. Those who made it back to England alive would have no reward for their efforts. By the 7th of June 1943 plans for Neptune were a historical curiosity of little military value.
        anonymousisme 7y ago
- munchbunny 7y ago
  Establishing a secret key and a secure channel does not require trust. It just requires a pair of keys so that you can be sure that the message gets to the other party unintercepted and unmodified. However, just because you have a channel that can't be MitM-ed doesn't mean you can actually trust whoever is on the other end. The problem of "how do you know you trust the other end" requires some foundational source of trust, whether that's trusting the transportation medium (that the person you handed the USB key to is actually who he/she claims to be), the issuer (could be yourself), and so on.
raverbashing 7y ago
Would Diffie-Hellman (still) be a good way of exchanging secrets? ECDH?
- lvh 7y ago
  Depending on context the answer is "absolutely" or "absolutely not", so that's hard to answer. I definitely wouldn't tell you to use finite-field Diffie-Hellman in any context, or any derived cryptosystems (ElGamal or IES), no.
  - rocqua 7y ago
    I might be misreading, but it seems like you advise against IES. If so, does that extend to ECIES? I ask because the actual article actually suggests ECIES.
    - lvh 7y ago
      "Finite-field" is the operative phrase in that sentence. I wouldn't tell you to use IES, as in the thing where you do g^xy mod p. I would tell you to use libsodium's box, which is a specific implementation of something sorta like ECIES, though. The confusion is that IES/ElGamal sometimes means a family of systems and sometimes someone literally means FFDH + AESCTR or something. The abstract concept is fine, but you should use a hardened implementation.
- tptacek 7y ago
  Don't freelance your own kex protocol. Don't use multiplicative group DH. Don't use the NIST p-curves to implement ECDH, which will require you also to implement point validation to avoid invalid curve attacks. You want something like Curve25519 DH, but depending on your application, you probably also want an authenticated key exchange, which a naive Curve25519 protocol isn't going to give you.
  - loup-vaillant 7y ago
    > Don't freelance your own kex protocol. Considering it took me 8 months to not even finish my own, making several serious mistakes in the process, even though I wrote my own goddamn crypto library and am standing on Noise's shoulders… I tend to agree. That said, we still have a problem: `crypto_box()` is nice, but it doesn't have any kind of forward secrecy, identity hiding, or key compromise impersonation resistance. Sure, offline protocols can't really have that (the best you can do is use signatures to avoid the key compromise impersonation issue, but then you loose some deniability). Online protocols however, can. But then what do we do? We could use Noise, (the Noise explorer now generates code in several languages), but you at least have to chose a pattern. Which one? How can you even notice that XK1 maximises client anonymity, and IX (properly used) maximises server security? Even if you know that, which are you going to use? And I'm not even talking about implementing your Noise pattern, should existing implementations not suffice (maybe you want to leverage a custom crypto library optimised for some embedded processor). Noise isn't simple. A serious drawback in my opinion. This, if I guess correctly, is what led you to recommend that horror that is TLS for client/server security. Because the burden of choosing a reasonable TLS library, of properly configuring that TLS library to only use TLS 1.3 with a limited set of ciphers (possibly just Curve25519 and ChaPoly)… still remains less error prone than picking up a Noise protocol. <PKI matters conveniently left out> That situation is deeply unsatisfactory. It's all well and good to tell people "don't make your own kex", but if you don't at the same time point them to an existing kex, they will be less likely to follow your advice. I mean, I didn't.
linsomniac 7y ago
^^^ I know this chap, he knows what he's talking about.
- jj11837 7y ago
  I smell bullshit. He can't explain how the secret key would be exchanged. "Agreeing on a key" isn't a problem any cryptographer needs to solve. You can tell this guy understands very little except how to sell something.

by lvh 7y ago

IggleSniggle 7y ago

Suddenly I’m more confused. How can you agree on a secret key, remotely, without some foundational source of trust? I don’t trust the default CA packages anymore, given the prevalence of untrustworthy vendors like Comodo.

tptacek 7y ago
He’s saying that if you can get away with generating something like a random API key and just having the client save that, that’s much safer than using public key cryptography.
- fireflash38 7y ago
  Minor clarification: > that’s much safer than using public key cryptography. It's much harder to screw up than using PKC (thereby making it safer). It's something that is really important for UX - you want to make the easiest path the safest path.
  - tptacek 7y ago
    No. Don't go looking for reasons to use public key where the underlying design doesn't necessitate it.
lvh 7y ago
Yes, you need some foundational source of trust, but you were going to communicate that public key one way or another. If you don't trust that medium (let's say it's WebPKI TLS and an adversary gets a bad cert from Comodo somehow), the adversary could just lie about the public key too. A MITM adversary that's in a position to unseal and reseal libsodium secretbox messages can also do that with libsodium box. (For everyone else: just because I'm playing along with this misissuance scenario doesn't mean I don't think ~everyone should trust WebPKI.)
deleted 7y ago
[deleted]
curryst 7y ago
In a private scenario (i.e. most B2B usage), you can communicate the key through a different channel. One option would be to write it down on a piece of paper, and fly someone to the other business to deliver it. Now both sides have a copy of the key, and transmission is guarded by your trust in your employee to not skim the key. Mail is another option, depending on how secure you think that is.
- tabletopneedle 7y ago
  It's much safer to just send the public key over whatever medium and then use an authenticated channel to verify the authenticity of said public key.
  - Natanael_L 7y ago
    How often do you have a reliable tamper resistant authenticated channel that isn't also secret?
    - tialaramex 7y ago
      I might be confident that bad guys won't realise what's going on and somehow break into my email system replacing your public key with their own in, say, six hours it takes to receive and act on the message; whereas I can't be reasonably confident that all my mail systems and all backups of mail systems will remain unbreakable for the foreseeable future or until I've deleted all trace of the symmetric key. Cryptography is often not about "uncrackable" but about confidence in security over a foreseen interval. On the 4th of June 1943 the details of Operation Neptune ("D-Day") were a priceless secret of the Allied Command, a break that allowed Berlin to know the plan could have resulted in the invasion force being expected by a heavily prepared and well-reinforced German defence. Those who made it back to England alive would have no reward for their efforts. By the 7th of June 1943 plans for Neptune were a historical curiosity of little military value.
      - anonymousisme 7y ago
munchbunny 7y ago
Establishing a secret key and a secure channel does not require trust. It just requires a pair of keys so that you can be sure that the message gets to the other party unintercepted and unmodified. However, just because you have a channel that can't be MitM-ed doesn't mean you can actually trust whoever is on the other end. The problem of "how do you know you trust the other end" requires some foundational source of trust, whether that's trusting the transportation medium (that the person you handed the USB key to is actually who he/she claims to be), the issuer (could be yourself), and so on.

raverbashing 7y ago

Would Diffie-Hellman (still) be a good way of exchanging secrets? ECDH?

lvh 7y ago
Depending on context the answer is "absolutely" or "absolutely not", so that's hard to answer. I definitely wouldn't tell you to use finite-field Diffie-Hellman in any context, or any derived cryptosystems (ElGamal or IES), no.
- rocqua 7y ago
  I might be misreading, but it seems like you advise against IES. If so, does that extend to ECIES? I ask because the actual article actually suggests ECIES.
  - lvh 7y ago
    "Finite-field" is the operative phrase in that sentence. I wouldn't tell you to use IES, as in the thing where you do g^xy mod p. I would tell you to use libsodium's box, which is a specific implementation of something sorta like ECIES, though. The confusion is that IES/ElGamal sometimes means a family of systems and sometimes someone literally means FFDH + AESCTR or something. The abstract concept is fine, but you should use a hardened implementation.
tptacek 7y ago
Don't freelance your own kex protocol. Don't use multiplicative group DH. Don't use the NIST p-curves to implement ECDH, which will require you also to implement point validation to avoid invalid curve attacks. You want something like Curve25519 DH, but depending on your application, you probably also want an authenticated key exchange, which a naive Curve25519 protocol isn't going to give you.
- loup-vaillant 7y ago
  > Don't freelance your own kex protocol. Considering it took me 8 months to not even finish my own, making several serious mistakes in the process, even though I wrote my own goddamn crypto library and am standing on Noise's shoulders… I tend to agree. That said, we still have a problem: `crypto_box()` is nice, but it doesn't have any kind of forward secrecy, identity hiding, or key compromise impersonation resistance. Sure, offline protocols can't really have that (the best you can do is use signatures to avoid the key compromise impersonation issue, but then you loose some deniability). Online protocols however, can. But then what do we do? We could use Noise, (the Noise explorer now generates code in several languages), but you at least have to chose a pattern. Which one? How can you even notice that XK1 maximises client anonymity, and IX (properly used) maximises server security? Even if you know that, which are you going to use? And I'm not even talking about implementing your Noise pattern, should existing implementations not suffice (maybe you want to leverage a custom crypto library optimised for some embedded processor). Noise isn't simple. A serious drawback in my opinion. This, if I guess correctly, is what led you to recommend that horror that is TLS for client/server security. Because the burden of choosing a reasonable TLS library, of properly configuring that TLS library to only use TLS 1.3 with a limited set of ciphers (possibly just Curve25519 and ChaPoly)… still remains less error prone than picking up a Noise protocol. <PKI matters conveniently left out> That situation is deeply unsatisfactory. It's all well and good to tell people "don't make your own kex", but if you don't at the same time point them to an existing kex, they will be less likely to follow your advice. I mean, I didn't.

linsomniac 7y ago

^^^ I know this chap, he knows what he's talking about.

jj11837 7y ago
I smell bullshit. He can't explain how the secret key would be exchanged. "Agreeing on a key" isn't a problem any cryptographer needs to solve. You can tell this guy understands very little except how to sell something.