2
$\begingroup$

for example, I have an encryption program like this:

Input: a message, M; my public key Kpub

Step 1: randomly generate a symmetric (e.g., AES) key, K

Step 2: use K to encrypt M

Step 3: use Kpub to encrypt K

Step 4: destroy K

In step 4, how to destroy K? Can we just assign a random value (e.g., 0) to the variable? Is this safe? Thank you!

$\endgroup$
1
  • 4
    $\begingroup$ The typical method is by zeroing memory. For example, this function in .NET. However, this isn't always possible depending on the language. Furthermore, in some languages, the variable needs to be pinned so it doesn't get copied in memory. $\endgroup$ Aug 23, 2022 at 15:31

2 Answers 2

4
$\begingroup$

Quite often the key is considered a byte array. 128/192/256 bit variables may not be available. Lower level functions sometimes use a 32 bit word array of 4, 6 or 8 32-bit words. As long as the key is in memory just zeroing the array would be fine.

Whatever you do, don't use hexadecimals or other textual representations as those are often hard to delete from memory. Locking the memory in place is definitely recommended if that's possible for your runtime. Deletion should take place as soon as the decryption has ended; waiting for a destructor call that never comes is not a good idea.

If the key is in storage the problem becomes harder (so please make sure the key is not swapped out or something like that. Once on an SSD or HDD it might be possible to get to the value even after zeroing the key value, although that definitely requires specialist knowledge and possibly some lab equipment. Randomizing the value would be considered good practice, but please note that even randomization may leave some residual information.

It would probably be harder to destroy the message as well. If the data specific key is not in memory, but the data itself is, then you might not have accomplished all that much. Key destruction is great, but don't forget that managing access to your system is probably more rewarding - both physical as logical access.

$\endgroup$
3
  • 1
    $\begingroup$ Why do you say encodings as ASCII hex are harder to delete from memory? Also, you can't recover an erased sector on an HDD (on an SSD it's possible due to wear leveling). A single overwrite of the sector containing the key is sufficient to destroy it if it's spinning rust. $\endgroup$
    – forest
    Aug 24, 2022 at 22:06
  • $\begingroup$ What I understood there may leak some magnetism into adjacent rust. I also understood that by now, the density is so high that it is near impossible to get any information that way though. And in principle you could get extremely unlucky and put a key into sector that becomes a bad sector later (in which case it gets written to a spare location on the disk). Information on the state of this kind of technology. If you're worried about it: using disk encryption could be a solution. $\endgroup$
    – Maarten Bodewes
    Aug 24, 2022 at 22:13
  • $\begingroup$ That was possible in theory for MFM and RLL hard drives, but they haven't been used in more than two decades. Nowadays it's all stuff like EPRML, where that doesn't apply and there is no way, theoretical or otherwise, to recover the previous contents of an overwritten sector. (Also, you should be locking memory, otherwise the key material might swap out.) $\endgroup$
    – forest
    Aug 24, 2022 at 22:13
5
$\begingroup$

The secure implementations would lock a small part of the memory to not get swapped out, various operating systems provide this functionality. In linux mlock systemcall and VirtualLock in windows. This will prevent a certain section of memory from being swapped out and written to disk. Obviously you are usually limited in how much memory you may lock.

Allocate the random key in this part of memory and ensure other key related stuff, partial keys used during claculations etc. are all in the locked region.

When you are done write out zeros, to any part of memory which had the key or might have something related, like a round sub key.

If you leave the key or a round sub key around, someone may be able to read it, from memory or from disk after it gets written to swap. Deleting data fully from disk is much harder, especially with modern hard drives.

Nothing is fool proof, including using the methods I mentioned. If your attacker is sitting on the same machine as you there are some attack vectors hard to defend against, but we can make it as difficult as possible.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.