基於密碼的加密密鑰儲存？
RFC 5959規定了基於 PBKDF2-HMAC-SHA-256 和 AES 加密（ECB 模式）的私鑰加密儲存。
是否有使用 AES 的特殊原因，而不是簡單地將密鑰材料與 PBKDF2 輸出進行異或？是否只是為了更快地儲存長密鑰，因為長 PBKDF2 輸出需要很長時間才能導出？
在儲存短密鑰（例如 256 位 ECC 私鑰）時，是否有充分的理由使用 AES 或者俱有單個 PBKDF2（或其他 KDF）輸出塊的 XOR 是否足夠？
您對 RFC 5959 工作原理的描述不太正確。說 RFC 5959 在 ECB 模式下使用 AES 進行加密並不完全正確。
正確的說法是：如果明文正好是 128 位，則使用 ECB 模式，否則使用 RFC 3394 中的非平凡操作模式。在前一種情況下，ECB 模式很好，因為它只是一個數據塊. 在後一種情況下，RFC 5959 說要使用 RFC 5649 中定義的 AES Key Wrap with Padding 算法。該算法在 RFC 5649 的第 4 節中指定。RFC 5649 的第 4.1 節指定了密鑰包裝，並解釋了它是如何工作的。它說使用 RFC 3394 第 2.2.1 節的方案，如果輸入不完全是 128 位（如果您儲存 256 位 ECC 私鑰，就會出現這種情況。）
無論如何，密鑰包裝算法（如 RFC 5959 中指定的）比簡單的 XOR 好得多。（如果沒有鹽，如果你用它來保護具有相同密碼的兩個不同的私鑰，一個簡單的 XOR 將是不安全的：一個私鑰的洩露將使攻擊者能夠學習另一個私鑰（因為它只是一個兩個-正如 Ricky Demer 解釋的那樣，更嚴重的是，一個簡單的 XOR 具有延展性，因此將允許對底層方案進行相關密鑰攻擊；如果底層方案（例如，ECC 解密）容易受到相關密鑰攻擊，這將是一個問題。
最好使用密鑰包裝算法。密鑰包裝算法是專門為以加密形式儲存私鑰而設計的，它們使用簡單 XOR 以外的東西是有原因的。