Your question appears to have nothing to do with certificates or hashes. Neither one involve symmetric ciphers (like DES or AES) at all. The actual answer is just a matter of how Outlook (or Mail.app) is configured on each machine, nothing more. I don't know how to control the ciphers used on Outlook for Mac, but here are the steps for Outlook 2013 on Windows; hopefully you can find their equivalent on Macs:
- In Outlook, open the
File tab on the left of the ribbon.
Options from the left sidebar that appears.
- In the "Outlook Options" window that pops up, select
Trust Center from the left sidebar.
- Under the "Microsoft Outlook Trust Center" heading, click the
Trust Center Settings button.
- In the "Trust Center" window that appears, select
E-mail Security from the left sidebar.
- Under the "Encrypted E-mail" heading, click the [Settings] button.
- In the "Change Security Settings" window that appears, under the "Certificates and Algorithms" heading, check the "Encryption Algorithm" drop-down. Set it to
AES (256-bit) if it isn't already set to that.
You might find the following page helpful for your Outlook for Mac users: https://support.office.com/en-us/article/Digital-signing-and-encryption-settings-8A6EB21D-0BEB-4E66-A63A-2D362966CF77. In particular, it tells you the steps to get to the settings page:
To access these settings from the primary Outlook Accounts preferences screen, select the account, click Advanced, and then click the Security tab.
After that, it should be similar to the instructions above (under "Encryption settings", find the "Encryption algorithm" option and select
Something to clear up: the certificate has nothing to do with the symmetric cipher used for bulk encryption. There are three types of cryptographic primitive in use, here, and none of them have anything to do with the others:
- Asymmetric ciphers (in this case, 2048-bit RSA). These have pairs of keys, a public key that you let everybody see, and a corresponding private key that you don't let anybody see. Anybody with the public key can encrypt a message such that only you (the holder of the private key) can decrypt it, and anybody with the public key can verify that you signed a message using your private key. However, these ciphers are extremely computationally expensive, so usually you only encrypt or sign a short string (a symmetric key for a message or a hash digest of a message/certificate, respectively). Encryption provides privacy / confidentiality (nobody but the holder of the private key can read the message). Signing provides authentication (only the holder of the private key could have created that signature) and integrity (if the message is tampered with, the signature won't verify correctly, so if it verifies you know the message wasn't messed with). These are used for:
- a CA (Certificate Authority) signing a certificate's hash (so that the recipient knows the certificate is yours and nobody is spoofing your key)
- a message sender signing a message's hash (so the recipient knows you sent the message and it hasn't been tampered with)
- encrypting a bulk encryption key to send with a message (this key is usually randomly generated for each message, and is never exchanged in plain text).
- Symmetric ciphers (like 168-bit 3DES or 256-bit AES). These are used for the actual message bodies (and attachments) that are being encrypted. They are fast, but the same key is used for both encryption and decryption (that is, they are symmetric) so there is no public key that you can safely share with the whole world. Thus, the symmetric key for a given message is sent protected by asymmetric encryption. These provide confidentiality only.
- Many symmetric ciphers are a type known as block ciphers (this includes all forms of AES, DES, Blowfish, and many others). Block ciphers work on fixed-length blocks. To be used with messages longer than one block, one uses a mode of operation; some of these are more secure than others. To securely encrypt messages that aren't an exact multiple of the block size, one uses padding.
- While padding can make it possible to detect naïve tampering with the encrypted data (or ciphertext), it is easy for a skilled attacker to bypass this detection. Also, padding is not always used since the data to encrypt is sometimes reliably an exact multiple of the block size (for example, hard disk sectors). Therefore, padding alone should not be trusted to provide integrity.
- Similarly, the most common modes of operation (CBC or CTR) do not provide integrity. Tampering with data encrypted using a block cipher in CBC mode can produce attacker-controlled changes in the decrypted data, although it will corrupt data beyond that. However, some modes of operation (like GCM) also ensure integrity when decrypting. If only one other party has the symmetric key, then these modes also provide authentication (you know that the message came from the other holder of the key). An algorithm that provides confidentiality, integrity, and authentication is called authenticated encryption.
- There also exist symmetric stream ciphers (such as RC4, which was widely used until exploitable weaknesses in it were discovered). These have no block size, need no padding, and are usually extremely fast. However, they only provide confidentiality, and must be combined with other primitives to provide integrity and authentication.
- Hash functions, sometimes called one-way encryption, like SHA-256 (a member of the SHA2 family). Hash algorithms are used to produce short codes called digests (suitable for asymmetric signatures) that can be used to demonstrate that something (like a certificate or message) has not been tampered with. The following are some properties common to secure hash algorithms:
- Resistance to preimage attacks. That is, having the hash digest doesn't make it possible to produce the original data that was hashed to produce this digest.
- Collision resistance. For a given message (such as an email or certificate) and its digest (such as was used to create a trusted signature), it should not be feasible to find a second message that produces the same digest.
The choices for one primitive have nothing to do with another. You can have somebody's certificate that was signed using 512-bit RSA (super weak) signature of an MD5 hash (cryptographically broken) but contains a 4096-bit RSA key that you can use to encrypt messages back to that person. You can't trust the signature on the certificate, but if you trust the source of the certificate anyway there's no reason you couldn't use that super-strong RSA key. You can encrypt a message to that person using the incredibly weak DES (56-bit) cipher, or using 256-bit AES; for either one, you'll send the symmetric encryption key protected by that 4096-bit RSA key.
There exist an enormous number of potential combinations of primitives (asymmetric and symmetric ciphers, hash function, key exchange algorithm if needed, mode of operation if needed, padding algorithm if needed). A number of popular ones are grouped as named "cipher suites" for use in TLS. That term is not commonly used for S/MIME (and some available features of TLS, such as ephemeral keys, are not available for asynchronous communication like email). However, the idea of combining a set of primitives to provide strong security against multiple types of attack is still relevant.