Cách chúng tôi bảo vệ trước hai cuộc tấn công vào mật mã cơ bản của tBTC — nhanh chóng, lặng lẽ và không có kịch tính.

TL;DR:

Gần đây, hai cuộc tấn công chống lại giao thức GG18 và nhiều cách triển khai đã được tiết lộ công khai – BitForge của nhóm Fireblocks và TSShock của Verichains.

tBTC vẫn an toàn.

Chúng tôi vui mừng thông báo rằng nhờ có sự tiết lộ có trách nhiệm từ Fireblocks và mã hóa phòng thủ của nhóm phát triển của chúng tôi, cả hai lỗ hổng này đã được giảm thiểu trong tBTC kể từ tháng 6, nhiều tháng trước các dự án khác trên khắp không gian và rất lâu trước khi được tiết lộ công khai. Là một phần của trải nghiệm này, chúng tôi đã quyết định vận chuyển và duy trì một giải pháp thay thế cho Binance

tss-lib

.

Tiết lộ BitForge

Vào ngày 10 tháng 5 năm 2023, chúng tôi nhận được báo cáo cũ về lỗ hổng bảo mật từ một nhà nghiên cứu bảo mật thân thiện. Báo cáo về lỗ hổng được cho là có nguồn gốc từ nhóm Fireblocks và trong khi chúng tôi liên hệ với họ để xác nhận, tính xác thực của nó đã được Dan Boneh tại A16z xác minh.

Báo cáo fireblocks 2023 05 10 fireblocks-report-2023-05-10.pdf 154 KB vòng tròn tải xuống Tìm hiểu Báo cáo

Để hiểu BitForge có thể tác động đến tBTC như thế nào, cần hiểu rõ về tBTC.

tBTC là cầu nối Bitcoin phi tập trung dựa vào các nhà khai thác khách hàng được chọn ngẫu nhiên để quản lý bitcoin. Để các nhà khai thác thực hiện được điều đó, họ cần có khả năng tạo ví bitcoin dùng chung và ký các giao dịch bitcoin. Để tạo được chữ ký, nhóm đó cần phải có sự đồng thuận của 51 trên 100.

Việc tạo chữ ký mà không có thành viên nào học cách ký thay mặt cho cả nhóm rất phức tạp. Sơ đồ được sử dụng trong sản xuất tBTC ngày nay được mô tả trong GG18 và cách triển khai mà khách hàng chính sử dụng là của Binance.

tss-lib

.

Trong số các khối xây dựng khác, GG18 (và

tss-lib

) sử dụng hệ thống mật mã Paillier cho các thuộc tính đồng hình của nó [1]. Khi thiết lập hệ thống mật mã Paillier, mỗi người tham gia tạo hai số nguyên tố lớn (p, q) làm khóa riêng của họ và sau đó N = p • q làm khóa chung của họ.[2]

Lỗ hổng BitForge xoay quanh những gì xảy ra khi người ký độc hại có thể sử dụng mô-đun

N = Small_Prime_1 • small_prime_2 • ... • small_prime_16 • q

và không ai trong số những người tham gia khác kiểm tra.

Trong tBTC, việc khai thác thành công lỗ hổng BitForge có thể lấy cắp tài liệu quan trọng, dẫn đến mất tiền. Để làm được điều đó, một cuộc tấn công sẽ yêu cầu

  • Một cuộc tấn công trung gian thành công chống lại giao tiếp của người ký - khó có thể xảy ra nếu xét đến lớp mạng đã được củng cố của chúng tôi.

  • Một kẻ đặt cọc T độc hại hiện có biết về lỗ hổng bảo mật và đủ số tiền đặt cược T để được chọn làm ví.

Giảm thiểu ngay lập tức

Bây giờ chúng tôi đã hiểu được lỗ hổng bảo mật, chúng tôi có thể thực hiện ngay hai hành động để giảm thiểu mối đe dọa.

Đầu tiên, chúng tôi tạm dừng nhịp tim của ví. tBTC dựa vào chữ ký định kỳ từ ví ("nhịp tim") để chứng minh tính sống động của người ký. Vì BitForge nhắm mục tiêu vào giao thức ký và vì tBTC chưa hỗ trợ quy đổi vào tháng 5 nên việc vô hiệu hóa nhịp tim có nghĩa là lỗ hổng này không thể bị khai thác thêm, ngay cả bởi người ký độc hại đã được gán cho ví BTC.

Thứ hai, chúng tôi đã làm việc với ban quản trị để vô hiệu hóa việc tạo ví mới. Vì tBTC v2 ra mắt với hạn chế dành cho người đặt cược beta nên chúng tôi biết khả năng xảy ra người ký độc hại là rất thấp. Tuy nhiên, động thái này còn đảm bảo hơn nữa người ký mới biết về lỗ hổng này không thể xâm nhập vào ví mới.

Cả hai biện pháp này đều được thực thi vào ngày 11 tháng 5 năm 2023. Không có chữ ký hoặc DKG, không có đường dẫn mã trong

tss-lib

có thể được kích hoạt trên mainnet. Tại thời điểm này, chưa đầy 24 giờ kể từ khi ứng phó sự cố, chúng tôi đã có được điều mà mọi kỹ sư bảo mật có thể hy vọng vào việc chủ động giảm thiểu lỗ hổng bảo mật — thời gian.

Chúng tôi đã cân nhắc hai kế hoạch tấn công.

"Người lớn"

Chúng tôi gọi kế hoạch giảm thiểu đầu tiên đang được xem xét là "Kế hoạch lớn". Đúng như tên gọi, nó bao gồm các biện pháp quyết liệt.

Trước tiên, chúng ta cần triển khai một giải pháp thay thế cho

tss-lib

và GG18 không gặp phải lỗ hổng BitForge. Chúng tôi đã lên kế hoạch cung cấp hỗ trợ cho chữ ký Schnorr dưới dạng nâng cấp hiệu suất.

Nếu bạn không quen với chữ ký Schnorr, hãy coi chúng như một bản nâng cấp lớn cho sơ đồ chữ ký ECDSA được sử dụng rộng rãi trên Bitcoin và Ethereum ngày nay. Chữ ký Schnorr đơn giản hóa đáng kể việc xây dựng ngưỡng mà không cần giả định bổ sung về chữ ký BLS... nhưng quan trọng nhất là chúng được hỗ trợ trên Bitcoin ngày nay!

Sự bổ sung này có nghĩa là một bản cập nhật phiên bản chính cho

giữ cốt lõi

Ứng dụng khách P2P hỗ trợ tBTC – một điều khó thực hiện một cách lặng lẽ. May mắn thay, nó đã nằm trong lộ trình của chúng tôi nên việc vận chuyển nó sẽ không gây nghi ngờ về một lỗ hổng chưa được tiết lộ.

Bước cuối cùng trong kế hoạch này sẽ yêu cầu luân chuyển tất cả các ví BTC trong hệ thống: có thể thực hiện được nhưng chậm, đòi hỏi nỗ lực phối hợp trên toàn cộng đồng.

"Vá Paillier"

Kế hoạch giảm thiểu thứ hai, được gọi là "Vá Paillier", sẽ cố gắng khắc phục sự cố tại chỗ.

Đầu tiên, chúng tôi sẽ gửi bản sửa lỗi phía máy khách để ngăn chặn các số nguyên tố nhỏ vô tình được tạo ra. Mặc dù điều này không bảo vệ được một client được xây dựng độc hại nhưng nó sẽ tránh được

Sau đó, chúng tôi sẽ gửi một biện pháp giảm thiểu đầy đủ chống lại BitForge, sử dụng bằng chứng Paillier ZK "không nhỏ" được tìm thấy trong giao thức ECDSA ngưỡng CGGMP21.

Sau khi thảo luận, rõ ràng kế hoạch này là sự lựa chọn thận trọng hơn; và hóa ra, chúng tôi đã triển khai hầu hết các bằng chứng cần thiết trong nỗ lực nghiên cứu trước đó.

