network profile
|
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? 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. |
