Tham gia Đăng nhập
Điểm:0
Kim Mỹ avatar Crypto

AES 256bitkey được tạo từ PBKDF2 an toàn đến mức nào

lá cờ cn
Kim Mỹ

Tôi đang sử dụng mã hóa CryptoJS AES 256:

CryptoJS.AES.encrypt(realData, generateKey(passphrase), {iv: iv});

Bí mật được tạo ra thông qua:

chức năng tạoKey (cụm mật khẩu) {
  const muối = CryptoJS.lib.WordArray.random(128/8);
  const key256Bits = CryptoJS.PBKDF2(cụm mật khẩu, muối, {
    Kích thước phím: 256/32,
    lặp lại: RandomNumber,
  });

  trả lại khóa256Bits;
}

Tôi chưa quen với điều này và tự hỏi mức độ an toàn của 256keybit ở trên là bao nhiêu?

Ai đó có thể sử dụng vũ lực để tìm ra chuỗi mã hóa hex, base64 của 256keybits, iv mà không cần quan tâm đến cụm mật khẩu không.

Sau đó, chuyển đổi 256keybits thực, iv được sử dụng để giải mã realData trong mã hóa AES? Hoặc 256keybits có thể là lực lượng vũ phu?

Cảm ơn!

327
1 + 0
aes
Điểm:1
fgrieu avatar Crypto
lá cờ ng
fgrieu

giá trị cho lặp lại: RandomNumber không phải là một số ngẫu nhiên. Đó là số lần lặp kiểm soát chi phí của PBKDF2. Nó được cho là được đặt ở mức cao nhất có thể chấp nhận được trong ứng dụng và khả năng bảo vệ mà PBKDF2 cung cấp để chống lại việc tìm kiếm mật khẩu tăng lên một cách tuyến tính với tham số đó. Sau đây tôi giả sử cao lặp đi lặp lại (giả sử đường cơ sở là một trăm nghìn), và điều đó Muối được lưu trữ bằng cách nào đó. Tôi cũng cho rằng nó được sử dụng HMAC-SHA-1 (mặc định) hoặc HMAC-SHA-256 (cũng phổ biến).

Theo những gì chúng tôi biết, điểm yếu chính trong những gì được mô tả là có thể kiểm tra cụm mật khẩu bằng cách chạy generateKey, sau đó kiểm tra khóa tương ứng bằng cách sử dụng mật mã AES đã biết. đó là "không quan tâm đến cụm mật khẩu"? Điều đó không rõ ràng với tôi.

Vấn đề là, PBKDF2 có thể được chạy ở tốc độ rất cao bởi những kẻ tấn công sử dụng GPU, FPGA hoặc ASIC. Khi nào lặp đi lặp lại cao (như lẽ ra), PBKDF2 là nút cổ chai của Tạo khóa và tìm kiếm mật khẩu. Vì vậy, các đối thủ có thể tìm kiếm các mật khẩu có độ lớn nhanh hơn so với người dùng bình thường sử dụng CryptoJS. Từ quan điểm làm cho việc tìm kiếm mật khẩu trở nên khó khăn, đó là mục tiêu chính của câu hỏi, PBKDF2 do đó là một trong những cách sử dụng năng lượng CPU dự phòng tồi tệ nhất có thể cho kéo dài phím khi gặp đối thủ mạnh. Nhiều tùy chọn tốt hơn argon2, scrypt, hoặc thậm chí là bcrypt.

Bạn quyết định xem có phải ngẫu nhiên mà NIST PBKDF2 được đề xuất trước đây, và vẫn không bắt buộc sử dụng một cái gì đó tốt hơn; giống như nó trước đây đã đẩy Kép_EC_DRBG, với mục đích rõ ràng là cho phép tình báo Hoa Kỳ phá vỡ loại tiền điện tử này. Dao cạo của Hanlon có thể áp dụng, nhưng tôi đánh giá cao hơn các nhà khoa học NIST.

