1. Benchmark hiệu năng I/O và CPU giữa TLS thông thường và TLS PQC
Chúng ta sẽ sử dụng công cụ openssl speed để đo lường tốc độ tính toán của các thuật toán, sau đó dùng pgbench để đo thông lượng thực tế của PostgreSQL dưới hai chế độ: TLS 1.3 (ECDSA/RSA) và TLS 1.3 với hybrid PQC (X25519-Kyber512).
Đo tốc độ tính toán thuật toán mật mã
Bước này xác định overhead về CPU khi thực hiện các hàm hash và ký số cho thuật toán PQC so với thuật toán cổ điển.
Tại sao: Để hiểu mức độ ảnh hưởng của thuật toán Kyber512 (PQC) lên tài nguyên CPU trước khi chạy trên hệ thống thực tế.
Kết quả mong đợi: Bạn sẽ thấy số lần ký số (signatures) hoặc mã hóa (encryptions) trên giây thấp hơn một chút so với ECDSA, nhưng vẫn nằm trong ngưỡng chấp nhận cho giao dịch ngân hàng.
cd /usr/local/openssl-pqc/bin
./openssl speed -evp "aes-256-gcm" "x25519" "rsa-2048" "kyber512" 2>&1 | grep -E "sign|verify|enc|dec"
Sau khi chạy, bạn sẽ thấy bảng thống kê tốc độ. Lưu ý các giá trị "sign" và "verify" của kyber512 để so sánh với rsa-2048 hoặc ecDSA.
Benchmark PostgreSQL với pgbench
Chúng ta sẽ chạy pgbench với 50 client song song trong 60 giây, sử dụng script mặc định (SELECT/INSERT/UPDATE/DELETE).
Tại sao: Để đo Throughput (TPS) và Latency thực tế khi PostgreSQL phải xử lý handshake TLS PQC cho mỗi kết nối mới.
Kết quả mong đợi: TPS của chế độ PQC có thể thấp hơn 5-15% so với TLS thường, nhưng độ trễ (latency) tăng thêm chỉ khoảng 1-2ms do handshake.
Đầu tiên, chuẩn bị script benchmark ghi nhận kết quả vào file log riêng biệt.
mkdir -p /var/log/pgbench_test
# Chạy benchmark cho TLS thường (nếu chưa tắt PQC, cần cấu hình lại postgresql.conf tạm thời)
# Giả sử ta đã có hai instance: 5432 (TLS thường) và 5433 (TLS PQC)
# Benchmark TLS PQC (Instance 5433)
pgbench -h 127.0.0.1 -p 5433 -U postgres -c 50 -T 60 -f /var/lib/postgresql/data/tpch/tpch.sql -l > /var/log/pgbench_test/pqc_benchmark.log 2>&1
Chờ lệnh chạy xong (khoảng 60 giây). Kiểm tra file log để lấy giá trị TPS (transactions per second).
grep "transactions per second" /var/log/pgbench_test/pqc_benchmark.log
Lặp lại tương tự cho instance TLS thường (port 5432) để so sánh.
pgbench -h 127.0.0.1 -p 5432 -U postgres -c 50 -T 60 -f /var/lib/postgresql/data/tpch/tpch.sql -l > /var/log/pgbench_test/standard_benchmark.log 2>&1
grep "transactions per second" /var/log/pgbench_test/standard_benchmark.log
2. Phân tích chi tiết handshake PQC bằng openssl s_client
Sử dụng openssl s_client để bắt và phân tích quá trình bắt tay (handshake) giữa client và server, xác minh xem thuật toán PQC (Kyber) có thực sự được trao đổi không.
Tại sao: Để chứng minh hệ thống không chỉ cấu hình PQC mà còn đang thực thi đúng giao thức hybrid (PQC + ECDSA) trong quá trình kết nối.
Kết quả mong đợi: Trong output của handshake, bạn sẽ thấy dòng Server key exchange hoặc Client key exchange chứa thông tin về kyber512 hoặc hybrid.
Chạy lệnh s_client với chế độ verbose để hiển thị chi tiết các bước handshake.
/usr/local/openssl-pqc/bin/openssl s_client -connect 127.0.0.1:5433 -tls1_3 -verify_depth 10 -state -msg -servername your_domain.com
Gửi một ký tự (ví dụ: "q") để server phản hồi và đóng kết nối, sau đó Ctrl+C để thoát.
Sau khi có output, tìm kiếm các từ khóa quan trọng để xác minh.
/usr/local/openssl-pqc/bin/openssl s_client -connect 127.0.0.1:5433 -tls1_3 -msg -servername your_domain.com 2>&1 | grep -i "kyber\|pqc\|hybrid\|supported_groups"
Kết quả mong đợi: Bạn sẽ thấy dòng Supported Elliptic Curves hoặc Key Share liệt kê X25519 và kyber512 (hoặc tên thuật toán tương đương trong build của bạn).
3. Kiểm thử Stress (Stress Test) để tìm điểm nghẽn
Thực hiện kiểm thử tải cực lớn với hàng ngàn kết nối đồng thời để tìm giới hạn của CPU hoặc bộ nhớ khi xử lý các thuật toán PQC nặng.
Tại sao: Các thuật toán PQC có kích thước key lớn hơn nhiều so với RSA/ECDSA, gây áp lực lên bộ nhớ và CPU. Cần xác định điểm "bottleneck" trước khi đưa vào production.
Kết quả mong đợi: Xác định số lượng connection tối đa mà server chịu đựng được trước khi Latency tăng đột biến hoặc CPU đạt 100%.
Sử dụng công cụ ab (Apache Benchmark) hoặc wrk để tạo tải. Ở đây dùng ab với script SQL đơn giản.
ab -n 100000 -c 200 -p /var/lib/postgresql/data/test_query.sql "postgres://postgres@127.0.0.1:5433/postgres"
Tạo file test_query.sql trước đó nếu chưa có, chứa một câu SELECT đơn giản.
echo "SELECT count(*) FROM pg_stat_activity;" > /var/lib/postgresql/data/test_query.sql
Trong khi chạy ab, mở một terminal khác để giám sát tài nguyên thời gian thực.
watch -n 1 "ps aux | grep postgres; free -h; top -b -n 1 | head -20"
Quan sát: Nếu CPU usage đạt 100% và TPS giảm mạnh, đó là điểm nghẽn tính toán (CPU bottleneck). Nếu bộ nhớ ảo (Swap) tăng vọt, đó là điểm nghẽn bộ nhớ (Memory bottleneck) do key PQC lớn.
4. Phân tích Log PostgreSQL để xác minh không có cảnh báo lỗi thời
Quét file log của PostgreSQL để đảm bảo không có cảnh báo về việc sử dụng thuật toán bị coi là yếu hoặc lỗi thời (deprecated) trong quá trình hoạt động của hệ thống PQC.
Tại sao: Một số cấu hình sai có thể khiến server fallback về thuật toán cũ (RSA 1024, MD5) gây lỗ hổng bảo mật, hoặc log cảnh báo về việc PQC không khớp.
Kết quả mong đợi: Log chỉ hiển thị các dòng LOG: connection received và LOG: connection authenticated mà không có WARNING hay ERROR liên quan đến crypto, ssl, hoặc deprecated.
Đầu tiên, bật mức log lên debug3 tạm thời để xem chi tiết quá trình handshake trong log file.
sudo -u postgres psql -c "ALTER SYSTEM SET log_min_messages = 'debug3'; SELECT pg_reload_conf();"
Chạy lại một vài request để sinh log mới.
pgbench -c 5 -t 10 -h 127.0.0.1 -p 5433 postgres
Quét log file (thường nằm tại /var/log/postgresql/postgresql-16-main.log hoặc tùy cấu hình) để tìm các từ khóa cảnh báo.
grep -iE "deprecated|insecure|weak|ssl.*error|crypto.*fail" /var/log/postgresql/postgresql-16-main.log
Kết quả mong đợi: Nếu lệnh grep không trả về kết quả nào (empty output), nghĩa là hệ thống đang hoạt động ổn định và không có cảnh báo bảo mật nào.
Đặt lại mức log về mức mặc định sau khi kiểm tra xong để tránh log quá tải.
sudo -u postgres psql -c "ALTER SYSTEM SET log_min_messages = 'log'; SELECT pg_reload_conf();"
5. Tổng hợp và Verify kết quả cuối cùng
Tạo một script nhỏ để tổng hợp các chỉ số quan trọng từ các bước trên thành một báo cáo đơn giản.
Tại sao: Để đồng nghiệp có thể xem nhanh trạng thái hiệu năng và bảo mật của hệ thống mà không cần đọc lại từng file log.
Kết quả mong đợi: Một file báo cáo văn bản chứa TPS trung bình, độ trễ trung bình, và trạng thái an toàn của log.
cat > /tmp/verify_pqc_status.sh &1 | grep -i "kyber\|pqc" | head -1
echo "=== End Report ==="
EOF
chmod +x /tmp/verify_pqc_status.sh
/tmp/verify_pqc_status.sh
Chạy script này để xem báo cáo tổng kết. Nếu tất cả các mục đều hiển thị "OK" và giá trị TPS chấp nhận được, hệ thống đã sẵn sàng cho bước tối ưu hóa ở Phần 7.
Điều hướng series:
Mục lục: Series: Triển khai Database Quantum-safe với Postgres và Ubuntu 24.04
« Phần 5: Mã hóa dữ liệu tại chỗ (Encryption at Rest) sử dụng PQC
Phần 7: Troubleshooting, tối ưu hóa và hướng phát triển tương lai »