| bio | website | codingrobots.com |
|---|---|---|
| location | ||
| age | 30 | |
| visits | member for | 1 year, 9 months |
| seen | May 17 at 11:14 | |
| stats | profile views | 7 |
Programmer and founder at Coding Robots
|
Oct 13 |
comment |
AES encryption for images @user39576 I quoted numbers for CBC; a few XORs is not a lot of additional operations. As for "codec problems" -- what's the purpose of opening an encrypted image if your current software doesn't understand that it's encrypted anyway? To look at white noise? The paper says it's so that "standard decoders can still decode the encrypted data without crashing". What kind of software crashes on a malformed input? |
|
Oct 11 |
comment |
AES encryption for images What codec problems? What large number of operations? How large are your images? AES can encrypt ~ 200 MB/s-1 GB/s on a modern computer. |
|
Oct 8 |
comment |
Hash collision resistance requirements for Lamport signatures Thanks! So, in general, for Lamport signatures with ~s-bit security for both collisions and preimages, k=2s, n=s+log2(4s), which for 128-bit security is 256 and 137. |
|
Oct 8 |
accepted | Hash collision resistance requirements for Lamport signatures |
|
Oct 7 |
revised |
Hash collision resistance requirements for Lamport signatures s/Kib/KiB/ |
|
Oct 7 |
revised |
Hash collision resistance requirements for Lamport signatures deleted 3 characters in body |
|
Oct 7 |
asked | Hash collision resistance requirements for Lamport signatures |
|
Sep 25 |
revised |
What is difference between PRG, PRF, and PRP edited for typos, removed last sentence |
|
Sep 25 |
suggested | suggested edit on What is difference between PRG, PRF, and PRP |
|
Aug 30 |
awarded | Critic |
|
Aug 27 |
comment |
Can iterated key expansion in Blowfish slow down bruteforce attacks on small key sizes? Correction: 2^32 * 8-byte blocks would be 32 GB (can't edit your post, because edits under 6 characters are not allowed for some reason.) |
|
Aug 27 |
accepted | Can iterated key expansion in Blowfish slow down bruteforce attacks on small key sizes? |
|
Aug 27 |
comment |
Can iterated key expansion in Blowfish slow down bruteforce attacks on small key sizes? Great, thank you! I didn't know about EksBlowfish. Perhaps, you can rewrite this comment into an answer, and I'll accept it. |
|
Aug 27 |
comment |
Can iterated key expansion in Blowfish slow down bruteforce attacks on small key sizes? Oh, I think that's what you suggested, actually, right? |
|
Aug 27 |
comment |
Can iterated key expansion in Blowfish slow down bruteforce attacks on small key sizes? I could, of course, stretch the key into a longer one with bcrypt, however this would violate the condition of the original problem -- using 64-bit encryption key :) I can restate the question: is using the state of bcrypt(cost, salt, password) directly for encryption of data (instead of encrypting "OrpheanBeholderScryDoubt" 64 times and then using the result as the key for new state) acceptable? |
|
Aug 27 |
awarded | Scholar |
|
Aug 27 |
accepted | What are the safe ways to derive HMAC key using block cipher? |
|
Aug 27 |
awarded | Student |
|
Aug 27 |
comment |
What are the safe ways to derive HMAC key using block cipher? Thank you! Regarding your last point: would it make sense (assuming that we can use block cipher with our own keys) to derive an intermediate key like you said, and then run block cipher with this key in CTR mode to generate the final MAC key of the requested length? |
|
Aug 27 |
revised |
What are the safe ways to derive HMAC key using block cipher? from -> using |