Chúng tôi bắt đầu triển khai các bằng chứng ZK cho bản phát hành dành cho khách hàng cá nhân.

Chứng minh sự trung thực của người vận hành

Trong khi triển khai bản vá đầy đủ, chúng tôi cũng bắt đầu xác nhận những phát hiện của mình cho đến nay.

Chúng tôi biết rằng không có nhà khai thác mới nào có thể tấn công tBTC... nhưng còn các nhà khai thác hiện tại thì sao? Nếu chi tiết về lỗ hổng BitForge bị rò rỉ, liệu các nhà khai thác có thể gây nguy hiểm cho tiền không?

Tại thời điểm tiết lộ, tBTC có 4 ví, mỗi ví có 100 thành viên. Nếu chúng tôi có thể chứng minh rằng không có yếu tố nhỏ nào được sử dụng khi những chiếc ví đó được tạo ra thì ngoài sự nghi ngờ hợp lý, chúng tôi có thể tránh được việc luân chuyển ví và tự tin hơn nhiều vào sự an toàn của hệ thống.

Mỗi thành viên của mỗi ví có mô-đun Paillier. Chúng tôi đã sử dụng vũ lực.

Tiết lộ ban đầu không cụ thể về cách thức hoạt động của cuộc tấn công, nhưng có viết:

Nguồn gốc của lỗ hổng là do các bên không kiểm tra xem mô đun Paillier, ký hiệu là N, có thừa số nhỏ hay không (một số nguyên tố có kích thước nhỏ hơn 2 100 được coi là nhỏ) hay nó là một lưỡng nguyên tố (vì vậy nó là tích của chính xác hai số nguyên tố)

Phiên bản khó phát hiện nhất của cuộc tấn công liên quan đến tBTC là khi kẻ tấn công sử dụng một hệ số nhỏ theo thứ tự 2100 và một hệ số khác theo thứ tự 21948. Mô-đun càng có nhiều hệ số thì càng dễ phân tích nó. Hệ số nào càng nhỏ thì càng dễ phân tích thành hệ số đó. Chúng tôi đã chuẩn bị cho điều tồi tệ nhất và hy vọng điều tốt nhất!

Đầu tiên, chúng tôi tạo ra một bộ khóa độc hại. Thư viện python libnum rất tốt cho việc này:

nhập bit libnum = 100 Total_bits = 2048 q = libnum.generate_prime(bits) p = libnum.generate_prime(total_bits - bit) N = p * q print(p, q, N)

Điều này tạo ra các mô-đun 2048 bit được tạo ngẫu nhiên với một hệ số nhỏ (~2^100) và một hệ số lớn (~2^1948).

Sau đó, chúng tôi đánh giá khoảng thời gian cần thiết để phân tích các yếu tố này bằng cách sử dụng Symy.ntheory.factort:

nhập thời gian từsympy.ntheory nhập yếu tố bắt đầu = time.time() các yếu tố = yếu tố(N) end = time.time() print(các yếu tố, str(kết thúc - bắt đầu))

Tất cả các bài kiểm tra đều được tính đến! Dưới đây là số liệu thống kê:

N. 64 phút 4016,88 q1 35906,3 trung vị 65896,9 q3 123775 tối đa 453262 trung bình 105729 stddev 107148 stderr 13393.6

Đến ngày 12 tháng 5 năm 2023, hai ngày sau khi tích cực giảm thiểu, chúng tôi xác nhận rằng không có số nguyên tố nào dưới 50 bit sử dụng máy tính xách tay của chúng tôi... và chuẩn bị cho quy trình phân tích nhân tố dài hơn trên đám mây.

Sau đó, chúng tôi tạo ra các giọt nước kỹ thuật số được tối ưu hóa cho CPU 8x48 lõi và lõi 1x16, để có tổng số 400 lõi.

yếu tố

chạy đơn luồng (và là thư viện bao thanh toán nhanh nhất mà chúng tôi tìm thấy); mỗi hộp được cấp một số để tính hệ số trên mỗi lõi.

