BOTAN(3em)
π NAME π
okay so bestie, welcome to the botan page β section 3em, if we're being precise β and it's literally Botan bindings for Emilua. that's the whole name. no cap. π«Άβ¨
β¨ DESCRIPTION β¨
First up, here's how you summon the secure byte span module:
local secure_byte_span = require 'botan'.secure_byte_span
local buf = secure_byte_span.new(4096)
So the secure_byte_span module lets you create a byte_span that uses Botanβs secure allocators. obsessed. π
And here's the handbook quote that explains the whole βwhyβ β read it, it's giving essential context:
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 astd::vectorwith a custom allocator that will zero memory before deallocation, named via typedef assecure_vector. Because it is simply a STL vector with a custom allocator, it has an identical API to thestd::vectoryou 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. β https://botan.randombit.net/handbook/api_ref/secmem.html
so secure_byte_span will use the same allocators from Botanβs secure_vector. This mitigation is also useful to protect cryptographic secrets if you have a buggy application that sends uninitialized data elsewhere (i.e. use-after-free). iykyk. Consider the following code:
local my_message = byte_span.new(size)
stream.write_all(my_socket, my_message)
The developer forgot to initialize my_message with the message they actually intended to send. byte_span.new() allocates memory. If the allocated memory was previously used to hold cryptographic secrets, these secrets will be leaked. However if all the sensitive data had been allocated using secure_byte_span then no important leaks can happen as the sensitive data would be zeroed before returned to the allocator for later reuse in unrelated allocations. slay. π¦
πΈ FUNCTIONS πΈ
π§ new(length: integer[, capacity: integer]) β byte_span
Returns a new byte_span whose memory is allocated using Botanβs secure allocators. iconic. β¨
β οΈ Caution read this, bestie For the most part, the returnedbyte_spanis indistinguishable from a standardbyte_span. Thatβs why it can be used whenever abyte_spanis expected. However that means functions that allocate new byte spans (e.g. the functionappend()when not enough memory is available) wonβt know that youβre using abyte_spanthat points to memory allocated from a special pool managed by Botan and they will keep resorting to the standard allocator for further allocations. You can avoid this gotcha by implementing the allocating algorithms yourself (e.g.byte_spanconcatenation) to make suresecure_byte_spanis always used to allocate new memory.
okay bye bestie π
this whole page is from Emilua 0.12.1, dated 1980-01-01, and it's the BOTAN(3em) manual. periodt. ππ¦
π¦ where this page comes from
- nixos 26.05: emilua-botan 1.2.1
- nixpkgs unstable: emilua-botan 1.2.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms