2015-03-13 62 views
0

我在Java SE和Android項目上使用相同的代碼。運行在Java和Android上的應用程序連接到相同的MQTT代理並交換消息。消息使用AES加密/解密。我有一個Java安全體系結構的經驗非常少,所以我的問題是:Java和Android之間的加密/解密

1)我應該期待什麼,如果我使用相同的密碼算法,但來自不同供應商(一個Java和其他Android上的)?使用不同的提供程序解密用另一提供程序加密的消息是否自動錶示該消息不會被成功解密?

2)什麼是推薦的供應商使用,將允許Java和Android應用程序在這種情況下,正確的溝通?我在網上看到了一些答案,但有些答案相對較舊,所以我不確定它們是否仍然是最佳答案。

+2

AES是標準。假設你使用的是同一個祕密,那麼你正在使用哪個實現並不重要 – odedsh 2015-03-13 09:40:15

+0

當算法未完全指定時,提供者之間當然存在差異。不要忘記指定操作模式和填充。不要使用'Cipher.getInstance( 「AES」);',而是'Cipher.getInstance( 「AES/CBC/PKCS5Padding」);'甚至更好的認證加密,如GCM或CCM是由BouncyCastle的提供。 – 2015-03-13 10:09:53

+0

在Java SE上使用'BouncyCastle'和在Android上使用'SpongyCastle'。同一版本。 – EpicPandaForce 2015-03-13 10:25:25

回答

1

如果我使用相同的Cipher算法,但來自不同的提供者(一個在Java上,另一個在Android上),我應該期待什麼?

相同的結果。

是否使用不同的提供程序來解密用另一個提供程序加密的消息會自動錶示該消息不會被成功解密?

2)什麼是推薦的供應商使用,將允許Java和Android應用程序在這種情況下,正確的溝通?

的一個內置的JRE,假設它支持AES。

但我不知道爲什麼你沒有使用SSL。

+0

謝謝你的回答。正在啓用SSL。就所使用的提供者而言,您是否會建議我不在代碼中指定提供者名稱,而是讓代碼使用默認提供者?這會在100%的時間內工作嗎? – Branex 2015-03-13 10:08:29

+0

如果它在兩端都起作用,它應該100%的時間工作。這並不免除你必須親自測試它。你最好直接跳到SSL。沒有意義建立兩個不兼容的產品版本,其中一個具有可疑的安全性。 – EJP 2015-03-13 10:21:40