344 reputation
19
bio website Grieu
location
age
visits member for 3 years, 3 months
seen Mar 26 at 10:16

I'm an engineer with experience in applied cryptography, in particular in Smart Card systems.


Mar
18
comment Is using the concatenation of multiple hash algorithms more secure?
@Patrick M: indeed, and that's what I'm saying in the second paragraph. I'll make it clearer that it applies to password hasing (even though the question has been edited to make it clear password hashing is not the focus).
Mar
17
comment Is using the concatenation of multiple hash algorithms more secure?
@Ismael Miguel: good suggestion, done.
Mar
17
comment Is using the concatenation of multiple hash algorithms more secure?
@Ismael Miguel: I did mean at least as secure in the first paragraph. As in: the concatenation of MD5 and (full) SHA-512 is at least as secure as (full) SHA-512, WRT collision-resistance (also second-preimage-resistance). Proof: hypothetical colliding messages for the 640-bit MD5||SHA-512 also collide for SHA-512, thus if SHA-512 is secure, then MD5||SHA-512 is secure.
Mar
17
comment Is using the concatenation of multiple hash algorithms more secure?
The "128 bit MD5 and 128 bit SHA512 will only be as collision-resistant as the weaker of the two" part of this answer is wrong. As an illustration, we can find new MD5 collisions at high rate, but there is no known collision for SHA512 truncated to 128 bits, thus no known collision for the 256-bit concatenation of MD5 and SHA512 truncated to 128 bits.
Mar
17
comment Is using the concatenation of multiple hash algorithms more secure?
This answer is oriented toward password hashes, and does not apply well to the question as it stands after edit.
Nov
27
comment How is security of server's RSA private key is ensured?
@Herr K: On a server connected to using https, the key needs to be used to demonstrate the server's identity for each new connection. It is thus "live" somewhere, and no password-protection can help that. If the key is in the server's CPU+RAM, and the server is rooted, the key is in danger. As explained, the HSM slightly helps to mitigate that risk, for there is good assurance that the key won't leak from it.
Mar
26
comment Why does the linux XRDP module use a 512 bit RSA key?
The question, or at least this well-informed answer, should probably be moved or copied here
Feb
17
comment Snapchat clone: How do I secure pre-downloaded notifications so that they cannot be opened outside of the app?
Cryptography alone can't achieve the goal in the question.
Dec
18
comment Do modern Android devices provide access to their Secure Elelement in some way?
Many thanks! I have checked this. It works on some relatively recent real hardware, including inability to export the key, but only for RSA keys of 2048 bits, nothing else that I could find. Also, I found no way that a remote internet server could ascertain that a key is in the keystore and was generated there, or inject such key there securely.
Mar
19
comment Lessons learned and misconceptions regarding encryption and cryptology
"use TLS" without fine prints is not such a good idea, when we see this
Mar
11
comment Truecrypt compromised? (Coldboot attack)
To me, the question is squarely off-topic, and belongs to security.se. Also, the attack linked to in the question does not "retrieve decryption keys from a device's RAM (even after shutdown)"; as far as I understand, it retrieves the keys either from a running computer using a well-know attack using DMA-thru-Firewire (which is highly system-specific), or from an hibernation file when the computer was hibernated with the volume mounted; I'm not sure what are the fine prints for the later to work.
Apr
27
comment What are the risks of storing passwords in a GPG encrypted file?
The main risk IMHO is having the machine compromised; that applies equally to both solutions considered. An attack seems easier to mount on the command-line solution (e.g. with a trojan in any of gpg/grep/less/bash/kernel, or a keylogger in hardware or software), on the other hand a malware could target the other program if it gets audience.
Dec
7
comment On-line cryptographically signed date/time?
@bstpierre: My overall application is that the trusted device produce certs of some sort, with a limited period of validity from current date/time. Certs in the future would be a serious issue. If the time service is run in-house, the people able to tamper with it are the same (or close) to the ones with an incentive to do so, in order to subvert the trusted device to generate certs in the future. Thus I prefer an independent date/time source.
Dec
6
comment On-line cryptographically signed date/time?
However, the lack of insurance of continued availability worries me. I'd prefer a paid-for service, as long as it does not come with a requirement to authenticate; even a weak authentication by IP address is a pain (switch to a backup line and you are toast).
Dec
6
comment On-line cryptographically signed date/time?
Seems quite close. Even though the standard timestamping protocol seems a bit complex for my trusted environment, it is safe and reasonably easy to implement most of it in the untrusted PC, and have only the crypto verification of a pre-formatted blob in the trusted device.
Dec
6
comment On-line cryptographically signed date/time?
Further, email is not the most convenient way for me to get the result. A single TCP/IP connection for request/certificate would be best. I'll add that requirement.
Dec
6
comment On-line cryptographically signed date/time?
Did not think of this one; it is free, and I could easily check several sources and survive a few rogue ones. However, short of a full https stack in my trusted device, I fail to see how to implement that. I'd prefer a static certificate, or data structure that can be statically and simply checked, which is a much better fit for my environment. I'll add that requirement.
Dec
6
comment On-line cryptographically signed date/time?
Thanks for the recommendation of this free timestamping service. However, with these, there is no standard protocol, and long term availability worries me.