@kelalaka Ross is still active, so if the edits are not welcome he can react. Currently he just got some rep for free. The author of the new question seems happy, so there's that. I'd spend a bit more time on the grammar / completeness next time. I've performed another edit to fix some minor issues.
I don't think it changes the gist of the answer, so from that point of view everything seems fine as well. And you left the org. answer intact, so it was more of an add-on anyway.
I'm researching cryptography. I'm looking for expert volunteers for a 5-10 minutes interview via Zoom or Google Hangout. The research is a comparison between Blake2 and SHA3. If you would like to help me, here is my email: [email protected]. Send me an email, and I'll send you the interview questions. I will appoint a time that suits you best. Thank you.
@MaartenBodewes Yes, I've seen that Ross is still active. I've looked a dupe. I've known that there was already one in SO, the closes were Ross's answer. Instead of just copy and paste and replace the 100 with n, I thought that will be better.
Your premise has a flaw. You say you want to 'reverse engineer' the hash function. There's no need to reverse engineer it - its implementation is public.
What you can't do is invert it (perhaps that's what you meant), because it's not invertible. You can easily tell it's not an invertible functio...
I have two questions about the sessions keys generated during the last steps of the Handshake phase:
Do the "client write key" and the "server write key" have the same value, even though both keys are generated independently on both sides?
(Same question) Do the "client write MAC key" and the "...
I have two questions about the sessions keys generated during the last steps of the Handshake phase:
Do the "client write key" and the "server write key" have the same value, even though both keys are generated independently on both sides?
(Same question) Do the "client write MAC key" and the "...