nhập sys từ Symy.ntheory nhập yếu tố nhập thời gian nhập json N = int(sys.argv[1], 16) start = time.time() các yếu tố = yếu tố(N) end = time.time() file = open(f '{sys.argv[2]}.txt', "w") file.writelines([json.dumps(factors), "\n", str(end - start)]) file.close()

Chúng tôi phân phối các mô-đun giữa các máy và sau đó bắt đầu tính toán.

python3 yếu tố.py <moduli1> 1 & từ chối python3 yếu tố.py <moduli2> 2 & từ chối ... python3 yếu tố.py <moduli48> 48 & từ chối

Chúng tôi đã kiểm tra kỹ để đảm bảo rằng chúng tôi có 48 lõi trên mỗi máy đang chạy ở mức sử dụng 100%, sau đó kiểm tra định kỳ để đảm bảo không có lỗi nào xảy ra.

Chúng tôi đã chạy các máy từ 2023-05-15T16:01Z cho đến 2023-05-22T19:21Z, tức là 7 ngày, 3 giờ, 20 phút hoặc tổng cộng 616.800 giây. Không ai trong số 400 chủ đề tìm thấy bất kỳ yếu tố nào.

Đây là ~4,8 độ lệch chuẩn trên mức trung bình và dài hơn 36% so với nỗ lực phân tích nhân tố dài nhất mà chúng tôi thấy, điều này giúp chúng tôi tin tưởng rằng chúng tôi đã cố gắng phân tích nhân tố đủ lâu.

Để có một yếu tố nhỏ, kẻ tấn công cần phải có:

  • Đã phát hiện ra cuộc tấn công trước cả các nhà nghiên cứu bảo mật.

  • Đã sửa đổi ứng dụng khách trước khi ví được hình thành. Ví gần đây nhất được đăng ký vào ngày 19/04/2023.

  • Bằng cách nào đó đã tránh được việc hệ số nhỏ của chúng bị phát hiện bởi thuật toán trên.

Kết hợp tất cả những điều này lại, chúng tôi biết rằng không có chìa khóa nào gặp nguy hiểm trước cuộc tấn công tiềm ẩn này.

Một bản vá đầy đủ

Bài viết CGGMP21 cũng sử dụng hệ thống mật mã Paillier. Sự khác biệt là trong quá trình tạo khóa, giao thức khiến mỗi người tham gia phải chứng minh bằng không rằng

  • Mô đun của chúng không chứa các yếu tố nhỏ. p66.

  • Mô đun của chúng là mô đun Paillier-Blum. p36.

  • Các tham số Ring-Pedersen của chúng được định dạng tốt. p37.

Đến ngày 16 tháng 5 năm 2023, chúng tôi đã có nguyên mẫu của tất cả các bằng chứng và bắt đầu đánh giá nội bộ.

Vào ngày 5 tháng 6, chúng tôi đã tạo một bản fork riêng và sau đó lặng lẽ xây dựng + vận chuyển tệp nhị phân của máy khách bằng phiên bản tùy chỉnh, riêng tư của

tss-lib

để thực hiện các chứng minh trên.

Bởi vì chúng tôi đã lên kế hoạch phát hành ứng dụng khách lớn để kích hoạt tính năng quét mới, nên chúng tôi có thể âm thầm đưa bản vá vào — mà không tiết lộ lỗ hổng hoặc cảnh báo bất kỳ tin tặc nào có thể là tin tặc.

Vào ngày 6 tháng 6, Trail of Bits bắt đầu xác minh bản vá của chúng tôi và vào ngày 7 tháng 6, chúng tôi đã khắc phục tất cả các phát hiện. [3]

Luận văn tss-lib Báo cáo tóm tắt về khắc phục BitForge Luận văn tss-lib Báo cáo tóm tắt về khắc phục BitForge.pdf 772 KB vòng tròn tải xuống TSShock Disclosure

