You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A bunch of sources, and some working code, has provisions to destroy crypto material (eg. by overwriting it).
I guess the underlying logic is that if an adversary is sleeping in your RAM, but you are just lucky enough for them to be out for coffee while you are doing your secret-secretly-secret computations, if you overwrite your material quickly, they won't see it when they snuggle back in your memory.
This logic is beyond me. I'd say that if the memory is compromised, all bets are unconditionally off, and hoping to catch an appropriate timing -- even the timing caled "before" -- is weak.
The thing complicates in a memory-managed language, where the compactifying GC is another adversary sleeping in your RAM, interrupting your pesky activity from time to time, and copying around whatever you are working with. At unpredictable intervals.
Granted, most key material is Cstruct.t, which is a Bigarray.Array1.t, which is allocated outside of the GC heap, but:
We still retain some info in offset-length descriptors which are on the heap; and
A bunch of key material is naturally represented as numbers whose representation is beyond reach.
Things can be worked around, but it would leave a horrid api semantics, which would, instead of simply operating on values, now operate on objects: things, with a life-cycle, instead of bits of information.
Could this possibly be worth it?
The text was updated successfully, but these errors were encountered:
And of course, erasure lowers the probability of the material being paged onto persistent storage, where it really could live indefinitely. But then the same logic applies to adversaries sleeping in your hard-drives, only a little weaker because those do get trashed with all the bits still on them.
Is it enough to assert the primary target is server-side TLS on Mirage?
In general it's just a good idea to keep track of your sensitive material and prevent it from leaking into uninitialized memory (e.g. someone else's fresh stack, or persistent swap). It's obviously diminishing returns to destroy all possible derived material from a key, but it's reasonable to track the Cstruct explicitly and ensure that it's deallocated and zeroed before being released.
A bunch of sources, and some working code, has provisions to destroy crypto material (eg. by overwriting it).
I guess the underlying logic is that if an adversary is sleeping in your RAM, but you are just lucky enough for them to be out for coffee while you are doing your secret-secretly-secret computations, if you overwrite your material quickly, they won't see it when they snuggle back in your memory.
This logic is beyond me. I'd say that if the memory is compromised, all bets are unconditionally off, and hoping to catch an appropriate timing -- even the timing caled "before" -- is weak.
The thing complicates in a memory-managed language, where the compactifying GC is another adversary sleeping in your RAM, interrupting your pesky activity from time to time, and copying around whatever you are working with. At unpredictable intervals.
Granted, most key material is
Cstruct.t
, which is aBigarray.Array1.t
, which is allocated outside of the GC heap, but:Things can be worked around, but it would leave a horrid api semantics, which would, instead of simply operating on values, now operate on objects: things, with a life-cycle, instead of bits of information.
Could this possibly be worth it?
The text was updated successfully, but these errors were encountered: