meta user
network profile
| bio | website | |
|---|---|---|
| location | Netherlands | |
| age | 39 | |
| visits | member for | 1 year, 6 months |
| seen | Jun 8 at 13:00 | |
| stats | profile views | 17 |
Java and security expert with over 10 years of experience with the language and with the practical application of cryptographic protocols - including the design of protocols within international standardization bodies. Creator of a heavily used common criteria certified product. Over 30 years of experience with computers. Likes kids, cats, reading, movies and several sports.
|
Mar 3 |
comment |
Can I combine two PRNGs to make use of more seed data? There are by definition only 2^160 possible streams because the state is 160 bits... And 160 bits is a lot. |
|
Mar 3 |
revised |
Can I combine two PRNGs to make use of more seed data? added 161 characters in body |
|
Mar 3 |
comment |
Can I combine two PRNGs to make use of more seed data? Good answer, but in this case the PRNG does not really expect a 160 bit seed at all. The SecureRandom implementation already compresses the seed. |
|
Mar 3 |
answered | Can I combine two PRNGs to make use of more seed data? |
|
Mar 3 |
answered | What information to include is the 'info' input for HKDF? |
|
Mar 2 |
comment |
How can I use asymmetric encryption, such as RSA, to encrypt an arbitrary length of plaintext? Could you indicate why you would need CBC over ECB when using a PKCS#1 compatible padding scheme? The padding scheme should already contain at least 8 bytes of random data, so wouldn't that act as a per-block IV? Note: I'm only considering confidentiality here of course. |
|
Feb 28 |
revised |
Counter mode secure hash algorithm forgot one commutative -> associative |
|
Feb 26 |
revised |
What information to include when calculating the HMAC of ciphertext added 36 characters in body |
|
Feb 26 |
comment |
What information to include when calculating the HMAC of ciphertext Yes you get the gist of it, although if a padding oracle attack is feasible (which depends on a few other things) then retrieving the plain text is certainly possible. These attacks should not jeopardize the key. |
|
Feb 26 |
answered | What information to include when calculating the HMAC of ciphertext |
|
Feb 25 |
comment |
Which one is fastest? Karatsuba or Montgomery multiplication? @HenrickHellström On the other hand, I don't think curious would get a better answer at stackoverflow than he just did in your comment, so... |
|
Feb 24 |
accepted | Symmetric encryption mode where ciphertext size is plain text size |
|
Feb 22 |
comment |
Why do we assume un-security of communication channel on every cryptography system +1 although the second paragraph is still a bit vague to me - which is understandable given the question |
|
Feb 22 |
asked | Symmetric encryption mode where ciphertext size is plain text size |
|
Feb 21 |
comment |
Why do we assume un-security of communication channel on every cryptography system For public key cryptography you need at least a trusted certificate, and this has to be secured through a secure channel. In this case the secured channel could however be e.g. a browser installation. After that you don't need secure channels anymore. |
|
Feb 21 |
comment |
Is storing original file size in an encrypted file header a bad idea? Obviously posting the length of the cipher text poses its own risks, especially since it is linked with the size of the plain text. |
|
Feb 21 |
answered | Is storing original file size in an encrypted file header a bad idea? |
|
Feb 21 |
comment |
Validating successful decryption in AES Link to previously asked question on stackoverflow |
|
Feb 17 |
comment |
AES encryption with shared IV @Thomas OK, fair enough. I generalized the warning because there is no need to make the IV public in this scheme, as long as key key is unique for each "session" of course. |
|
Feb 17 |
comment |
AES encryption with shared IV @Thomas in this specific case (CBC/zero counter/same key) it certainly is a flaw. |
