| bio | website | |
|---|---|---|
| location | Netherlands | |
| age | 39 | |
| visits | member for | 1 year, 5 months |
| seen | yesterday | |
| stats | profile views | 15 |
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.
|
Jan 3 |
comment |
Benefit of combining classical substitution ciphers with modern cryptography Your assumption: "the client has a key of 64 chars (a-z, A-Z, "+/")" is a pretty bad assumption due to the fact that a key itself should be a binary key generated by using a (pseudo) number generator or - if a password is the only input - an output of a password based key derivation function (PBKDF) such as PBKDF2. |
|
Jan 3 |
comment |
How will Cryptography be changed by Quantum Computing? AES with 256 bit blocks does not exist. AES is the standardized form of Rijndael with 128 bit block size. |
|
Jan 3 |
comment |
Is RSA in a ECB-like-mode safe for bulk encryption? Looking back at this question, I think that the order of the blocks does not matter much. If you are worried about that, then you need some sort of integrity protection anyway, just like you would if you were using any symmetric cipher. Because of the random padding, at least the plain text is relatively safe compared to e.g. AES in ECB mode. |
|
Jan 3 |
comment |
Does the elliptic curve (EC) cryptosystem outperform RSA and DL cryptosystems? Actual performance may of course vary between implementations. You are better off doing a theoretical compare, as given by Thomas, as any other compare is bunk. Or implement a performance compare yourself and run it on your target platforms. |
|
Dec 17 |
comment |
Good enough deterministic PRNG based on hashes Voted down because, although it is good advice, it is not an answer. |
|
Nov 29 |
comment |
AES timing attacks Knowledge about the key, obviously. |
|
Nov 29 |
comment |
AES timing attacks Waiting to a constant time would do it, although that really could affect performance. If the plain text must be known depends on the kind of attack I guess. Timing attacks is a group of attacks, not so much a specific one. |
|
Nov 29 |
revised |
AES timing attacks made link work + title |
|
Nov 29 |
comment |
Counter mode secure hash algorithm Again thanks, I'm trying to get access but the first promising link in Google seem to be down. Maybe I should push some cash some way to get to the paper. So be it. |
|
Nov 29 |
comment |
AES timing attacks In general timing attacks are pretty relevant to real life network applications (unfortunately). And unfortunately timing attacks generally rely on statistics over many tries. This means that non-key specific delays can easily be averaged out. Constant delays especially don't accomplish much. Best way to attack them is to make a more constant implementation and making sure that a key is only used a certain amount of times. Slow down loops on possible attacks can also be used, simply to slow the attack down. |
|
Nov 29 |
suggested | suggested edit on AES timing attacks |
|
Nov 29 |
comment |
Counter mode secure hash algorithm That said, I don't think the problem has been studied well enough that it doesn't merit more attention. But I also have to admit that my current knowledge dictates that it won't be me that is making a proposal anytime soon :). |
|
Nov 29 |
revised |
Why is the IV passed in the clear when it can be easily encrypted? Completed the course (with a pretty good score too) |
|
Nov 29 |
comment |
Counter mode secure hash algorithm Thanks for the additional info, I did hear about the hash functions that use large numbers to accomplish "my" requirements, but they do indeed seem to be too impractical to achieve performance benefits over a generic hash. That said, there are likely special benefits e.g. when some parts of the data is only available after a certain amount of time. |
|
Nov 29 |
awarded | Yearling |
|
Nov 16 |
comment |
AES key padding The statement is that decryption will fail if the key is faulty, and this is correct. But authenticated encryption does not provide a method to test if the key is incorrect. A decryption failure will also occur if the ciphertext has been altered. |
|
Nov 16 |
comment |
AES key padding I.e. means "id est" in Latin, which in turns means that a more precise description of the statement will follow. As using an incorrect key is only one reason why decryption may fail, the question is not correctly stated here. It would work if you meant e.g., "exempli gratia", or "for example". |
|
Nov 13 |
comment |
Why shouldn't one build a MAC by XORing multiple message blocks? Explain why we should do your homework. |
|
Oct 31 |
comment |
Is AES in CBC mode secure if a known and/or fixed IV is used? I feel that the use case where a key derivation function is used together with a random salt (for each encrypt) is missing. In that case there are less constraints on the IV, as the key will be different each time it is used for encryption. |
|
Oct 31 |
comment |
Is frequency analysis a useful tool against encryption by multiplication? @illsecure I think the answer is clear enough to receive an accept, don't you think? |