SSL 加密、SHA-1 和 SHA-2

发布于 2024-09-01 13:38:07 字数 301 浏览 5 评论 0原文

我正在尝试实施 SHA-2 加密而不是 SHA-1

为此,我知道这两种哈希算法之间的位数不同,这让我感到困惑。

如何实现这一目标?我需要在哪些部分进行必要的更改?

我可以使用 Java、Python 和任何其他主要编程语言的任何开源库。

I am trying to implement SHA-2 encryption instead of SHA-1.

For this, I know that the number of bits between these two hash algorithms are different, and it confuses me.

How can this be achieved and at what parts do I need to make required changes?

I can use any open source library from Java, Python and any other major programming language.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

隔纱相望 2024-09-08 13:38:07

首先,无论是 SHA-1 还是与 SHA-2 相关的任何算法都不是“加密”算法。它们是哈希函数。在 SSL 中,哈希函数主要用于通过 HMAC 结构实现完整性,而不是机密性。哈希函数接受任意长度的输入,并产生固定长度的输出,这是输入数据的一种“摘要”;该操作是不可逆的。

哈希函数是“公开的”:没有机密数据,没有密钥;每个人都可以计算任何给定输入的哈希函数输出。 “消息验证码”(MAC) 是一种“密钥散列”:在此过程中还会输入密钥(即任意一组位),因此需要了解密钥才能(重新)计算MAC 输出。这用于完整性检查(发送方使用密钥计算 MAC,接收方使用密钥重新计算 MAC;如果 MAC 匹配,则数据正确,因为攻击者不知道密钥,无法获得更改数据并根据更改的数据计算有效的 MAC)。

HMAC 是将散列函数(例如 SHA-1)转换为 MAC 的构造。 TLS(这是 SSL 的当前标准名称)使用 HMAC。当与给定的哈希函数 h 一起使用时,HMAC 的输出与 h 的输出具有相同的大小。该输出可以按照惯例被截断:HMAC/SHA-1 名义上产生 160 位输出,但在某些协议中通常只保留前 96 位。 SSL 中不会发生此类截断。

FIPS 180-3 标准定义了五种哈希函数,分别命名为 SHA-1、SHA-224、SHA-256、SHA-384 和 SHA-512,输出长度分别为 160、224、256、384 和 512 位。 SHA-224、SHA-256、SHA-384 和 SHA-512 函数通俗地称为“SHA-2”,因此“SHA-2”不是一个函数,而是一系列四个哈希函数。

TLS 规范定义了密码套件。密码套件是客户端和服务器在连接初始阶段(“握手”)达成一致的一组密码算法。这些算法中包括用于确保数据完整性的 MAC。一些标准密码套件指定 MAC 应为“具有 SHA-256 的 HMAC”,即使用 SHA-2 函数之一的东西。

因此,您的问题的答案是:“只需将客户端和服务器配置为使用具有 HMAC/SHA-256 的密码套件之一”。如果您的 SSL 实现不支持此类密码套件,那么您将必须对其进行修改,这将需要非常彻底地了解 SSL 的工作原理;阅读并理解完整的 RFC 5246 是必要的。

First of all, neither SHA-1 nor anything related to SHA-2 is an "encryption" algorithm. They are hash functions. In SSL, hash functions are used mostly for integrity, not confidentiality, through the HMAC construction. A hash function takes an input of arbitrary length, and produces an output with a fixed length, which is a kind of "digest" of the input data; the operation is meant not to be reversible.

A hash function is "public": there is no confidential data, no key; everybody can compute the hash function output on any given input. A "message authentication code" (MAC) is a kind of "keyed hash": a secret key (i.e. an arbitrary bunch of bits) is also input in the process, so that knowledge of the key is necessary to (re-)compute the MAC output. This is used for integrity checks (the sender uses the key to compute the MAC, the receiver uses the key to recompute the MAC; if the MAC matches, then the data is correct, because an attacker, not knowing the key, could not have altered the data and computed a valid MAC on the altered data).

HMAC is a construction which turns a hash function (such as SHA-1) into a MAC. TLS (that's the current, standard name of SSL) uses HMAC. The output of HMAC, when used with a given hash function h, has the same size than the output of h. That output can be conventionally truncated: HMAC/SHA-1 nominally produces a 160-bit output, but it is customary, in some protocols, to keep only the first 96 bits. Such truncation does not occur in SSL.

The FIPS 180-3 standard defines five hash functions, named SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512, with output lengths of 160, 224, 256, 384 and 512 bits respectively. The SHA-224, SHA-256, SHA-384 and SHA-512 functions are colloquially known as "SHA-2", so "SHA-2" is not one function, but a family of four hash functions.

The TLS specification defines cipher suites. A cipher suite is a set of cryptographic algorithms that the client and server agree upon during the initial phase of the connection (the "handshake"). Among the algorithms is the MAC to use to ensure data integrity. Some of the standard cipher suites specify that the MAC shall be "HMAC with SHA-256", i.e. something which uses one of the SHA-2 functions.

So the answer to your question is: "just configure the client and server to use one of the cipher suites with HMAC/SHA-256". If your SSL implementation does not support such cipher suites, then you will have to modify it, which will entail understanding quite thoroughly how SSL works; reading and understanding the complete RFC 5246 will be necessary.

我很坚强 2024-09-08 13:38:07

hashlib 模块MessageDigest 支持所有 SHA-2算法。

The hashlib module and MessageDigest support all SHA-2 algorithms.

日暮斜阳 2024-09-08 13:38:07

据我所知,在 SSL 中实现 SHA256 所需了解的所有内容都包含在 RFC 5246 中

但我怀疑你对加密技术的了解还远远不够……SHA 2 不存在,你正在寻找 SHA256、SHA384 或 SHA512,它不是加密算法,而是加密哈希函数。

那么,你到底想做什么?

So far as I can see, everything you need to know to implement SHA256 in SSL is covered in RFC 5246.

But I suspect you're nowhere near understanding enough cryptography to do this... SHA 2 doesn't exist, you're looking for SHA256, SHA384 or SHA512, and it is not an encryption algorithm, but instead a cryptographic hash function.

So, what are you actually trying to do?

冷默言语 2024-09-08 13:38:07

我相信您会越来越多地看到这个问题。现在,GoDaddy 在提交证书签名请求时可以选择指定您要使用 SHA1 还是 SHA2。

不过,这是一篇有趣的读物。我基本上知道它在要求什么,以及如何强制我的服务器使用使用其中一种或另一种的密码。不确定我到底知道有什么区别,或者为什么使用其中一种会更好。

I'm sure you will see more and more of this question. GoDaddy now has an option when submitting a certificate signing request, to specify whether you are going to be using SHA1 or SHA2.

This was an interesting read here though. I knew basically what it was asking and how to force my server to use a cypher that used one or the other. Not sure I knew exactly what the difference was or why it would be better to use one or the other though.

怪我太投入 2024-09-08 13:38:07

试试这个,它适用于 weblogic SQL Authenticator

 public static void main(String args[]) throws NoSuchAlgorithmException {
 String password="abcdef"; 
 System.out.println("{SHA-1}" + new sun.misc.BASE64Encoder().encode(java.security.MessageDigest.getInstance("SHA1").digest(password.getBytes())));
 }

try this, it works for weblogic SQL Authenticator

 public static void main(String args[]) throws NoSuchAlgorithmException {
 String password="abcdef"; 
 System.out.println("{SHA-1}" + new sun.misc.BASE64Encoder().encode(java.security.MessageDigest.getInstance("SHA1").digest(password.getBytes())));
 }
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文