Vào ngày 14 tháng 7, chúng tôi nhận được một báo cáo khác về một vấn đề nghiêm trọng, lần này là từ nhóm Verichains thông qua ImmuneFi. Điều đáng lo ngại nhất là nhóm đã đưa vào một bằng chứng khái niệm mà họ tuyên bố đã chứng minh được khả năng trích xuất khóa từ

giữ cốt lõi

khách hàng.

Tuy nhiên, khi tìm hiểu sâu hơn, chúng tôi nhận ra rằng PoC của nhóm Verichains dựa trên phiên bản cũ hơn của ứng dụng khách,

v2.0.0-m3

— không phải bản beta phát hành dành cho khách hàng cá nhân mà các nhà đầu tư đã sử dụng.

Đến ngày 18 tháng 7, chúng tôi xác nhận rằng ứng dụng khách được vá riêng từ biện pháp giảm thiểu BitForge cũng giúp tBTC an toàn trước lỗ hổng mới, được đặt tên là TSShock và cuộc tấn công không thể xảy ra trên mạng chính.

Làm sao? Trong khi thực hiện biện pháp giảm nhẹ BitForge, chúng tôi đã phát hiện ra sự cố xung đột băm đằng sau TSShock đã được sửa công khai và đưa nó vào ứng dụng khách được vá riêng tư. Chúng tôi đánh giá cao tiết lộ từ Verichains và hài lòng với kết quả.

Đồ ăn mang về

Việc tiết lộ có trách nhiệm là khó khăn

Như mọi khi, một trong những phần khó nhất của việc tiết lộ có trách nhiệm thường là tìm đúng người để nói chuyện.

Trong vài ngày qua, tôi đã làm việc với một nhóm mũ trắng, kiểm toán viên và các nhà lãnh đạo an ninh khác để cố gắng giải quyết phần khó nhất của việc tiết lộ có trách nhiệm: tìm đúng người để nói chuyện. pic.twitter.com/pPjt7D51ZE

- @samczsun.com (@samczsun) Ngày 7 tháng 8 năm 2023

Ở đây, chúng tôi thật may mắn khi nhận được thông tin tiết lộ về BitForge sớm như vậy — nhiều bên trung gian đã tham gia trước khi chúng tôi liên hệ với nhóm Fireblocks.

Không rõ bằng cách nào chúng tôi có thể làm tốt hơn ở đây... các kho lưu trữ liên quan có quy trình tiết lộ được công bố, chúng tôi có chương trình tiền thưởng ImmuneFi, chúng tôi phản hồi nhanh chóng các email qua

security@threshold.network

và chúng tôi tuân theo tiêu chuẩn security.txt.

Mặt khác, chúng tôi gặp một số vấn đề khi xác minh rằng sự cố mà ThorChain gặp phải vào ngày 16 tháng 8 trên thực tế là TSShock — chứ không phải một lỗ hổng mới. Tôi không thể xác nhận điều đó, mặc dù đã liên hệ trên Twitter, thông qua danh bạ Telegram được chia sẻ, v.v.

Chúng tôi cần tìm ra cách phối hợp tốt hơn trong toàn ngành, đặc biệt là giữa các dự án có sự phụ thuộc chung quan trọng như

tss-lib

.

Ở đâu có khói, ở đó có lửa.

Binance

tss-lib

đã có một số vấn đề trong những năm qua. Nó không được cập nhật thường xuyên, phạm vi thử nghiệm không lớn và hầu hết các cải tiến về mã trong vài năm qua đều nhằm đáp lại các tiết lộ.

Chúng tôi biết, bởi vì bản thân chúng tôi là một trong những người đóng góp thường xuyên hơn.

Sau BitForge và TSShock, chúng tôi không còn tự tin vào thượng nguồn

tss-lib

kho lưu trữ, bao gồm cả việc giảm thiểu thích hợp các vấn đề này.

Thay vào đó, chúng tôi khuyên bạn nên tất cả

tss-lib

người dùng nên cân nhắc sử dụng fork của chúng tôi, hiện là nguồn mở.

Công việc tương lai

Trên hết các vấn đề với

tss-lib

