32 lines
1.5 KiB
ReStructuredText
32 lines
1.5 KiB
ReStructuredText
|
|
||
|
|
Memory container
|
||
|
|
========================================
|
||
|
|
|
||
|
|
A major concern with mixing modern multi-user OSes and cryptographic
|
||
|
|
code is that at any time the code (including secret keys) could be
|
||
|
|
swapped to disk, where it can later be read by an attacker, or left
|
||
|
|
floating around in memory for later retrieval.
|
||
|
|
|
||
|
|
For this reason the library uses a ``std::vector`` with a custom
|
||
|
|
allocator that will zero memory before deallocation, named via typedef
|
||
|
|
as ``secure_vector``. Because it is simply a STL vector with a custom
|
||
|
|
allocator, it has an identical API to the ``std::vector`` you know and
|
||
|
|
love.
|
||
|
|
|
||
|
|
Some operating systems offer the ability to lock memory into RAM,
|
||
|
|
preventing swapping from occurring. Typically this operation is
|
||
|
|
restricted to privileged users (root or admin), however some OSes
|
||
|
|
including Linux and FreeBSD allow normal users to lock a small amount
|
||
|
|
of memory. On these systems, allocations first attempt to allocate out
|
||
|
|
of this small locked pool, and then if that fails will fall back to
|
||
|
|
normal heap allocations.
|
||
|
|
|
||
|
|
The ``secure_vector`` template is only meant for primitive data types
|
||
|
|
(bytes or ints): if you want a container of higher level Botan
|
||
|
|
objects, you can just use a ``std::vector``, since these objects know
|
||
|
|
how to clear themselves when they are destroyed. You cannot, however,
|
||
|
|
have a ``std::vector`` (or any other container) of ``Pipe`` objects or
|
||
|
|
filters, because these types have pointers to other filters, and
|
||
|
|
implementing copy constructors for these types would be both hard and
|
||
|
|
quite expensive (vectors of pointers to such objects is fine, though).
|