加密（模式和填充） [英] Encryption (mode and padding)

问题描述

我的任务是编写一个涉及加密的小型Java控制台应用程序。我不熟悉加密，所以我不得不先做一些阅读。到目前为止，给出的高级别要求是应该使用AES-256来生成一次性密钥来加密文件。

I was tasked with writing a small Java console application that involves encryption. I am not familiar with encryption, so I had to do some reading up first. So far the high level requirements given is that AES-256 should be used to generate a one-time key to encrypt a file.

之后，接收者的公钥RSA-2048）来加密AES-256一次性密钥。然后将加密的文件和加密的一次性AES-256密钥压缩并发送给收件人。

After that, the recipient's public key (RSA-2048) should be used to encrypt that AES-256 one-time key. The encrypted file and the encrypted one-time AES-256 key will then be zipped up and send to recipient.

根据我对加密和解密的理解，除了算法（RSA，AES等），还有称为模式和填充的事情。例如，以下代码将RSA指定为算法，ECB模式和PKCS1Padding。

From what I understand about encryption and decryption from reading up, apart from the algorithm (RSA, AES, etc), there is also things called mode and padding. For example, the following code specified RSA as algorithm, ECB mode and PKCS1Padding.

Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");

加密和解密时必须使用相同的算法，模式和填充。

The same algorithm, mode and padding must be used in the encryption and decryption. Therefore, is it reasonable for me to go ask the users on what mode and padding they want?

我注意到Cipher cipher = Cipher.getInstance（RSA）似乎是不可能的使用ECB的默认模式和填充PKCS1Padding，因此这行代码与上面相同。那么是否可以假设ECB模式和PKCS1Padding模式将用于RSA-2048作为默认模式？

I notice that Cipher cipher = Cipher.getInstance("RSA") seems to use the default mode of ECB and padding of PKCS1Padding, and so this line of code is the same as the above. So is it ok to assume that ECB mode and PKCS1Padding mode will be used for RSA-2048 as default?

推荐答案

发送消息您应该使用较新的OAEP方案，因为RSA与PKCS＃1 v1.5可能容易受到 Bleichenbacher攻击。然而，完全可能的，甚至有可能，某人请求RSA混合加密从未听说过攻击。一般来说，仍然使用PKCS＃1 v1.5填充作为默认填充。

No, for sending messages you should use the newer OAEP scheme, as RSA with PKCS#1 v1.5 may be vulnerable to the Bleichenbacher attack. It is however entirely probable and even likely that somebody requesting RSA hybrid encryption has never heard of the attack. In general PKCS#1 v1.5 padding is still used as the default.

您不应该期望用户为您做出安全决定，除非唯一的用户是学生加密（并知道上面的攻击）。安全一般不应该过多依赖教育用户。

You should never expect users to make security decisions for you, unless the only users are students of cryptography (and know about the attack above). Security in general should not rely too much on educating users.

我个人会向请求者询问填充。您还应该检查他们是否期望对称加密的认证（MAC，HMAC，认证密码或签名）。如果他/她不能回答这个问题，他们可能不知道有关加密。

Personally I would certainly asking the requester about the padding. You should also check if they would expect authentication (MAC, HMAC, authenticated cipher or a signature) for the symmetric encryption. If he/she cannot answer the question they may not know that much about encryption.

我目前不会考虑你已经完成的要求（虽然学习目的可以是一个借口。）

I would not currently consider the requirements you have been given to be complete (although "for learning purposes" can be one hell of an excuse).

RSA / ECB / PKCS1Padding实际上不实现ECB模式加密。它应该被称为RSA / None / PKCS1Padding，因为它只能用于加密一个明文块（或确实是一个秘密密钥）。这只是Sun / Oracle的命名错误。

"RSA/ECB/PKCS1Padding" actually doesn't implement ECB mode encryption. It should have been called "RSA/None/PKCS1Padding" as it can only be used to encrypt a single block of plaintext (or, indeed a secret key). This is just a naming mistake of Sun/Oracle.

还有一个称为RSA-KEM的混合加密模式，应至少与RSA OAEP一样安全，尚未在Java SE中实现。

There is also a hybrid encryption mode called RSA-KEM that should be at least as secure as RSA OAEP, but it has not been implemented within Java SE.

AES-256本身不应用于生成一次性密钥。您应该使用 KeyGenerator 的实例生成AES-256一次性密钥（这可能是一个命名混淆，因为 KeyGenerator 本身不会使用 AES，它会为 AES创建密钥。

AES-256 itself should not be used to "generate a one time key". You should use an instance of KeyGenerator generate an AES-256 one time key (this is likely a bit of naming confusion because the KeyGenerator itself does not use AES, it creates keys for AES).

这篇关于加密（模式和填充）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！