... dòng giao thức ngưỡng GG18 cũng có một số lỗ hổng trong những năm qua. Và mặc dù tất cả mật mã đều phải trải qua thử thách của thời gian, nơi nào có khói, thường có lửa — và nếu có thể tránh được rủi ro thì chúng ta nên làm như vậy.

Nhiều dự án cần ngưỡng ECDSA và đối với những dự án đó, chúng tôi khuyên bạn nên nâng cấp lên CGGMP21.

May mắn thay, chúng ta có một giải pháp thay thế mạnh mẽ hơn. Kể từ ngày 14 tháng 11 năm 2021, Bitcoin đã kích hoạt sơ đồ chữ ký mới — Schnorr. Kể từ tháng 4, kế hoạch của chúng tôi là di chuyển tBTC sang chữ ký Schnorr, sử dụng ROAST/FROST và GJKR (RFC 10)  để tránh sự phức tạp khi triển khai ngưỡng ECDSA. Nhóm đã đồng ý khuyến nghị nên giữ nguyên chương trình beta staker cho đến khi quá trình di chuyển sang Schnorr diễn ra.

Mong đợi được nghe nhiều hơn về nỗ lực này vào cuối năm nay!

Sự nhìn nhận

Bảo mật phần mềm là một công việc lớn và việc giảm thiểu những lỗ hổng này phụ thuộc vào rất nhiều người.

Chúng tôi muốn cảm ơn...

  • Ari và nhóm tại Fireblocks vì những phát hiện của họ.

  • MacLane Wilkison, Tux và Dan Boneh vì sự giúp đỡ của họ trong việc xác minh thông tin tiết lộ.

  • Promethea Rashke vì công việc chuyển các bằng chứng từ CGGMP21 sang tss-lib, Beau Rancourt vì công việc của anh ấy trong việc phân tích các mô-đun Paillier hiện có, và Jakub Nowakowski, Piotr Dyraga và Lukasz Zimnoc vì công việc của họ trong việc điều phối phản hồi của chúng tôi và xem xét tất cả mã.

  • Tjaden Hess và Trail of Bits vì sự hỗ trợ và phản hồi của họ trong việc xác minh biện pháp giảm thiểu của chúng tôi.

  • Ngưỡng DAO cho khả năng phản hồi đáng kinh ngạc của họ.

Mốc thời gian

