对于 SSL，有SSL 3.0、TLS 1.0、TLS 1.1和TLS 1.2。

在 SSL 3.0 中，使用内部伪随机函数(PRF) 将共享密钥（从密钥交换机制获得）扩展为对称密钥，用于后续的对称加密。此 PRF 始终使用 MD5 和 SHA-1。

在 TLS 1.0 和 TLS 1.1 中，PRF 被一个新的结构所取代，它仍然使用 MD5 和 SHA-1，以一种可以说是“更好”的方式（从密码学上讲）。

MD5 和 SHA-1 还用于 SSL 3.0、TLS 1.0 和 TLS 1.1 以计算握手中的签名（使用基于证书的客户端身份验证时来自客户端的签名，使用 DHE 密码套件时来自服务器的签名） ; 签名的内容将使用 SHA-1（对于 DSA/ECDSA）或同时使用MD5 和 SHA-1（对于 RSA）进行哈希处理。

此外，交换的握手消息再次使用 MD5 和 SHA-1 进行散列，以计算Finished结束握手的消息；在 SSL 3.0 的情况下，两个哈希“按原样”使用，而在 TLS 1.0 和 1.1 中，涉及额外的 PRF 调用。

除了握手之外，应用程序数据将使用一些具有完整性检查的对称算法进行加密，并且完整性检查通常会使用 HMAC（在 SSL 3.0 的情况下，是 HMAC 衍生物），这将基于在协商密码套件。以“MD5”结尾的密码套件此时使用 MD5，而以“SHA”结尾的密码套件使用 SHA-1。

使用 TLS 1.2，情况发生了变化。PRF 和仍然存在，但仅使用一个散列函数，并且该散列函数是密码套件中协商的那个。相同的散列函数将用于散列消息的握手消息Finished（顺便说一下，这对于嵌入式 RAM 匮乏的实现来说很麻烦，因为实现必须要么缓冲ClientHello和 的开头ServerHello，要么启动一堆散列函数，因为在ServerHello解析之前不知道将使用的哈希函数）。当密码套件以“MD5”结尾时，哈希函数为 MD5。当它以“SHA”结尾时，就是 SHA-1。当它以“SHA256”结尾时，就是 SHA-256。

当使用GCM时，没有 per-record HMAC；完整性是从 GCM 模式本身获得的。因此密码套件中指定的散列函数仅用于 PRF 和其他与握手相关的用途。

现在棘手的一点是：在 TLS 1.2 之前没有用于 TLS 的标准 GCM 密码套件。用于 TLS 的 GCM 密码套件以RFC 5288开头；其他在RFC 5289和一些后续 RFC 中定义。所有当前定义的密码套件都发布在IANA 注册中心。所有 GCM 密码套件仅适用于 TLS 1.2+，而且，它们都使用 SHA-256 和 SHA-384，而不是 SHA-1。相应地，截至 2013 年 7 月，没有在 TLS 中同时使用 SHA-1 和 GCM 的标准方法。如果您想要 GCM（使用 AES 或其他算法），则需要 TLS 1.2，并且散列函数（用于握手）将是 SHA-256 或 SHA-384。据推测，也可以定义具有 SHA-512 的密码套件，但这还没有发生。

当然，每条规则都有例外。SSL 中的公钥是通过X.509 证书交换的，这些证书是使用大量密码学的复杂对象，您经常会发现一些 SHA-1 甚至 MD5 潜伏在那里。但这主要超出了 TLS 的范围，特别是不受协商密码套件的影响。理论上，客户端和服务器可能/应该为此协商支持的哈希函数，但实际上服务器将发送它从其 CA 获得的证书，并且在这件事上几乎没有选择。

对于 SSH，算法是相互独立协商的；没有真正的包罗万象的密码套件的概念。请参阅RFC 4253，第 7.1 节。RFC 5647定义了 AES/GCM 与 SSH 的使用，但不关心内部使用的散列函数；当然，如果使用 GCM，将不会有基于散列的 MAC 用于批量数据加密（这就是 GCM 的重点：它带有自己的 MAC），但内部仍然使用散列函数，至少，密钥派生（类似于 SSL 中所谓的“PRF”）。

RFC 6239更加彻底，因为它尝试为 SSH 定义算法集，遵循所谓的NSA Suite B。这意味着椭圆曲线 Diffie-Hellman（SSL 术语中的“ECDHE”：对于 SSH，密钥交换始终使用“临时密钥”）、AES/GCM...和 ​​SHA-256 或 SHA-384，而不是 SHA-1。此外，当严格遵循 RFC 6239 时，SSH 服务器公钥（用于签名的永久公钥）应该使用 ECDSA，而不是 RSA。

因此，至少在理论上，您可以将 SSH 与 ECDHE、RSA 签名、AES/GCM和SHA-1 一起使用，但是当您使用 GCM 时，我们鼓励您也切换到 SHA-256 或 SHA-384。SSH 实现的实际工作往往取决于确切的软件版本、编译选项和本地配置，并且需要测试。