Feature Branch

Current feature branch for this issue: not created yet.

Progress

• Make note of external sources of code and copyrights/licences.
• Update/add comments when additional sources are used.

---

Background

Because of the nature of the application, it is going to be based upon various sources, including algorithms, Bitcoin Improvement Proposals (BIPs), Satoshi Labs Improvement Proposals (SLIPs), Requests For Comments (RFCs), articles, code samples, my original code, etc.

Ordinarily, I would just add the copyright lines to the LICENSE file if published under a compatible licence and/or requires the copyright notice line(s) be included in any subsequent work.

The purpose of this issue is to make a note of the sources of code the code in this repository is built upon, to expand upon the copyright lines in the LICENSE file.

Feature Branch

Current feature branch for this issue: feature/issue-1/gui-2.

Progress

• Create RSA keypair with private key wrapped by TPM.
• Obtain my own OID, partition OID, and then assign an OID for the key purpose of LTO Encryption Manager account key management (wrapping/encrypting/decrypting/signing/verifying).
• Use secure desktop to create/recreate account AES keys from BIP39 seed phrase.
• Encrypt (wrap) account keys using RSA public key.
• Create account record file for each account. File contains wrapped AES key, seed and account fingerprints, and RSA signature of the data.
• Merge into main branch.

---

Background