Đối với những người quan tâm, đây là dòng thời gian chi tiết hơn. Lưu ý rằng tất cả thời gian đều là UTC.

  • 2023-05-10 9:19 PM: Nhận bản tiết lộ lỗ hổng ban đầu.

  • 10-05-2023 9:53 CH: Phân phối công việc: Kuba tìm nạp các mô-đun Paillier hiện có để chúng tôi có thể kiểm tra, bắt đầu phân tích chúng. Promethea bắt đầu vá tss-lib. Beau bắt đầu viết mã bao thanh toán và điểm chuẩn. Piotr chuẩn bị một giao dịch quản trị tBTC để tạm dừng việc tạo ví mới.

  • 2023-05-11 12:06 AM: Kuba trích xuất và chia sẻ 400 mô-đun hiện có.

  • 11-05-2023 1:08 chiều: Piotr giao giao dịch để tạm dừng việc tạo ví mới cho quản trị.

  • 11-05-2023 7:45 CH: Promethea triển khai bản thảo thô của các bằng chứng cần thiết trong một nhánh riêng của tss-lib.

  • 12-05-2023 4:35 CH: Beau đã tạo thành công một lưỡng nguyên tố có kích thước phù hợp và bắt đầu thử phân tích nó.

  • 12-05-2023 7:15 CH: Beau sử dụng các số nguyên tố kép dễ phân tích hơn để đánh giá các thư viện phân tích khác nhau và nắm được quy mô hiệu suất. primefac hoạt động tốt nhất.

  • 15-05-2023 12:12 CH: Quản trị tBTC vô hiệu hóa việc tạo ví mới.

  • 15-05-2023 4:36 CH: Beau bắt đầu tính toán tất cả 400 mô-đun bằng cách sử dụng các giọt Digital Ocean được tối ưu hóa cho CPU.

  • 17-05-2023 2:49 PM: Promethea điều chỉnh bản vá tss-lib để tương thích ngược hoàn toàn với các máy khách keep.

  • 19-05-2023 1:58 CH: Promethea xác định các xung đột băm tiềm ẩn và bổ sung bản sửa lỗi.

  • 22-05-2023 7:21 CH: Beau tắt máy tính tiền. Không tìm thấy yếu tố nào.

  • 25-05-2023 5:01 CH: Piotr lên lịch kiểm tra Trail of Bits cho các thay đổi và tạo một nhánh tư vấn bảo mật mới của tss-lib để tạo điều kiện thuận lợi cho việc kiểm tra.

  • 2023-06-05 2:25 PM: Piotr lặng lẽ chèn các thay đổi vào bản phát hành keep-core v2.0.0-m3.

  • 06-06-2023 9:42 CH: tjade273 (Trail of Bits Auditor) hoàn thành bản vá bảo mật tss-lib đầu tiên của họ.

  • 07-06-2023 2:51 CH: Promethea xác định rằng Ntilde, (một mô-đun Paillier khác) cũng dễ bị tấn công và bản sửa lỗi cũng cần được áp dụng cho giao thức chia sẻ lại (chúng tôi không sử dụng tính năng chia sẻ lại; chúng tôi vẫn sửa nó).

  • 13-06-2023 2:34 CH: Promethea hoàn tất việc chia sẻ lại và sửa lỗi Ntilde.

  • 14-07-2023 10:11AM: Khám phá qua ImmuneFi rằng Verichains đã tìm thấy một cách khai thác liên quan đến các xung đột băm mà Promethea đã sửa.

  • 18-07-2023 3:04PM: Kuba xác nhận Verichains PoC không ảnh hưởng đến ứng dụng khách giữ lõi được vá riêng.

  • 20-07-2023 11:34 SA: Ship keep-core v2.0.0-m4 bao gồm bản sửa lỗi ntilde và chia sẻ lại.

  • 29-06-2023 10:49 CH: tjade273 hoàn tất kiểm tra việc chia sẻ lại và sửa lỗi Ntilde.

  • 16-08-2023 1:46 CH: Một dự án khác tweet về một lỗ hổng mới (chính là lỗ hổng đó). Chúng tôi tạm dừng tiết lộ thông tin này để điều tra.

[1]: Sơ đồ mã hóa đồng cấu là sơ đồ trong đó bạn có thể thực hiện phép toán trên văn bản được mã hóa và có thể giải mã nó sau này một cách chính xác. Đối với Paillier,

giải mã(mã hóa(tin nhắn1) • mã hóa(tin nhắn2)) == tin nhắn1 + tin nhắn2

.

[2]: Về mặt tính toán có thể dễ dàng xác minh rằng

N = p • q

nhưng khó có thể tìm ra p và q chỉ bằng N. Xem Hệ số nguyên. Số lớn nhất được tính thành nhân tử là RSA-250, một số có 250 chữ số thập phân, vào năm 2020. Tổng thời gian tính toán là khoảng 2700 năm tính toán lõi.

[3]: Các nhận xét đánh giá kéo đã bị mất khi tiết lộ bảo mật được hợp nhất. Chúng tôi đang làm việc với GitHub để khôi phục chúng. Trong khi chờ đợi, đây là một ảnh chụp màn hình:

Và đây là Bản tóm tắt cách khắc phục do Trail of Bits tổng hợp lại.

ruột thừa

N độc hại để đo điểm chuẩn

https://Gist.github.com/beaurancourt/c26f437baa62ebda45d069998273b053

Kết quả điểm chuẩn

Tính bằng giây, theo thứ tự chỉ số.

Kết quả về thời gian điểm chuẩn của lỗ hổng Kết quả về thời gian của điểm chuẩn về lỗ hổng. GitHub Gist: chia sẻ mã, ghi chú và đoạn trích ngay lập tức. Ý chính 262588213843476