constant-time-analysis

Tổng quan về skill constant-time-analysis

constant-time-analysis là một skill phục vụ kiểm toán bảo mật, giúp phát hiện rủi ro kênh bên timing trong mã crypto trước khi chúng trở thành lỗi có thể khai thác. Skill này phù hợp nhất cho kỹ sư, reviewer và AI agent đang kiểm tra xem các phép toán phụ thuộc vào secret, nhánh rẽ, so sánh hoặc lệnh thực thi có thể làm lộ key, token hay các giá trị nhạy cảm khác hay không.

Mục tiêu chính không phải là “hiểu lý thuyết crypto” mà là “nhận ra đoạn nào của code đã không còn chạy theo kiểu constant-time.” Vì vậy, constant-time-analysis hữu ích nhất trong các đợt review triển khai, kiểm tra bảo mật trước khi merge, và xử lý sự cố khi cần đánh giá một hàm có an toàn trước tấn công timing hay không.

Điểm khác biệt so với một prompt chung là skill này được xây dựng quanh output đã biên dịch và các đường phân tích theo từng ngôn ngữ, chứ không chỉ quét source. Điều này quan trọng vì lỗi constant-time thường lộ ra ở assembly, bytecode hoặc lệnh của VM, ngay cả khi source code trông hoàn toàn vô hại.

Phù hợp nhất để audit bảo mật với constant-time-analysis

Hãy dùng skill này khi bạn đang review code mà:

• xử lý secret, xác thực, hoặc các primitive mật mã
• dùng phép chia, modulo, so sánh, hoặc rẽ nhánh dựa trên giá trị suy ra từ secret
• cần xác minh trên cả artifact đã biên dịch, không chỉ dựa vào ý định trong source
• nhắm tới C, C++, Go, Rust, Swift, Java, Kotlin, PHP, JavaScript, TypeScript, Python, hoặc Ruby

Skill này bắt được gì và bỏ sót gì

constant-time-analysis rất mạnh với các mẫu rò rỉ timing như phép chia biến thiên theo dữ liệu, nhánh rẽ phụ thuộc secret, và các phép so sánh không an toàn. Tuy nhiên, nó yếu hơn khi xử lý các lỗi thiết kế crypto ở mức rộng hơn, lỗi giao thức, hoặc rò rỉ phát sinh từ mạng, cache, hay nhiễu môi trường — trừ khi những vấn đề đó xuất hiện ngay trong đường code được phân tích.

Vì sao người dùng cài skill này

Hãy cài skill này khi bạn muốn một quy trình review lặp lại được, có thể cảnh báo rủi ro timing sớm hơn so với việc đọc lướt thủ công. Nếu bạn chỉ cần một nhận định nhanh cho một đoạn code đơn lẻ, một prompt thường có thể đủ; nhưng nếu bạn cần hành vi review bảo mật nhất quán, skill này sẽ thêm cấu trúc rõ ràng.

Cách dùng skill constant-time-analysis

Cài đặt và kích hoạt đúng cách

Dùng đường dẫn cài đặt constant-time-analysis từ skill manager của bạn, sau đó chạy nó trong ngữ cảnh có ngôn ngữ mục tiêu và hàm hoặc file nhạy cảm. Một prompt kích hoạt tốt nên nêu rõ mục tiêu crypto, các input là secret, và ngôn ngữ/runtime để skill chọn đúng đường phân tích.

Ví dụ kích hoạt:

• “Review src/sign.rs for constant-time risk. Secret input is the private key scalar; focus on division, branches, and comparisons.”
• “Run constant-time-analysis on this PHP password-checking function and tell me whether any opcode-level timing leak is likely.”

Cung cấp đúng dạng đầu vào

Skill này hiệu quả nhất khi bạn cung cấp:

• file hoặc hàm cần kiểm tra
• giá trị nào là secret
• hành vi nào attacker có thể quan sát
• phiên bản ngôn ngữ và runtime mục tiêu, nếu biết

Đầu vào tốt hơn:

• “Audit verifyToken() in TypeScript. Token bytes are secret; compare against stored HMAC; check for Div, Mod, and early-exit comparisons.”
• “Analyze this Rust reduce() routine for secret-dependent division across x86_64 and arm64.”

Đọc các file này trước

Khi quyết định cài đặt và xác định workflow, hãy bắt đầu từ:

• SKILL.md cho trigger, phạm vi và cách chọn ngôn ngữ
• README.md cho các ngôn ngữ được hỗ trợ và mục tiêu đầu ra
• references/compiled.md cho C/C++, Go, và Rust
• references/javascript.md, references/python.md, references/php.md, references/ruby.md, references/swift.md, references/kotlin.md cho các quy tắc riêng của VM

