問題描述

我需要將加密數據從 Java 客戶端發送到 C# 服務器.現在我正在學習如何使用 AES 加密數據(要求).按照這個公認的答案 android 加密/使用 AES 解密，我正在執行以下操作:

I need to send encrypted data from a Java client to a C# server. Right now I'm learning how to encrypt data using AES (requirement). Following this accepted answer android encryption/decryption with AES I'm doing the following:

byte[] keyStart = "qweroiwejrwoejlsifeoisrn".getBytes(); // Random character string

byte[] toEncrypt = myMessageString.getBytes();

keyGen = KeyGenerator.getInstance("AES");
sr = SecureRandom.getInstance("SHA1PRNG");
sr.setSeed(keyStart);
keyGen.init(128, sr);
SecretKey secretKey = keyGen.generateKey();
byte[] secretKeyByte = secretKey.getEncoded();

SecretKeySpec skeySpec = new SecretKeySpec(secretKeyByte, "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
cipher.doFinal(toEncrypt);

由于算法使用 SecureRandom 使用 keyStart 我不確定這是否可以在 C# 甚至在另一個 中解碼>Java 程序，沒有 SecureRandom.

Since the algorithm uses a SecureRandom using the keyStart I am not sure if this can be decoded in C# or even in another Java program, without the SecureRandom.

這種加密/解密是否只知道 keyStart 的值，或者因為我正在使用 SecureRandom 我仍然需要傳遞其他東西才能解密?

Will this encryption/decryption work with just knowing the value of keyStart or since I'm using SecureRandom I still need to pass something else in order to decrypt?

另外，有沒有更好的方法，或者這個就可以了?

Also, is there a better way to do it or is this one just fine?

推薦答案

不，您應該使用 SecureRandom 從靜態數據派生密鑰的整個想法相當糟糕:

No, the whole idea that you should use a SecureRandom for key derivation from static data is rather bad:

1. SecureRandom的主要功能是生成隨機值，不應該用作密鑰流的生成器；
2. SecureRandom，當用 "SHA1PRNG" 實例化時，并沒有實現定義明確的算法，而且實際上已知算法會發生變化，即使從一個 Sun JDK 到另一個;
3. Oracle 提供的"SHA1PRNG" 實現使用初始種子作為only 種子，其他人可能只是添加 種子到隨機池中.

1. SecureRandom's main function is to generate random values, it should not be used as a generator for a key stream;
2. SecureRandom, when instantiated with "SHA1PRNG" does not implement a well defined algorithm, and the algorithm has actually be known to change, even from one Sun JDK to another;
3. The Oracle provided implementation of "SHA1PRNG" uses the initial seed as only seed, others may just add the seed to the random pool.

已知使用 "SHA1PRNG" 作為密鑰派生函數會在多個 Android 版本上產生問題，并且可能在任何其他 Java RE 上失敗.

Using "SHA1PRNG" as key derivation function has been known to produce issues on several versions of Android, and may fail on any other Java RE.

那么你應該怎么做呢?

1. 使用 new SecureRandom() 甚至更好，KeyGenerator 生成真正的隨機密鑰，如果您需要全新的隨機密鑰，則無需播種隨機數生成器；
2. 直接向SecretKeySpec提供一個已知密鑰的byte[]，或者使用十六進制解碼器從十六進制解碼(注意String 實例很難從內存中刪除，所以只有在沒有其他方法的情況下才這樣做)；
3. 如果您想從密碼創建密鑰，請使用 PBKDF2(使用比在鏈接)；
4. 如果您想從一個密鑰種子創建多個密鑰，請使用真正的基于密鑰的密鑰派生機制，例如使用 HKDF(見下文).

1. Use new SecureRandom() or even better, KeyGenerator to generate a truly random key, without seeding the random number generator if you need a brand new random key;
2. Directly provide a byte[] of a known key to SecretKeySpec, or use a hexadecimal decoder to decode it from hexadecimals (note that String instances are hard to delete from memory, so only do this if there is no other way);
3. Use PBKDF2 if you want to create a key from a password (use a higher iteration count than the one provided in the link though);
4. Use a true Key Based Key Derivation Mechanism if you want to create multiple keys from one key seed, e.g. use HKDF (see below).

如果種子是由例如生成的，選項 4 將是首選.密鑰協商算法，例如 Diffie-Hellman 或 ECDH.

Option 4 would be preferred if the seed was generated by e.g. a key agreement algorithm such as Diffie-Hellman or ECDH.

請注意，對于選項 3，PBKDF2，您最好只使用 ASCII 密碼.這是因為 Oracle 的 PBKDF2 實現不使用 UTF-8 編碼.

Note that for option 3, PBKDF2, you would be wise to keep to ASCII passwords only. This is due to the fact that the PBKDF2 implementation by Oracle does not use UTF-8 encoding.

至于選項 4，我幫助將所有好的 KBKDF 添加到 Bouncy Castle 庫 因此，如果您可以將 Bouncy Castle 添加到您的類路徑和/或已安裝的安全提供程序列表中，則無需自己實現 KBKDF.目前最好的 KBKDF 可能是 HKDF.如果您無法將 Bouncy Castle 添加到您的類路徑中，那么您可能希望在派生數據上使用 SHA-256 輸出的最左邊字節作為窮人的"KDF.

As for option 4, I've helped with adding all good KBKDF's to the Bouncy Castle libraries so there isn't a need to implement a KBKDF yourself if you can add Bouncy Castle to your classpath and/or list of installed security providers. Probably the best KBKDF at the moment is HKDF. If you cannot add Bouncy Castle to your classpath then you might want to use the leftmost bytes of SHA-256 output over the derivation data as a "poor man's" KDF.

這篇關于創建 AES 密鑰比播種 SecureRandom 更好的方法的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！