欧美综合一区二区,99国产精品久久久久久久成人热,久操伊人

本文介紹了如何處理“AES/GCM/NoPadding"的 IV 和身份驗(yàn)證標(biāo)簽?的處理方法，對大家解決問題具有一定的參考價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)吧！

問題描述

我在 Java 8 中使用 AES/GCM/NoPadding 加密，我想知道我的代碼是否存在安全漏洞.我的代碼似乎工作，因?yàn)樗梢约用芎徒饷芪谋?，但有一些?xì)節(jié)不清楚.

I'm using AES/GCM/NoPadding encryption in Java 8 and I'm wondering whether my code has a security flaw. My code seems to work, in that it encrypts and decrypts text, but a few details are unclear.

我的主要問題是:

Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
cipher.init(Cipher.ENCRYPT_MODE, key);
byte[] iv = cipher.getIV(); // ?????

該 IV 是否滿足對于給定密鑰，IV 不得重復(fù)"的要求.來自 RFC 4106?

我也很感謝我的相關(guān)問題的任何答案/見解(見下文)，但第一個(gè)問題最困擾我.我不知道在哪里可以找到回答這個(gè)問題的源代碼或文檔.

I'd also appreciate any answers / insight for my related questions (see below), but that first question is bugging me the most. I don't know where to find source code or documentation that answers this.

這里是完整的代碼，大致.如果我在寫這篇文章時(shí)引入了錯(cuò)誤，我深表歉意:

Here is the full code, roughly. I apologize in case I introduced errors while writing this post:

class Encryptor {
  Key key;

  Encryptor(byte[] key) {
    if (key.length != 32) throw new IllegalArgumentException();
    this.key = new SecretKeySpec(key, "AES");
  }

  // the output is sent to users
  byte[] encrypt(byte[] src) throws Exception {
    Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
    cipher.init(Cipher.ENCRYPT_MODE, key);
    byte[] iv = cipher.getIV(); // See question #1
    assert iv.length == 12; // See question #2
    byte[] cipherText = cipher.doFinal(src);
    assert cipherText.length == src.length + 16; // See question #3
    byte[] message = new byte[12 + src.length + 16]; // See question #4
    System.arraycopy(iv, 0, message, 0, 12);
    System.arraycopy(cipherText, 0, message, 12, cipherText.length);
    return message;
  }

  // the input comes from users
  byte[] decrypt(byte[] message) throws Exception {
    if (message.length < 12 + 16) throw new IllegalArgumentException();
    Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
    GCMParameterSpec params = new GCMParameterSpec(128, message, 0, 12);
    cipher.init(Cipher.DECRYPT_MODE, key, params);
    return cipher.doFinal(message, 12, message.length - 12);
  }
}

假設(shè)用戶破解我的密鑰 = 游戲結(jié)束.

Suppose that users cracking my secret key = game over.

更詳細(xì)的問題/相關(guān)問題:

More detailed questions / related questions:

cipher.getIV() 返回的 IV 以這種方式使用對我來說安全嗎?

它是否避免了在 Galois/Counter 模式中重復(fù)使用 IV、組合鍵的災(zāi)難?
當(dāng)我有多個(gè)應(yīng)用程序同時(shí)運(yùn)行此代碼時(shí)仍然安全嗎?所有應(yīng)用程序都從同一 src 數(shù)據(jù)(可能在同一毫秒內(nèi))向用戶顯示加密消息?
返回的 IV 是由什么制成的?它是一個(gè)原子計(jì)數(shù)器加上一些隨機(jī)噪聲嗎?
我是否需要避免 cipher.getIV() 并使用自己的計(jì)數(shù)器自己構(gòu)造一個(gè) IV?
假設(shè)我使用的是 Oracle JDK 8 + JCE Unlimited Strength 擴(kuò)展，實(shí)現(xiàn) cipher.getIV() 的源代碼是否可以在線獲得?

Does it avoid the catastrophe of reusing the IV,key combination in Galois/Counter Mode?
Is it still safe when I have multiple applications running this code at once, all displaying encrypted messages to users from the same src data (possibly in the same millisecond)?
What's the returned IV made of? Is it an atomic counter plus some random noise?
Do I need to avoid cipher.getIV() and construct an IV myself, with my own counter?
Is the source code implementing cipher.getIV() available online somewhere, assuming I'm using Oracle JDK 8 + JCE Unlimited Strength extension?

那個(gè) IV 總是 12 字節(jié)長嗎?

Is that IV always 12 bytes long?

身份驗(yàn)證標(biāo)簽是否總是 16 字節(jié)(128 位)長?

Is the authentication tag always 16 bytes (128 bits) long?

使用 #2 和 #3，并且沒有填充，這是否意味著我的加密消息總是 12 + src.length + 16 字節(jié)長?(所以我可以安全地將它們壓縮成一個(gè)字節(jié)數(shù)組，我知道正確的長度?)

With #2 and #3, and the lack of padding, does that mean my encrypted messages are always 12 + src.length + 16 bytes long? (And so I can safely squish them into one byte array, for which I know the correct length?)

在給定用戶知道的恒定 src 數(shù)據(jù)的情況下，向用戶顯示無限數(shù)量的 src 數(shù)據(jù)加密是否安全?

Is it safe for me to display an unbounded number of src data encryptions to users, given constant src data that the users know?

如果 src 數(shù)據(jù)每次都不同(例如，包括 System.currentTimeMillis() 或隨機(jī)數(shù))，我向用戶顯示無限數(shù)量的 src 數(shù)據(jù)加密是否安全?

Is it safe for me to display an unbounded number of src data encryptions to users, if the src data is different every time (e.g. including System.currentTimeMillis() or random numbers)?

如果我在加密之前用隨機(jī)數(shù)填充 src 數(shù)據(jù)會有幫助嗎?在前面和后面說 8 個(gè)隨機(jī)字節(jié)，還是只在一端?或者這根本沒有幫助/讓我的加密變得更糟?

Would it help if I padded the src data with random numbers before encryption? Say 8 random bytes in front and back, or only on one end? Or would that not help at all / make my encryption worse?

(因?yàn)檫@些問題都是關(guān)于我自己的代碼的同一塊，并且它們彼此密切相關(guān)，并且其他人在實(shí)現(xiàn)相同的功能時(shí)可能/應(yīng)該有相同的問題集，因此拆分感覺是錯(cuò)誤的問題分成多個(gè)帖子.如果這更適合 StackOverflow 的格式，我可以單獨(dú)重新發(fā)布它們.讓我知道！)

(Because these questions are all about the same block of my own code, and they are strongly related to each other, and others might/should have the same set of questions when implementing the same functionality, it felt wrong to split the questions into multiple posts. I can re-post them separately if that is more appropriate for StackOverflow's format. Let me know!)

久久久久久久av_日韩在线中文_看一级毛片视频_日本精品二区_成人深夜福利视频_武道仙尊动漫在线观看

如何處理“AES/GCM/NoPadding"的 IV 和身份驗(yàn)證標(biāo)

問題描述

推薦答案

相關(guān)文檔推薦