Timeline for Writing your own Encryption algorithm?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 3, 2018 at 22:50 | comment | added | Jacob H | @EllaRose the extra link still deals with data communication, which I completely agree with; OTP should not be used for data communicated over a network. However I think OTP is fine for storing passwords on a local machine, with keys stored on say, a usb drive. I don't think it's any more prone to failure than AES. | |
| May 3, 2018 at 22:44 | history | edited | Ella Rose | CC BY-SA 4.0 |
added another link for why the OTP is not a practical algorithm
|
| May 3, 2018 at 22:43 | comment | added | Ella Rose | @JacobH The linked answer discusses why it is clunky (the awkward need to pre-distribute $n$ bits of key material for $n$ bits of message) and cites precedent for how it has failed before in the past. I can add another link to drive the point home even more. | |
| May 3, 2018 at 21:04 | comment | added | Jacob H | "Using the one time pad in practice is clunky and prone to failure" The answer you link doesn't seem to support this at all. It states that it is basically useless to use OTP for trasnmitting data, but that is not what OP asks. | |
| May 3, 2018 at 18:07 | comment | added | user | @SeanBurton Certainly fair enough. | |
| May 3, 2018 at 14:40 | comment | added | Sean Burton | Fair enough, they are a side-channel attack. Not sure whether you include padding, modes, key generation, etc within part of the symmetric encryption, or whether you consider them other parts of the overall solution, as there's plenty of other ways those could get messed up (using ECB, reusing IV or counters, using a bad RNG, using insecure padding or not validating the padding, etc). | |
| May 3, 2018 at 14:16 | comment | added | user | @SeanBurton I specifically qualified that statement with "iff OP isn't worried about things like sidechannel attacks". Timing attacks definitely count as sidechannel attacks to me. | |
| May 3, 2018 at 14:11 | comment | added | Sean Burton | @MichaelKjörling Actually, it is very easy to mess up the implementation of even symmetric crypto to the point of vulnerability, for example by neglecting to use constant-time operations and opening your implementation up to timing attacks... | |
| May 3, 2018 at 9:44 | comment | added | user | As for "there exists a non-negligible probability of failure", as opposed to a lot of other software development tasks any serious published cryptographic algorithm will have plenty of test vectors published which you can write unit tests around before you even write the first line of implementation. Iff OP isn't worried about things like sidechannel attacks, then symmetric encryption and hashes are probably among the easier parts of an overall solution to implement. It'd likely be hard to mess up symmetric crypto to the point of vulnerability; asymmetric crypto is another matter, though! | |
| May 3, 2018 at 9:40 | comment | added | user | "It's inappropriate to encrypt passwords." That depends on the use case. For authentication, you are absolutely right. For storage (e.g. for a password manager), reversible encryption is a necessity (technically you could store the passwords in plain text and need no encryption, but that would be beyond stupid; with encryption, reversibility is a requirement for this use case). | |
| May 3, 2018 at 2:51 | history | edited | Ella Rose | CC BY-SA 4.0 |
added links
|
| May 3, 2018 at 2:39 | history | answered | Ella Rose | CC BY-SA 4.0 |