At present, the application only takes hexadecimal entropy or a BIP-0039 mnemonic seed and calculates and displays the other, as well as the BIP-0039 derived binary seed, the derived SLIP-0021 master node (m) derivation key, and the symmetric keys for nodes m, m/"SLIP-0021", m/`"SLIP-0021"/"Master encryption key", and m/"SLIP-0021"/"Authentication key".

These tests in the UI are no longer necessary as they were converted to unit tests in commit b7d7cb4. The BIP-0039 tests use the vectors.json file linked from the bip0039 specification (using BIP-0039 passphrase TREZOR). The SLIP-0021 tests use a slip0021-vectors.json file in a similar format, that currently only contains the example in the slip0021 specification (using no BIP-0039 passphrase).

An attempt was made to clear things from memory when they are no longer needed in commits beb65b3 and 2384bcb, although some continued use of strings currently remain. I considered using PasswordBox and SecureString, but until Dictionary<string, int> supports key lookups using ReadOnlySpan<char> and type SensitiveData is available, it would be too much work to remove the use of string.

Mnemonic seeds are also too long to not display the input text, and it is unclear if PasswordRevealMode in the UWA version of PasswordBox allocates a string if the password is revealed. TextBox can have a CustomDictionary for spell check, but such dictionaries augment the system dictionaries rather than replace them - it isn't possible to force spell check to only use the BIP-0039 word list.

Until there is a suitable solution to the issues highlighted in the previous two paragraphs, the use of TextBox and string will remain, because the alternative is to spend a huge amount of time creating NotTextBox and NotDictionary (plus implementing ReadOnlySpan<char>.Split(), ReadOnlySpan<char>.Normalize(), etc.).

A lot of code was split from MainWindow.xaml.cs in commit 89ab9cb and slightly refactored into sub-namespaces and static public functions. Although it could potentially split into a separate library, watfordjc/GameChatLite#2 brought this repository back to the top of the unfinished code stack because I also intend to use SLIP-0021 derived keys in the GameChatLite server.

That brings us to the issue: retaining secret data, and doing it securely.

The Issue

LTO-Encryption-Manager needs to be able to calculate the symmetric key for a given LTO tape's barcode without requiring the user to enter their BIP-0039 mnemonic seed every time. Deriving deterministic keys using SLIP-0021 was chosen because LTO uses AES-256-GCM (256 bit keys) and SLIP-0021 uses HMAC-SHA512 to derive a 512-bit hash for a given node, with the first half defined as a 256-bit derivation key and the second half a 256-bit symmetric key. The 256-bit symmetric key for a given node can therefore be directly used as an AES-256-GCM symmetric key, and the node's derivation path can be based on the tape's label/barcode.

Similarly, it is proposed that GameChatLite's server will use 64-bit snowflake IDs for user IDs, device IDs, and state IDs. A new installation is initially identified as a new device ID (stored in a cookie signed using HMAC-SHA256 with the server's key), a state ID (passed in a query variable to the OAuth2 server, along with a signature of the state ID and device ID signed using the state ID's symmetric key), and on success a new device ID is generated and linked to a new/existing user ID given the user ID supplied by the OAuth2 server.

In order to avoid saving state and potential personal identifiers, the state ID will have a validity window and will be added to a blacklist once used, with the blacklist getting pruned as old IDs become too old to be valid. The server will only store device IDs that are linked to user IDs, with new_session device IDs having an as yet undecided validity period (5 days?) and only existing in the user's browser. Likewise, the state IDs will only exist in the user's browser as a query parameter. In order to solve the question How can a server know it generated and linked two IDs without storing either of them or anything about them? I again considered SLIP-0021. Given the limited lifetime of the IDs, HMAC-SHA256 using a 256-bit (32 byte) seemed sufficient.

So, I have two SLIP-0021 use cases, and code that can create keys for (currently hard-coded) derivation paths. Both derivation path schemes are to use a reverse hostname as the first-level label and an ASCII number at the second-level to support key rollovers (the first key would be at derivation path m/"uk.johncook.slip-0021.usage-description"/"0"). I need to store three things for each first-level label: the first-level label, the key rollover count, and the derivation key for that node.

Given Windows 11's announcement had me check my devices had built-in TPM support, my initial thoughts are to work out how to encrypt and store the derivation keys in .NET 5, using the TPM in some way. This will probably involve CNG rather than CryptoAPI.

First-Level to Account-Level

This issue has been renamed to focus on the uk.johncook.slip-0021.lto-aes256-gcm SLIP-0021 schema and progress the development of this application.

Storing the account-level derivation key (i.e. m/"uk.johncook.slip-0021.lto-aes256-gcm"/"0"/"0"/"0" rather than m/"uk.johncook.slip-0021.lto-aes256-gcm") will potentially require re-entering the recovery seed more often, but it will simplify what needs to be done to get the application to the point where it is minimally functional.

Feature Branch

Current feature branch for this issue: not created yet.

Progress

• Create a task list for this issue.

---

Background

The intended purpose of this application is to send a symmetric encryption key to an LTO drive for use in encrypting/decrypting data written/read to/from an LTO cartridge.

In the case of new cartridges that already have barcodes applied to them, the barcode is unlikely to be stored in the MAM/LTO-CM chip.

In the case of full tape encryption (i.e. the entire tape is encrypted), the encryption key needs to be set on the drive before the cartridge is formatted. If a cartridge is formatted LTFS and then encrypted, the drive needs to be in mixed mode to be able to read unencrypted data (such as the index file).

When formatting a tape in a drive that isn't part of a tape library, you are asked for the cartridge's barcode.

By being able to scan the barcode on a new cartridge before inserting it into a tape drive, the application can make the barcode available for copying/pasting to the formatting software.

Additionally, once detection of cartridge insertion/removal is added, the application could query the drive to see if the inserted cartridge has been initialised and whether or not a barcode is stored in MAM. If the cartridge doesn't have a barcode stored in MAM, the application could potentially prompt "Blank Barcode: Write scanned barcode to cartridge memory?" and then write the barcode to MAM.

I believe HPE tape formatting software reads the current barcode from MAM and prepopulates the barcode in the prompt, so saving to MAM may negate the copying/pasting step.

Feature Branch

Current feature branch for this issue: not created yet.

Progress

• Create a task list for this issue.

---

Background

This issue was originally at watfordjc/LTO-Encryption-SPTI#5

LTO-Encryption-SPTI is currently a linear Win32 C application.

LTO-Encryption-Manager has now reached the point where it needs to use SPTI.

The goal of this issue is to implement the most basic functions as library functions, starting with opening a file descriptor for the tape drive, using a Win32 API to obtain the serial number and WWN/LUN, and then closing the file descriptor.

The Data Backups and Archiving Project contains this loosely related note:

Improve design of LTO-Encryption-SPTI

At the moment there is a lot of repetitive code, redundant code leftover from the template, and the code isn't that clean.
There is also a lot of debugging code and output and very little data being retained after it is queried.
The data in the SCSI VPDs, for example, are mostly burned into the drive's persistent non-volatile memory at the time of manufacture or during a firmware update.
Translate the SCSI pages into structured variables that can be referenced rather than doing the byte and bit stuff inline.