Nếu bạn chỉ lướt một file tham chiếu, hãy chọn file khớp với đường chạy runtime của bạn thay vì chỉ nhìn vào nhãn ngôn ngữ source.

Dùng workflow review, không chỉ một lượt quét

Một quy trình sử dụng constant-time-analysis thực tế thường là:

1. xác định hàm có xử lý secret
2. chạy hướng dẫn phù hợp với ngôn ngữ
3. rà soát mọi phép chia, modulo, so sánh, nhánh rẽ, hoặc lời gọi helper đáng ngờ
4. chạy lại sau khi refactor hoặc thay đổi compiler/runtime
5. yêu cầu đầu ra thân thiện với CI nếu bạn muốn kết quả có thể kiểm tra tự động

Điều này quan trọng vì một sửa đổi ở source vẫn có thể được biên dịch thành lệnh không an toàn, đặc biệt trong các ngôn ngữ biên dịch.

Câu hỏi thường gặp về skill constant-time-analysis

constant-time-analysis chỉ dành cho cryptography thôi sao?

Không. Skill này dành cho bất kỳ code nào mà chênh lệch timing trên dữ liệu secret là vấn đề, nhưng thực tế thường rơi vào crypto, auth, xử lý key và xác minh token. Nếu code chỉ xử lý dữ liệu công khai, skill này có lẽ là không cần thiết.

Tôi có cần biết assembly hoặc bytecode không?

Không cần để bắt đầu. Skill này hữu ích chính vì nó chỉ bạn tới đúng artifact runtime và reference theo từng ngôn ngữ. Bạn không cần đọc từng lệnh, nhưng bạn phải biết hàm hoặc file nào là nhạy cảm về bảo mật.

constant-time-analysis có tốt hơn prompt thông thường không?

Có, khi bạn cần hành vi review bảo mật lặp lại được. Prompt thường có thể nhận ra rủi ro rõ ràng, nhưng constant-time-analysis hữu ích hơn cho công việc trong repository vì nó được tổ chức quanh việc chọn ngôn ngữ, output đã biên dịch, và các mẫu rò rỉ cụ thể.

Khi nào tôi không nên dùng nó?

Đừng dùng nó cho logic nghiệp vụ thông thường, code UI, hoặc biến đổi dữ liệu công khai. Cũng nên bỏ qua khi thư viện đã bảo đảm hành vi constant-time và bạn chỉ hỏi về cách dùng API cấp cao mà không có logic phụ thuộc secret viết thêm.

Cách cải thiện skill constant-time-analysis

Tập trung vào secret và mô hình attacker

Kết quả tốt nhất từ constant-time-analysis đến khi bạn nói rõ chính xác thứ gì phải giữ bí mật và attacker có thể quan sát được gì. Hãy nói rõ rủi ro là timing từ xa, timing ở tiến trình cục bộ, hay kiểm tra artifact đã biên dịch. Nếu không có thông tin đó, skill có thể quá tập trung vào các nhánh vô hại hoặc bỏ sót ràng buộc thực sự.

Chỉ đưa vào đường code rủi ro nhỏ nhất cần thiết

Hãy cung cấp đúng hàm thực sự chạm vào secret, không phải toàn bộ repository. Nếu đường đi có helper, chỉ cần đưa kèm khi chúng ảnh hưởng đến rẽ nhánh, số học, hoặc so sánh. Cách này giảm nhiễu và giúp output dễ hành động hơn.

Yêu cầu bằng chứng theo từng ngôn ngữ

Để có kết quả tốt nhất, hãy yêu cầu skill kiểm tra artifact runtime phù hợp:

• assembly cho C/C++, Go, Rust
• bytecode cho JavaScript, TypeScript, Python, Ruby, PHP
• hành vi JVM cho Kotlin

Cách này cải thiện việc dùng constant-time-analysis vì rò rỉ timing thường xuất hiện ở tầng thấp hơn source.

Chạy lại sau mỗi lần sửa

Một lỗi hay gặp là sửa source code rồi mặc định rằng rò rỉ đã biến mất. Hãy kiểm tra lại sau khi đổi thuật toán, cờ compiler, mức tối ưu, hoặc phiên bản runtime. Với constant-time-analysis cho audit bảo mật, lượt kiểm tra thứ hai thường là lúc bạn xác nhận được tư thế an toàn thực sự.