Re: refreshing keys regularly?
hi Philip, will it _help_ guard against brute force attempts to simply replace my server key on a daily or weekly basis? if so, should my client app be coded to do the same? or is changing out the server's key sufficient to this end? What are you doing with the keys ? Of course will it decrease the chance of breaking the key by brute force, but I think that if you choose a sufficient key length it is very unlikely that someone will break it... If you renew keys frequently - you have at least to protect the process of key exchange and I think that this might bring a new source of problems into the calculation... Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature
Re: key compromise with memory debugger possilbe ?
Hello Lev, thx for the quick answer We use openssl to en/decrypt data with 3des - is it possible to retrieve the used key while running a de/encryption via a memory debugger or something similar ? yes. Are there any preventions against such attacks or has noone ever thought about such an attack ? the problem is: you cannot completely eliminate all possible ways to attack the system. plan for building the system for which the cost of stealing the key would be barely more than expected damage which can possibly occur from breaking the system. that's the golden practical rule. yes of course - you must find the balance between paranoid and necessary ;) Are there any studies or test that have dealt with this issue ? That it is theoretically possible was clear to me, the question meant if it is enough possible for practical relevance - I even can hack a 3des key in a certain amount of time - so there is of course no 100% security... TIA Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature
Re: key compromise with memory debugger possilbe ?
hi Lev, [stuff deleted] this is very trivial. the key is contained clear-text in the memory image of a process (/dev/mem, or whatever). To try to decrypt the data with the key, the simplest case is a brute-force: fetch a memory region at location X, treat it as a key, and try to decrypt an encrypted data. You certainly have to have an algorithm to determine with high probability that decription has succeeded, but it is quite easy for most structured data, including audio formats. The complexity of this task is linear with amount of process memory: for 5 mbyte process the whole process will take certainly less than an hour of average computer. That was the part Im looking for - unfortunatley :( P.S. I am being unfair to a certain extent. Good security-conscious programming provides several techniques to lower the window of opportunity for the attacker to gain the access to this data. For example, it is customary to wipe the key from the memory after it was used to encrypt the data. The anti-swap techniques (mlockall(2)) are also widely used. Hmm, if I want to decrypt a 2 hour movie I have no chance to delete the key before the movie was decrypted, so there is enough time to get it from the memory And I dont need the study for knowing that it is possible - the question is how easy it is and if we can make it more difficult (we have some ideas...) and I just wanted to know if there have been some considerations within the team... One Idea is, not to store the full key but the derived chunks and produce some noise around the parts - so you are unable to read the whole key. Using your approach to try every piece of memory as a key will render unusable because you now must try every combination of three randon pieces of memory - I think this will significantl raise the computing time into infinity ;) Thanks for your opinion Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature
