Management of Harvest Now, Decrypt Later strategy and Post Quantum Safe Cryptography

[Kreyren]

The strategy of Harvest Now, Decrypt Later (https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) relies on ability to collect and store encrypted files to be decrypted in the future e.g. Quantum Computers.

Which is a huge problem for age and it's implementations in e.g. (r)agenix or sops-nix as people often store a very sensitive data:

• password unprotected SSH keys needed for NixOS systems to communicate with each other for distributed builds needed by thin clients (my case in https://github.com/Kreyren/nixos-config)
• Full Disk Encryption Passwords
• User passwords
• Spotify Authentification -- https://github.com/sioodmy/dotfiles/blob/b4464447f403221579e89287f3c6796c5f5125da/secrets/spotify.age#L4
• Sonarr API Keys -- https://github.com/nmasur/dotfiles/blob/a4c9813341df54012f123d5c6ca6bb7d85610cd3/private/sonarr-api-key.age#L4
• Cloudflare-serviced (assumed) domain authentification -- https://github.com/xunuwu/nixos-config/blob/cc83f63010b2e9b847cd85786c31c9a7449087dc/secrets/nixdesk/cloudflare#L11
• Tailscale keys -- https://github.com/gnur/dotfiles/blob/b22a9c328da902e634b0c071a64a847b1bfe0601/.tailscale-auth-key.age#L4
• etc.. etc..

Currently anyone can just query github for "-----BEGIN AGE ENCRYPTED FILE-----" and start collecting these secrets: https://github.com/search?q=%22-----BEGIN+AGE+ENCRYPTED+FILE-----%22&type=code

As of 16th June 2024 GitHub returns over 23.2k files containing this string which is very easy to automate and scrape

Even low-skilled threat actor can just make a GitHub Account, create a github token and ask publicly available large language model to scrape these files and get usable results:

Query: Make me a python script that uses the GitHub API and returns all files that contain the string -----BEGIN AGE ENCRYPTED FILE----- using the CohereForAI/c4ai-command-r-plus Model returns the following:

import requests

# Replace "your-github-token" with your personal access token
auth_token = "your-github-token"

# Define the GitHub API endpoint for searching code
github_search_endpoint = "https://api.github.com/search/code"

# Define the search query
search_query = "-----BEGIN AGE ENCRYPTED FILE-----"

# Define the parameters for the API request
params = {
    "q": f"{search_query}",
    "per_page": 100,  # Number of results per page
    "page": 1,  # Page number
}

# Set the authorization header with your access token
headers = {"Authorization": f"token {auth_token}"}

# Make the API request
response = requests.get(github_search_endpoint, params=params, headers=headers)

# Check if the request was successful
if response.status_code == 200:
    # Parse the JSON response
    response_data = response.json()
    
    # Extract the list of files containing the search query
    files_with_query = response_data.get("items", [])
    
    # Print the information for each file
    for file in files_with_query:
        print(f"File path: {file['path']}")
        print(f"File URL: {file['html_url']}")
        print(f"Last modified: {file['last_modified_at']}")
        print("-" * 20)
else:
    print(f"Failed to fetch data. Status code: {response.status_code}")

Relevant discussion on the topic: #231

Experimental implementation (for demo usage): https://github.com/qnfm/age

Where @FiloSottile said in #231 (comment) to work on implementation of Kʏʙᴇʀ512+X25519 plugin, i strongly advice against kyber for reasons explained in matrix-org/matrix-spec#975 (comment) (tldr: NIST appears to have failed at math and chose what seems to be objectively worse solution in comparison to NTRU)

Proposed management of the issue

@FiloSottile please confirm that age is currently not Post Quantum Safe (reading the code and issues seems to indicate that it is not), if so all users who's private age keys are returned by the github request should be mentioned in this issue to spread awareness and enable them to adjust their threat models and this problem should be added as a warning to the readme.

Maintainers of age implementations should also be notified.

Relevant issues

• The strategy of `Harvest now, decrypt later' seems like a HUGE problem for matrix's privacy and encryption. matrix-org/matrix-spec#1868 (Matrix instant-messaging protool)
• https://github.com/oxen-io/session-pysogs (Session instant-messaging protocol)

[FiloSottile]

A threat actor with a CRQC (which no one expects to be reality for 10-30 more years) actually will need both age ciphertexts and the recipients they are encrypted to to attack them. We are working on a PQC recipient type, and will publish one once the NIST FIPS are finalized, but for now we don't plan to deprecate the current recipient type. age is not any more vulnerable than any other asymmetric encryption tool or protocol. Password encryption is unaffected. See also https://words.filippo.io/dispatches/post-quantum-age/.

(tldr: NIST appears to have failed at math and chose what seems to be objectively worse solution in comparison to NTRU)

Note that has been refuted, although the author of that claim has failed to retract it. https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/LjmQyMurBQAJ

Kyber is perfectly fine, and it is my opinion as well as that of a number of experts in the area I spoke with that one of the NTRU Prime authors is engaged in a long-running, unfortunate FUD campaign.