On 2016-11-11 12:08, li...@lazygranch.com wrote: > That does explain a lot, but why when I "talk to myself" (send myself email) > do I get a lower grade (less bits) of encryption than when another server is > sending mail? Is there some parameter I need to set in postfix?
Which particular algorithm gets chosen is usually up to the TLS client (which can be another server connecting to yours): At the start of the connection, client and server tell each other what ciphers they support, and the client picks one. There's pros and cons to 128 bit and 256 bit ciphers (128 bit is good enough and faster; 256 bit has more safety margin against *some* attacks – but not all), some programs prefer one or the other. You'll have to look up whether you can tell your particular client software to prefer 256 bit ciphers, if you want to. > > Original Message > From: Sven Schwedas > Sent: Friday, November 11, 2016 2:59 AM > To: postfix-users@postfix.org > Subject: Re: bits of encryption > > On 2016-11-11 11:16, li...@lazygranch.com wrote: >> This comes under the notion that if you don't ask, you don't learn. > > It is a bit off topic, yes. > >> I did some dovecot2 updates, so naturally I decided to test the mail >> system. When I mail a message to myself, this is the TLS notification: >> (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) >> >> However I do receive mail with higher levels of encryption. For example: >> (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) >> >> But in both cases, isn't my certificate the one being used for >> encryption? Other than building my cert at 4096 bits, I don't remember >> much other than it was a pain to get working. > > Your certificate is used in both cases, But™. > > There's lots of bits to an encrypted connection: > >> ECDHE-RSA-AES128-GCM-SHA256 > > • ECDHE means that every connection negotiates (DH/Diffie Hellman) an > ephemeral key (=used for only this connection, the E in DHE) based on > elliptic curves (EC). This is "forward secure" encryption, and makes > sure that someone who steals your certificate cannot use it to decrypt > old, recorded TLS sessions. > > • RSA is algorithm of your certificate. That's the 4096 bit part. This > is used to sign the ECDHE parameters, so the other end knows they're > coming from you. > > But, both elliptic curves and RSA are Really Damn Slow. So your (ECDHE) > session key is only used to exchange a symmetric key (shared password). > > • In your case, this symmetric key is then used for AES128 (/AES256). > Symmetric algorithms are really fast, especially since many systems have > dedicated AES hardware nowadays. That's where the "128/128 bits" part > comes from: It's the total/effective size of your symmetric cipher. > > (Why the distinction between total and effective size? 3DES. Symmetric > ciphers are relatively fast, but hardware acceleration can make or break > it. DES was the predecessor to AES and worked with 56 bit keys. AES is > good, but there was/is a lot of hardware that has a tiny microcontroller > and DES hardware acceleration, and nothing else. 3DES runs DES three > times in a row with different keys, giving you 168/112 bits because some > operations cancel each other out. It's clunky and awkward, but on the > devices mentioned, it's still faster than AES, and _much_ safer than > DES. On everything else, not so much.) > > • AES (and other block ciphers) works on chunks of data, and each chunk > needs to be encrypted separately… but when two chunks are the same, and > you use the same key, you get the same "secret" text: > > https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg > > There's several ways to work around this, by adding additional data to > each block to make it more random. In your case, it's GCM (Galois > Counter Mode). > > • Finally, the "-SHA256" part. That's the hash function both sides use > for various things. (Hashing the shared symmetric key e.g., and if > you're using AES-CTR/AES-CBC instead of -GCM, to give tamper resistance. > GCM has that built in.) > > -- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas, Systemadministrator Mail/XMPP sven.schwe...@tao.at | Skype sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz https://www.tao-digital.at | Tel +43 680 301 7167 https://pave.software – PAVE Password Manager
signature.asc
Description: OpenPGP digital signature
