Tại sao hầu hết thời gian có một chút không khớp trong các khóa riêng X25519 tùy thuộc vào các chức năng được sử dụng, nhưng các khóa chung luôn khớp (cùng một hạt giống cho cả hai)?

Tôi đang cố gắng xoay sở để đi từ một hạt giống đến một Ký chính, và cũng có được một Khóa riêng (khóa mã hóa). Tôi đang sử dụng NaCl/libsodium.

Tôi đã tạo mã bên dưới và kết quả thật thú vị. hóa ra pk1.private_key và pk2.private_key phù hợp với khoảng 3% thời gian. Tuy nhiên, khóa công khai khớp 100%, tất cả đều được tạo bắt đầu bằng cùng một khóa hạt giống. Chuyện gì đang xảy ra ở đây?

• tôi có được pk1 bằng cách sử dụng PrivateKey.from_seed(hạt giống)

• tôi có được pk2 bằng cách sử dụng SigningKey(seed).to_curve25519_private_key()

Ví dụ về sự không phù hợp (chúng gần giống nhau nhưng không bằng nhau):

# byte đầu tiên không khớp bởi 0x01
hạt giống: f8d9e54a23971beebf2552c1a50ade6150cd051321398394f515e8d4b1ba0404
priv1: c1fd4612ee8ef24d295210a277e196e6bb4a9ae6b93f98d93f197860fe5dc048
priv2: c0fd4612ee8ef24d295210a277e196e6bb4a9ae6b93f98d93f197860fe5dc048

# byte đầu tiên không khớp bởi 0x03
hạt giống: d612a66f92ee2f42ab1f7ea9a712a47c815843d21fc988b1d202459f235b6410
priv1: f33d5e80bb556333e2961c9868b1dc7e548836ee56808689ca022f1a19fe86bb
priv2: f03d5e80bb556333e2961c9868b1dc7e548836ee56808689ca022f1a19fe867b

# Byte đầu tiên không khớp với 0x01, byte cuối cùng không khớp với 0x40
hạt giống: 10b7e1c66cf08005a22289158a088e028160f892dc6c20d43025be4690aaed85
priv1: 194898f65d117579d50e80a9b7e07bd048bfd1300d55561dac9dfaed4ef02109
priv2: 184898f65d117579d50e80a9b7e07bd048bfd1300d55561dac9dfaed4ef02149

từ nacl.signing nhập SigningKey
từ nacl.public nhập PrivateKey, PublicKey, Box, SealedBox
từ nacl.bindings nhập crypto_sign_SEEDBYTES
từ nacl.utils nhập StringFixer, ngẫu nhiên

chạy def (gỡ lỗi = Sai):
    hạt giống = ngẫu nhiên (crypto_sign_SEEDBYTES)
    pk1 = PrivateKey.from_seed(hạt giống)
    pk2 = SigningKey(seed).to_curve25519_private_key()
    nếu gỡ lỗi:
        in('hạt giống: ', hạt giống.hex()) 
        in('priv1: ', pk1._private_key.hex())
        in('priv2: ', pk2._private_key.hex())
        in('pub1: ', byte(pk1.public_key).hex())
        in('pub2: ', byte(pk2.public_key).hex())
    trả lại hạt giống, pk1, pk2

chạy = 10000
private_key_match = 0
public_key_match = 0
both_match = 0

cho tôi trong phạm vi (chạy):
    nếu tôi % 500 == 0:
        in(i, 'của', chạy)
    hạt giống, pk1, pk2 = chạy()
    x = pk1._private_key == pk2._private_key
    y = byte(pk1.public_key) == byte(pk2.public_key)
    nếu x:
        private_key_match += 1
    nếu bạn:
        public_key_match += 1
    nếu x và y:
        both_match += 1

print('khớp khóa cá nhân:', private_key_match)
print('khớp khóa công khai: ', public_key_match)
print('cả hai khớp: ', both_match)

'curve25519' (ban đầu Bernstein gọi nó, bây giờ được đổi tên thành X25519 hoặc XDH25519 cho rõ ràng vì giống nhau đường cong ở dạng khác được sử dụng cho Ed25519[ph]) yêu cầu khóa riêng (hệ số nhân) phải là bội số của 8 để tránh các cuộc tấn công của nhóm con nhỏ và theo quy ước được biểu diễn bằng little-endian nên 3 bit thấp của byte đầu tiên buộc phải 0.

X25519 cũng yêu cầu bit cao bằng 0 (vì trường cơ bản của nó chỉ khoảng $2^{255}$) và Bernstein chỉ định bit tiếp theo đến cao là 1 (để chặn 'tối ưu hóa' cho phép tấn công theo thời gian); những điều này ảnh hưởng đến Cuối cùng byte ở dạng little-endian mà dường như bạn không nhận thấy trong các ví dụ của mình cũng thay đổi bb - 7b và 09 - 49.

Hai (hoặc ba) kẹp này được thực hiện cùng nhau sẽ thay đổi tất cả giá trị được chọn ngẫu nhiên trừ (100/32)% thời gian, đủ gần 3% cho công việc của chính phủ.

Ed25519 thực sự có cùng nhu cầu về số nhân riêng của nó là bội số của 8, nhưng nó không sử dụng khóa riêng trực tiếp cho số nhân; thay vào đó, nó chạy khóa riêng thông qua hàm băm để mở rộng và sử dụng cho cả hệ số và giá trị bí mật làm mù thông báo và chỉ kẹp bên trong phần hệ số mà không sửa đổi những gì người dùng coi là khóa riêng.

bịp bợm Tại sao 3 bit thấp hơn của khóa bí mật Curve25519/ed25519 bị xóa trong quá trình tạo?
và Cấu trúc phím Curve25519
và xem/so sánh https://datatracker.ietf.org/doc/html/rfc7748#page-8
so với https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.5 .