3 ms·
I propose a game. Here are the rules. Private key comes (as a surprise) in many forms, including: 1) base64 encoded version 2) decoded version 3) "rocket sc
by tiredoldfart 13y ago
I propose a game. Here are the rules.
Private key comes (as a surprise) in many forms, including:
1) base64 encoded version
2) decoded version
3) "rocket science" parts (n, p, d, ...): openssl rsa -text -in ./private.key | grep "^[a-z].*:$"
-> modulus:, privateExponent:, prime1:, prime2:, exponent1:, exponent2:, coefficient:
You may assess the leak potential by yourself:
a) by writing down your private key secrets (openssl rsa -text -in ./private.key) on a paper or in a python keyhunt.py and heartbleeding a real server (initialized with a known private key) few times and then inspecting the output (requires a bit of patience) [X]
b) by running openssl in a debugger and understanding what happens with the crypto secrets in a real live run (requires a bit of reversing) [X]
c) by running the openssl under e.g. valgrind and checking how the allocation of different forms of the crypto secrets really works (requires tools) [X]
d) by modifying the openssl CRYPTO_malloc() code to initialize crypto buffers with a recognizable patterns and then heartbleeding your test server (requires a bit of coding) [X]
e) reading the code and seeing how all those intermediate forms of the private key are handled (and reading it again, and again until you are certain of your conclusion) (requires skill) [X]
f) by reading from the web accounts and results of people who have seen the private keys (requires trust) [X]
g..z) by something else ... [X]
Then post your how many X's you had to go through before you see the leak. Good luck! :D
I didn't get far before it was seeing the leak time for me, but then I cheated and saw most of those done anyway, was painful but fun. :)