128 reputation
4
bio website
location Taiwan
age 18
visits member for 1 year
seen Sep 8 at 15:42

Feb
7
awarded  Editor
Feb
7
revised Generating Diffie-Hellman parameters efficiently
Improved code formatting
Feb
7
suggested suggested edit on Generating Diffie-Hellman parameters efficiently
Feb
7
comment Generating Diffie-Hellman parameters efficiently
Try using ECDHE, much faster as the key sizes don't have to be as big and the curves are pre-generated. As a side note, number of cores won't help since everything is done on one thread.
Dec
13
awarded  Student
Dec
13
comment When do I need to renew keys for Salsa20 or HMAC?
@CodesInChaos So practically there isn't much security benefit from doing key renewals disregarding forward secrecy. And with regard to forward secrecy changing the key must be done at quite a frequent interval to minimize loss should the key be compromised. Am I correct is saying the above?
Dec
13
asked When do I need to renew keys for Salsa20 or HMAC?
Nov
21
comment Are there any protocols that are truly secure from active and passive MITM attacks?
@user31425 What part of my comment are you referring to? Putting trust in a CA can only yield secure connection if the CA itself is functioning normally, which is the basic assumption a client makes when it contacts a CA.
Nov
10
awarded  Supporter
Nov
8
comment Are there any protocols that are truly secure from active and passive MITM attacks?
If a shared secret is pre-established and there is a guarantee that only Alice and Bob knows the shared secret. Any old symmetrical encryption is good enough... You can even use the shared secret to generate a time-based temporal key for message transmission. If no shared-secret can be established, then no, you are left with nothing... If you think about it logically, with no third party (e.g CA) involved and given the parameter that EVERYTHING can be faked, how can one identify someone else?
Nov
4
awarded  Teacher
Nov
3
comment randomly generated key reused with XOR
@owlstead +1 for "almost infinitely". Might I also suggest for defined "messages" like OP suggested, a block cipher would be better. As his/her messages have finite length and OP wishes to encrypt them "differently" (Implied by his/her concept of choosing a new key)
Nov
3
answered randomly generated key reused with XOR
Nov
3
comment randomly generated key reused with XOR
How exactly do you expect to decrypt this message? If your key k is randomly generated per message, does that mean the decryption party has a means to generate key k based on some agreed parameters? And also, can you not generate a new key for every chunk of the message? (i.e If the message was 1024-bits but your key is only 256-bits, can you not simply generate 4 keys for each part?). Reusing keys is already bad, given your performing a simple XOR to get ciphertext from plaintext, simple ciphertext analysis can quickly determine the message based on repeats in the message body.