細粒度粗粒度加密API

是否有任何理由選擇粗粒度的粗粒度API，尤其是加密處理？細粒度粗粒度加密API

粗：

AESDecrypt(pad_type, 
      mode_type, 
      mode_data, /* CTR or IV */ 
      ciphertext, 
      plaintext)

精細：

AES128_ECB_Decrypt(ciphertext, plaintext) 
AES128_CBC_PKCS5_Decrypt(iv, ciphertext, plaintext) 
AES128_CBC_NOPAD_Decrypt(iv, ciphertext, plaintext) 
AES256_CTR_Decrypt(ctr, ciphertext, plaintext)

來源

2011-09-15 Ronoc

沒有真正的功能（或安全）任何區別。

隨着所有版本只有一個功能，您可以更改算法和模式，而無需重新編譯（如果您的應用程序從別的地方需要這些值），而庫可以支持新的算法，而API的變化。

在許多不同的功能版本您的應用程序要麼鎖定到一個特定的算法，要麼你需要大量的if/case語句來支持多個。

來源

2011-09-15 10:29:06

您的用戶可能是密碼學技術熟練的人嗎？給非技術用戶太多的選擇是加密中的一件壞事 - 他們會犯錯誤。通過限制選擇，例如不提供ECB模式，可以幫助用戶避免錯誤。 – rossum

這是一個好點，但有點正交於這個問題。它也只適用於創建自己協議的人員，而不是實施現有協議的人員。有具體的選擇（功能或參數）的警告良好的文件可以在這裏幫助。 –

Skillz真的不是一個擔心。我們正在抽象我們的庫加密調用，以允許一個搬運工添加他們自己的定製庫。我們想知道這樣一個搬運工是否有接口的副作用。 – Ronoc

細粒度粗粒度加密API

回答

相關問題