Câu hỏi xem xét việc đệm văn bản dễ nhớ như "khóa mật mã" vào khóa AES bằng cách thêm byte 0 vào biểu thức (UTF-8) của văn bản này dưới dạng byte, cho đến khi đạt 16, 24 hoặc 32 byte cho AES-128, AES-192, hoặc AES-256.
Các chủ yếu vấn đề với điều này là nó nhanh và không tốn kém, đây là một thảm họa trong ngữ cảnh: nó cho phép kẻ thù áp dụng quy trình đó một cách nhanh chóng và không tốn kém cho các mật khẩu hợp lý, đồng thời kiểm tra các khóa thu được dựa trên bản mã (với bản rõ đã biết hoặc dự phòng đã biết), và do đó tìm ra khóa. Đây là bẻ khóa mật khẩuvà có một ngành công nghiệp nhỏ đang phát triển hỗn hợp phần mềm và phần cứng cho việc này.
Tôi nghĩ rằng một từ điển gồm một triệu từ tiếng Anh phổ biến nhất (đối với một số định nghĩa mở rộng của từ này) có chứa "mã hóa". Ít nhất, một tìm kiếm của Google đã tìm thấy 78.400 lần xuất hiện và nó nằm trong danh sách các miền đã đăng ký trong ba TLD phổ biến. Với một cặp bản rõ/bản mã đã biết hoặc bản mã cho một bản rõ có cấu trúc nào đó, việc này sẽ mất vài giây để phá vỡ đối với người có công cụ phù hợp.
Mặc dù điều đó có thể được cải thiện rất nhiều (xem đoạn tiếp theo), "cipherkey" không phải là một mật khẩu tốt. Bạn nên chọn một mật khẩu khó đoán hơn. Chỉ đơn thuần đặt tên cho điều đó cụm mật khẩu sẽ giúp! Nhưng đó là một thứ hai vấn đề.
Khi biến bất cứ thứ gì đáng nhớ (mật khẩu, cụm mật khẩu..) thành chìa khóa, một phải sử dụng hàm dẫn xuất khóa dành cho mật khẩu, đó là hàm có tham số workfactor cho phép điều chỉnh chi phí của dẫn xuất khóa. Nếu chi phí đó là 0,5 giây thời gian của một máy tính mạnh, thay vì 20 nano giây cho phương pháp được đề xuất, thì điều đó sẽ trở thành nút cổ chai cho việc bẻ khóa mật khẩu và có thể khiến họ ít nhất phải đổ mồ hôi. Với cụm mật khẩu à la XKCD hoặc xúc xắc, nó có thể khá an toàn.
Người ta nên sử dụng Muối, điều này sẽ ngăn việc tính toán trước các khóa dẫn xuất và ngăn việc khấu hao chi phí của các dẫn xuất đó đối với một số cặp mật khẩu/khóa. đó là một cái khác thứ hai vấn đề.
Điều quan trọng là chức năng dẫn xuất chính là bộ nhớ cứng, nghĩa là sử dụng một lượng lớn bộ nhớ trong suốt quá trình tính toán của nó, vì điều đó làm tăng đáng kể chi phí tấn công bằng tiền, với chi phí thấp cho người dùng hợp pháp. Các chức năng được khuyến nghị bao gồm Argon2 và mật mã. Các chức năng phổ biến nhưng không được đề xuất bao gồm PBKDF2, không khó về bộ nhớ và nằm trong số những cách sử dụng thời gian CPU tồi tệ nhất có thể cho mục đích lấy mật khẩu thành khóa: nó tối đa hóa lợi thế của những kẻ tấn công sử dụng ASIC, FPGA và thậm chí cả GPU w.r.t. người dùng hợp pháp sử dụng CPU. tôi tìm thấy Khuyến nghị của NIST cho PBKDF2 phù hợp với sự thúc đẩy trước đây của họ cho Kép_EC_DRBG:
Mặc dù PBKDF2 khó về thời gian nhưng không khó về bộ nhớ, nhưng nó được triển khai rộng rãi đến mức không thực tế (tại thời điểm này) để đưa ra yêu cầu cho chức năng dẫn xuất khóa cứng trong bộ nhớ.