0 + 5
Kim Mỹ avatar
lá cờ cn
Kim Mỹ
"không quan tâm đến cụm mật khẩu"? Ý tôi là, pha mật khẩu được chuyển vào generateKey(passphrase) có thể chứa các ký tự đặc biệt để làm cho nó trở nên mạnh mẽ đối với lực lượng vũ phu. Trong khi khóa được trả về từ generateKey(passphrase) mà tôi có thể sử dụng để mã hóa và giải mã realData trong CryptoJS.AES.encrypt(realData, generateKey(passphrase), {iv: iv}) là mảng byte. Vì byte là mới đối với tôi nên tôi không biết liệu điều đó có khó để phá vỡ và đưa trở lại giải mã làm khóa hay không.
0
Hồi đáp
Kim Mỹ avatar
lá cờ cn
Kim Mỹ
Ngoài ra, chuỗi mã hóa có thể đọc được (Hex, Base64) của generateKey (cụm mật khẩu) (trong Crypto-JS tôi chỉ có thể sử dụng key256Bits.toString()) không chứa bất kỳ ký tự đặc biệt nào nếu hex hoặc chỉ '/,+' và kết thúc lạ hơn ' ==' nếu cơ sở64. Và điều đó có dễ dàng đối với lực lượng vũ phu sau đó chuyển đổi trở lại mảng byte (khóa được trả về từ generateKey (cụm mật khẩu)) sau đó đưa vào giải mã realData không? Xin lỗi điều này là mới đối với tôi và sửa tôi nếu tôi sai. Cảm ơn!
0
Hồi đáp
Kim Mỹ avatar
lá cờ cn
Kim Mỹ
trong thư viện Crypto-JS, cung cấp chuỗi mã hóa có thể đọc được (Hex, Base64) của generateKey (cụm mật khẩu), tôi chỉ có thể sử dụng CryptoJS.enc.Hex.parse() để lấy 256keybit thực và giải mã realData mà không cần quan tâm đến cụm mật khẩu được chuyển vào generateKey(cụm mật khẩu) để tạo khóa giải mã?
0
Hồi đáp
fgrieu avatar
lá cờ ng
fgrieu
Không dễ dàng cưỡng bức một khóa 256 bit được biểu thị dưới dạng chuỗi Base64 gồm 43 ký tự so với cưỡng bức thô tương đương 32 byte. Và điều đó về cơ bản là không thể. Mã hóa chính xác đầu ra của PBKDF2 để tạo khóa AES với tất cả 256 bit là một chi tiết quan trọng. Tôi cho rằng nó không đúng. Đó là một vấn đề lập trình, phụ thuộc nhiều vào CryptoJS, do đó khá lạc đề. Tôi đã không thảo luận về nó.
1
Hồi đáp
dave_thompson_085 avatar
lá cờ cn
dave_thompson_085
(@KimMỹ+) crypto-js.PBKDF2 trả về _WordArray_ là loại 'đối tượng' javascript chứa _ byte (nhưng không phải là Unit8Array dựng sẵn của javascript); nếu bạn chuyển đổi chuỗi này thành chuỗi (ví dụ:bởi console.log) kết quả đó được mã hóa trong base64 nhưng nếu bạn chuyển nó làm khóa cho một phiên bản crypto-js.Cipher sử dụng các byte trong đó, trong khi nếu bạn chuyển _string_ (dựng sẵn) cho một phiên bản như vậy thì nó sẽ áp dụng một PBKDF do OpenSSL xác định và khá kém (EVP_BytesToKey với niter=1) và theo mặc định cũng sử dụng định dạng do OpenSSL xác định với `Salted__`+8byte được thêm vào trước bản mã và được mã hóa trong base64.
1
Hồi đáp
lá cờ VietNam
Phan Văn Trường
Câu hỏi này là trong các ngôn ngữ khác:

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.