meta user
network profile
| bio | website | touset.org |
|---|---|---|
| location | San Francisco, CA | |
| age | 29 | |
| visits | member for | 7 months |
| seen | 13 hours ago | |
| stats | profile views | 14 |
Cyclist. Rubyist.
|
1d |
comment |
Generate fixed length cipher text from arbitrary length plaintext Simplistically, such a construct would allow for infinitely efficient compression. Want to distribute a 10TB file? Easy! "Encrypt" it with this scheme and it's now only $n$ bits in size. |
|
May 14 |
comment |
Using an MD5 hash as a password I believe the odds of an "accidental" collision in only $2^{77}$ inputs to MD5 is virtually indistinguishable from zero. |
|
May 14 |
revised |
Using an MD5 hash as a password added 465 characters in body |
|
May 14 |
answered | Using an MD5 hash as a password |
|
May 10 |
comment |
Is the DES algorithm in OPENSSL random? You're correct that it isn't broken in a cryptanalytic sense. It's just that 56 bits is well within brute force range of even rank amateurs, which for all practical purposes is totally broken. A 56 bit key was brute forced in 1998 on a single desktop computer in a little over two days. Given the advances in hardware, I can't imagine a DES key would last more than a few hours at most against an average modern laptop. |
|
May 10 |
comment |
Is the DES algorithm in OPENSSL random? If you're just asking out of curiosity, great. But you should never, ever, ever use DES for any practical application. It is absolutely 100% broken. Use AES if this is for anything other than toying around. |
|
May 9 |
answered | Does knowledge of original file size provide a cryptographic weakness? |
|
May 5 |
comment |
Theoretical pi-based stream cipher That is the definition of "normal": all digits have uniform probability in every possible base. And as stated earlier, that doesn't imply that they are distributed randomly, only evenly. To flip your question around, what evidence is there that the digits in $\pi$ are indistinguishable from random? We can't just assume the property of randomness merely because it would be convenient. It must be proven. |
|
May 4 |
comment |
How to derive two keys from one password Why? Using one algorithm is less complicated and has equivalent characteristics. |
|
May 2 |
comment |
Encrypt a single file, chunk-by-chunk, each chunk using different key (AES) Alternatively to CTR, you can simply use GCM mode which has authentication built-in, not requiring a separate HMAC. You can always send distinct blocks to multiple cloud services for storage, but it does require all of the blocks to decrypt any of them. |
|
Apr 29 |
comment |
Custom crypto library in C @user1028028 You asked for advice, and the advice you received has universally indicated that what you're doing is likely a poor idea, and that your "needs" appear to be completely incompatible with sound cryptographic practices. Do with that information what you will. |
|
Apr 29 |
comment |
Custom crypto library in C If you think that adding calls to sleep is a good way of preventing timing attacks against a C library, you have absolutely no business implementing your own crypto. |
|
Apr 29 |
awarded | Quorum |
|
Apr 28 |
comment |
Is this scheme a provably fair random number generation? When the client knows $n$, $o$, and $p$ I don't see how the client can't easily reconstruct $m$ when given $p\equiv m + o \pmod{n}$ and $m < n - 1$ |
|
Apr 25 |
comment |
Is this scheme a provably fair random number generation? @DavidSchwartz Do you mean $m$? I'm not sure I follow. |
|
Apr 25 |
comment |
Is this scheme a provably fair random number generation? I think technically the server only needs to send $p$ to the client, since $m$ can be derived (although as stated, the protocol could easily be extended to three or more collaborating parties) |
|
Apr 25 |
comment |
Password verification @bic "Is the process in actuality broken?" is really the wrong question to be asking, and I hope to disabuse you of that line of thinking in the first place. The answer is practically always going to be "yes" in situations like this. That still applies even if you, I, or even an experienced cryptographer don't immediately know the exploitable flaw. Additionally, there are all manner of possible vulnerabilities that can and will crop up during the implementation of the protocol, even if the protocol itself is secure. |
|
Apr 25 |
revised |
Password verification added 1246 characters in body |
|
Apr 25 |
revised |
Password verification added 1246 characters in body |
|
Apr 25 |
revised |
Password verification added 1246 characters in body |
