Tham gia Đăng nhập
Điểm:0
randomname avatar Crypto

Làm cách nào tôi có thể xác định giá trị nhóm ECDHE được sử dụng trong phiên TLS

lá cờ us
randomname

Trong ECDHE, nhóm là một giá trị công khai. Tôi muốn nhận giá trị này cho một phiên. Tôi đã kiểm tra phiên bằng Wireshark. Trong ServerHello -> Key share extension -> Key share entry, tôi tìm thấy các thông số sau:

Mục chia sẻ khóa: Nhóm: x25519, Độ dài trao đổi khóa: 32
Nhóm: x25519 (29)
Độ dài trao đổi khóa: 32
Trao đổi khóa: 22d9....88e....635... (độ dài đầy đủ là 64 ký tự hex, 256 bit)

Bạn có thể giải thích thêm? Làm cách nào để giá trị Độ dài trao đổi khóa có thể là 32, nhưng nó là 256 bit và 64 ký tự hex?

100
0 + 0
kelalaka avatar
lá cờ in
kelalaka
Nó là 32 byte và đó là 64 ký tự hex. Các câu hỏi liên quan đến công cụ không có chủ đề ở đây.
1
Hồi đáp
randomname avatar
lá cờ us
randomname
@kelalaka Cảm ơn bạn! Bài đăng không phải là về công cụ. Nhưng giá trị nào từ đầu ra của công cụ đã đăng?
0
Hồi đáp
kelalaka avatar
lá cờ in
kelalaka
@knaccc đây là ký hiệu ECC; nó phải là $x([a]G)$. Đó là $x22519(a,9)$ trong ký hiệu RFC thực thi Thang Montgomery và chỉ trả về tọa độ đầu tiên. Tôi không chắc Wireshark thực sự thấy điều này như thế nào, tuy nhiên, có vẻ như họ bỏ qua mã hóa điểm cơ sở. Xem [rfc7748 6.1](https://datatracker.ietf.org/doc/html/rfc7748#section-6.1) và phần 5. Bạn có nghĩ rằng câu hỏi này thực sự có thể trả lời được không? TLS 1.3 nói rằng tuân theo rfc7748 trong đó mã hóa của $9$ cũng là 32 byte.
0
Hồi đáp
Maarten Bodewes avatar
lá cờ in
Maarten Bodewes
Vâng, khóa công khai luôn được nén cho x25519 này ở định dạng thô (chỉ là một số nguyên endian lớn có kích thước tĩnh). Kích thước của nó là 256 bit (ký hiệu tiền điện tử), 32 byte (trong giao thức) hoặc - chỉ dành cho người tiêu dùng - 64 ký tự hex.
1
Hồi đáp
Điểm:2
knaccc avatar Crypto
lá cờ es
knaccc

Bắt tay TLS 1.3 hoạt động như sau:

Máy khách sẽ gửi cấu trúc dữ liệu "ClientHello" đến máy chủ. Ở giai đoạn này, máy khách chưa biết máy chủ hỗ trợ "Nhóm" nào. Để tránh phải quay lại máy chủ, theo suy đoán, nó có thể chứa một "phần tử nhóm" cho nhóm mà nó muốn sử dụng. Trong trường hợp được hỏi, phần tử nhóm là khóa chung 32 byte để sử dụng với "Nhóm 29" (29 == hex 0x1d), là mã định danh TLS cho cái thường được gọi là X25519. Dưới đây là danh sách đánh số cho tất cả các nhóm được hỗ trợ TLS: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

X25519 nghĩa là trao đổi Diffie-Hellman sử dụng điểm cơ sở nổi tiếng G trên đường cong elip Curve25519, trong đó các phần tử nhóm nằm trong nhóm con tuần hoàn lớn chứa G trong đường cong này. Điểm G không cần phải được truyền đi, bởi vì nó được định nghĩa là một phần của Tiêu chuẩn X25519 và giống nhau đối với tất cả các lệnh của X25519.

Khóa công khai tạm thời của khách hàng là "phần tử nhóm" được gửi một cách suy đoán. Đối với X25519, nó dài 32 byte (64 ký tự hex hoặc 256 bit). Phần tử nhóm này được liệt kê dưới dạng giá trị "trao đổi khóa" trong phần "chia sẻ khóa" của cấu trúc dữ liệu ClientHello.

Máy chủ sẽ phản hồi bằng thông báo "ServerHello" nếu nó đồng ý sử dụng nhóm được bao gồm theo suy đoán của máy khách, ở đây là Nhóm 29. Điều này bao gồm thành phần nhóm của máy chủ trong giá trị "trao đổi khóa" trong phần "chia sẻ khóa".Phần tử nhóm này là khóa công khai tạm thời của máy chủ.

Với thông tin này, cả máy khách và máy chủ đều có thể tính toán cùng một bí mật được chia sẻ được gọi là "bí mật tiền chính". Điều này sau đó được kết hợp với dữ liệu ClientHello và ServerHello để lấy các khóa mã hóa đối xứng (xem https://datatracker.ietf.org/doc/html/rfc8446#section-7.1). Những điều này cho phép máy chủ và máy khách giao tiếp an toàn với nhau bằng cách sử dụng mã hóa được xác thực, chẳng hạn như AES-GCM.

Nếu máy chủ không đồng ý với nhóm được đề xuất của máy khách hoặc máy khách đã chọn không đề xuất bất kỳ nhóm nào, nhưng máy chủ đồng ý với một nhóm (khác) mà máy khách được liệt kê trong "các nhóm được hỗ trợ", thay vào đó, máy chủ sẽ gửi HelloRetryRequest để thông báo cho máy khách để thử lại ClientHello bằng cách sử dụng một nhóm được chỉ định, sau đó máy chủ sẽ chấp nhận như trên. Nếu máy chủ không đồng ý không tí nào nhóm mà máy khách hỗ trợ, nó sẽ gửi một cảnh báo lỗi và quá trình bắt tay không thành công -- trừ khi máy khách cũng đề xuất một PSK có sẵn, nhưng điều đó thường chỉ xảy ra khi tiếp tục và nếu quá trình bắt tay ban đầu không thành công thì không thể tiếp tục lại.

TLS 1.0-1.2 xử lý ECDHE theo cách khác - nếu có, bởi vì nó là tùy chọn. Trong các giao thức đó, bộ mật mã chỉ định trao đổi khóa và xác thực cũng như mật mã dữ liệu và hàm băm cho HMAC (nếu không phải là AEAD) và PRF (nếu là 1.2). Máy khách gửi các bộ mật mã liệt kê ClientHello mà nó hỗ trợ, bất kỳ, một số hoặc tất cả chúng có thể sử dụng ECDHE kết hợp với xác thực RSA hoặc ECDSA (tức là chứng chỉ), và tiện ích mở rộng nhóm được hỗ trợ (hoặc đường cong được hỗ trợ trước RFC7919) chỉ định các đường cong mà nó hỗ trợ. Nếu máy chủ đồng ý với bộ mật mã ECDHE được cung cấp và một đường cong được cung cấp, thì máy chủ sẽ gửi ServerHello chỉ định bộ mật mã, sau đó là chuỗi chứng chỉ của nó, sau đó là ServerKeyExchange chứa id đường cong và khóa công khai tạm thời của nó.Máy khách (nếu nó chấp nhận chứng chỉ) gửi ClientKeyExchange có chứa khóa công khai tạm thời của nó, sau đó quá trình tính toán bí mật dùng chung cũng diễn ra tương tự, mặc dù chi tiết về cách các khóa hoạt động được tạo ra khác với 1.3 và cả từ 1.2 trở về trước.

0 + 0
kelalaka avatar
lá cờ in
kelalaka
đây là ký hiệu ECC; nó phải là $x([a]G)$. Đó là $x22519(a,9)$ trong ký hiệu RFC thực thi Thang Montgomery và chỉ trả về tọa độ đầu tiên. Tôi không chắc Wireshark thực sự thấy điều này như thế nào, tuy nhiên, có vẻ như họ bỏ qua mã hóa điểm cơ sở. Xem [rfc7748 6.1](https://datatracker.ietf.org/doc/html/rfc7748#section-6.1) và phần 5. Bạn có nghĩ rằng câu hỏi này thực sự có thể trả lời được không? TLS 1.3 nói rằng tuân theo rfc7748 trong đó mã hóa của $9$ cũng là 32 byte.
0
Hồi đáp
knaccc avatar
lá cờ es
knaccc
@kelalaka hex "trao đổi khóa" trong ServerHello là khóa chung của máy chủ, là điểm cơ sở (tọa độ x của 9) nhân với khóa riêng của máy chủ hoặc X25519(server_private_key, 9) trong ký hiệu rfc7748.Không chắc ý của bạn là gì khi "bỏ qua mã hóa điểm cơ sở" - không bao giờ cần phải truyền điểm cơ sở 9, vì nó nổi tiếng là một phần của thông số kỹ thuật X25519.
0
Hồi đáp
kelalaka avatar
lá cờ in
kelalaka
Như tôi đã nói đơn giản dưới câu hỏi là về ánh xạ tiêu chuẩn vào WireShark mà không cung cấp thông tin về điểm cơ sở được mã hóa $9$. Tại sao họ hiển thị như thế này là tùy thuộc vào sự lựa chọn của nhà thiết kế.
0
Hồi đáp
knaccc avatar
lá cờ es
knaccc
@kelalaka Tôi nghĩ rằng chúng tôi đã giải thích câu hỏi theo cách khác. Tôi cho rằng vấn đề là người đăng đã nhầm lẫn về ý nghĩa của "nhóm", đặc biệt là vì nhóm có thể có nghĩa là "nhóm 29", có thể có nghĩa là thành phần nhóm là khóa chung của máy chủ hoặc có thể có nghĩa là nhóm của điểm cơ sở. Do đó, cách tiếp cận của tôi là chỉ giải thích tất cả các thuật ngữ.
0
Hồi đáp
Điểm:0
DannyNiu avatar Crypto
lá cờ vu
DannyNiu

Nhóm được sử dụng trong trao đổi khóa X25519, sử dụng Curve25519 của DJB (Daniel J. Bernstein).

Có một loạt các tiêu chuẩn thương mại được gọi là SEC#* (Tiêu chuẩn cho mật mã hiệu quả) chỉ định mật mã đường cong elip. Khóa công khai (điểm) trong các tiêu chuẩn này dài 2x+1 (tọa độ x-y không nén với byte tiêu đề) hoặc x+1 (tọa độ x nén với byte tiêu đề).

Ngoài ra còn có DJB và các đội của anh ấy nỗ lực tạo ra các đường cong hiệu quả và không có kênh phụ ngay bây giờ được biết như X25519 (đối với trao đổi khóa) và Ed25519 (đối với chữ ký số). Các khóa công khai cũng là các điểm, nhưng chúng được xác định trực tiếp theo mã hóa byte của tọa độ trong 1 chiều, do đó không cần byte tiêu đề.

Công cụ của bạn chỉ ra rằng đó là x25519, được tạo bởi DJB folks.

Bạn cũng có thể muốn biết rằng, có một loạt tiêu chuẩn khác được gọi là PKCS#* (Tiêu chuẩn mã hóa khóa công khai), tiêu chuẩn đầu tiên trong chuỗi quy định mã hóa RSA được sử dụng trên internet, (có các tiêu chuẩn RSA khác được sử dụng ở nơi khác) .

0 + 0
kelalaka avatar
lá cờ in
kelalaka
X25519 không sử dụng tọa độ $y$.
0
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.