3 ms·

A solution is to separate the encryption and authentication parts of SSL icons. Lets Encrypt and the likes get only the icon for ecrypted, the other old CA:s ge

by thecopy 10y ago

A solution is to separate the encryption and authentication parts of SSL icons. Lets Encrypt and the likes get only the icon for ecrypted, the other old CA:s gets also the authenticated icon.

pfg 10y ago
Ignoring the price tag, there's no difference between Let's Encrypt and "other old CAs". They both perform the same kind of validation for DV certificates. Some might even say Let's Encrypt does more than others, given that they support CAA. Other types of certificates (such as EV, which attempt to verify the business entity requesting the certificate exists and is indeed requesting it) already get different treatment in most browsers (namely the organization's name being shown in a green box).
geofft 10y ago
Do you think people who haven't studied crypto will understand the distinction between the two? I'm still amazed at the fact that FCC regulations confuse encryption with authentication. On ham radio frequencies, you usually can't transmit encrypted traffic, because that's not what the frequency allocation is for. But for certain types of remote command of automated craft, you're allowed to encrypt the message because someone sending a tampered/spoofed message could crash your craft. Which completely confuses encryption and authentication! And that's from people whose entire job is to think about rulemaking for electronic communication.
- sp332 10y ago
  Are you suggesting that signing a cleartext message would not involve encryption? Because I'm pretty sure the way "signing" works is to encrypt a hash of the message. So you need to send an encrypted message either way, even if it's a smaller one.
  - geofft 10y ago
    No, that's not how signing works - encryption is a function of a message and a public key, such that you can take the encrypted message and a private key and recover the cleartext. Since the public key is known to everyone, an attacker can modify the message, generate their own hash, and encrypt that with the public key, just as easily. It's true that you can construct a signing scheme by using a decryption algorithm: treat the hash as if it were a ciphertext and "decrypt" it with the private key, then anyone can verify it by "encrypting" it with the public key. That way only the person with the private key can sign it, which is the direction you want. But this doesn't run afoul of the FCC's rules, because you're not obscuring the message; everyone has the public key. If you're using so-called "textbook RSA" (i.e., the type of RSA you can explain on a whiteboard, with no hardening against real-world attacks), it's also true that the encryption and decryption operations are the same mathematical function. But you don't actually want to use textbook RSA, at the very least because of malleability (if you multiply two textbook-RSA ciphertexts, you get the same thing as if you'd decrypted them, multiplied the cleartexts, and encrypted that, except you don't need to know the private key), but also because of determinism, timing attacks, etc. Real-world RSA signature algorithms bear little resemblance to real-world RSA encryption or decryption algorithms.
    - duskwuff 10y ago
      Well... depends on the authentication scheme. One authentication scheme which doesn't involve any encryption is HMAC with a shared secret key. Sure, you need the key to authenticate the message -- but that's perfectly fine in many situations.

by thecopy 10y ago

A solution is to separate the encryption and authentication parts of SSL icons. Lets Encrypt and the likes get only the icon for ecrypted, the other old CA:s gets also the authenticated icon.

pfg 10y ago

Ignoring the price tag, there's no difference between Let's Encrypt and "other old CAs". They both perform the same kind of validation for DV certificates. Some might even say Let's Encrypt does more than others, given that they support CAA. Other types of certificates (such as EV, which attempt to verify the business entity requesting the certificate exists and is indeed requesting it) already get different treatment in most browsers (namely the organization's name being shown in a green box).

geofft 10y ago

Do you think people who haven't studied crypto will understand the distinction between the two? I'm still amazed at the fact that FCC regulations confuse encryption with authentication. On ham radio frequencies, you usually can't transmit encrypted traffic, because that's not what the frequency allocation is for. But for certain types of remote command of automated craft, you're allowed to encrypt the message because someone sending a tampered/spoofed message could crash your craft. Which completely confuses encryption and authentication! And that's from people whose entire job is to think about rulemaking for electronic communication.

sp332 10y ago
Are you suggesting that signing a cleartext message would not involve encryption? Because I'm pretty sure the way "signing" works is to encrypt a hash of the message. So you need to send an encrypted message either way, even if it's a smaller one.
- geofft 10y ago
  No, that's not how signing works - encryption is a function of a message and a public key, such that you can take the encrypted message and a private key and recover the cleartext. Since the public key is known to everyone, an attacker can modify the message, generate their own hash, and encrypt that with the public key, just as easily. It's true that you can construct a signing scheme by using a decryption algorithm: treat the hash as if it were a ciphertext and "decrypt" it with the private key, then anyone can verify it by "encrypting" it with the public key. That way only the person with the private key can sign it, which is the direction you want. But this doesn't run afoul of the FCC's rules, because you're not obscuring the message; everyone has the public key. If you're using so-called "textbook RSA" (i.e., the type of RSA you can explain on a whiteboard, with no hardening against real-world attacks), it's also true that the encryption and decryption operations are the same mathematical function. But you don't actually want to use textbook RSA, at the very least because of malleability (if you multiply two textbook-RSA ciphertexts, you get the same thing as if you'd decrypted them, multiplied the cleartexts, and encrypted that, except you don't need to know the private key), but also because of determinism, timing attacks, etc. Real-world RSA signature algorithms bear little resemblance to real-world RSA encryption or decryption algorithms.
  - duskwuff 10y ago
    Well... depends on the authentication scheme. One authentication scheme which doesn't involve any encryption is HMAC with a shared secret key. Sure, you need the key to authenticate the message -- but that's perfectly fine in many situations.