Autonomys Auto Drive Encryption Specification
Introduction
The Autonomys Decentralized Storage Network (DSN) implements client-side encryption for user files. When you upload a file to the Autonomys network, it's encrypted on your device before being transmitted to the network. This means that the decentralized network stores encrypted versions of your files, and only someone with the correct password can decrypt and access the original content.
Client-Side Encryption Process
Files are encrypted entirely on the client side before any data is sent to the network. The encryption happens on your device using your password, and the resulting encrypted data is what gets transmitted to and stored by the DSN.
The encryption process uses established cryptographic algorithms and follows a chunked approach where files are broken into pieces and each piece is encrypted separately. This allows for efficient processing of files of any size and enables streaming operations.
The beauty of this approach is that it eliminates trust requirements. You don't need to trust the network operators, storage providers, or any other party involved in the decentralized network. Even if someone gains access to the stored data, they would only see encrypted information that appears completely random without your password.
The Encryption Algorithm: AES-256-GCM
Autonomys DSN uses AES-256-GCM, which is considered the gold standard for file encryption. AES stands for Advanced Encryption Standard, and the "256" refers to the 256-bit key length, which provides exceptional security. To put this in perspective, even with the most powerful computers available today, it would take longer than the age of the universe to break this encryption through brute force attacks.
The "GCM" part stands for Galois/Counter Mode, which is a special way of applying the AES encryption that provides two important benefits. First, it encrypts your data so that it becomes unreadable to anyone without the key. Second, it creates an authentication tag that acts like a tamper-evident seal - if anyone tries to modify your encrypted file, even by a single bit, the decryption process will immediately detect this and refuse to proceed.
This dual protection ensures both confidentiality (your data stays private) and integrity (your data stays unmodified). The same encryption standard is used by governments and major corporations worldwide to protect their most sensitive information.
Password-Based Key Generation
Since users typically work with passwords rather than cryptographic keys, the system uses PBKDF2 (Password-Based Key Derivation Function 2) to convert passwords into the encryption keys needed for AES-256.
The key derivation process works as follows: your password is combined with a randomly generated 32-byte value called a "salt." This combination is then processed through the SHA-256 hash function exactly 100,000 times. This repetitive process serves an important security purpose - it makes password-based attacks computationally expensive and time-consuming.
Each file gets its own unique 32-byte salt, which is generated using cryptographically secure random number generation. This salt is stored with your encrypted file because it's needed for decryption, but it doesn't compromise security - its purpose is to ensure that even if two people use the same password, their encryption keys will be completely different.
How Files Are Encrypted
The encryption process breaks files into chunks of 1 megabyte each and encrypts each chunk separately. This chunked approach allows for efficient processing of large files and enables streaming operations where encryption can begin before the entire file is available.
For each chunk of data, the system generates a unique 16-byte initialization vector (IV) using cryptographically secure random number generation. This IV ensures that identical chunks of data will produce different encrypted outputs, which is important for security.
The encryption process for each chunk combines the original data with its unique IV and processes it through the AES-256-GCM algorithm using the key derived from your password. The result is an encrypted chunk that contains both the encrypted data and an authentication tag generated by the GCM mode.
File Structure in the Decentralized Network
When your file is stored on the Autonomys DSN, it has a specific structure that enables secure decryption later. The encrypted file begins with the 32-byte salt that was used during key derivation. This salt is followed by a series of encrypted chunks, each containing a 16-byte initialization vector followed by the encrypted data and its authentication tag.
The file structure is designed to be self-contained, meaning everything needed for decryption (except your password) is included in the encrypted file itself. The salt and initialization vectors are not secret and can be safely stored alongside the encrypted data - their purpose is to ensure uniqueness and prevent certain types of cryptographic attacks.
Privacy in a Decentralized Environment
One of the most compelling aspects of Autonomys DSN's encryption approach is how it addresses the unique privacy challenges that arise in decentralized storage networks. Unlike traditional cloud storage where you must trust a single company with your data, decentralized networks involve multiple independent parties who participate in storing and serving your files. The client-side encryption creates a privacy layer that works regardless of how many parties are involved in the storage process.
When your encrypted file enters the DSN, it gets processed through the network's multi-layered architecture. Nodes in the content delivery network layer, farmers caching pieces in the distributed hash table layer, and participants in the archival storage layer all handle only encrypted data. From their perspective, your file appears as cryptographically random data - they cannot determine what type of content you're storing, how large your original files are, or any meaningful information about your data.
This privacy protection works at multiple levels of the network interaction. When farmers receive pieces of your encrypted file for storage in their plots, they're working with data that has already been encrypted on your device and potentially further processed by the DSN's encoding schemes. The encryption ensures that even if someone gained access to multiple storage locations across the network, they would only find encrypted fragments that provide no insight into your original content.
The decentralized nature of the network actually enhances privacy in some ways compared to centralized systems. There's no single point where your complete file exists in unencrypted form outside of your own device. The distribution across multiple independent storage providers means that no single party has a complete view of your storage activity, and the encryption ensures that partial views remain meaningless.
This approach also provides privacy protection that persists over time. As the network evolves, as storage providers join and leave, and as the DSN's architecture develops, your files remain protected by the same client-side encryption that was applied when you first stored them. The privacy guarantees don't depend on the ongoing security practices of any particular storage provider or network operator.
Performance and Efficiency Considerations
The encryption system is designed to be efficient while maintaining strong security. The choice of 1 MB chunks strikes a balance between memory usage and computational efficiency. This chunking allows files to be processed in a streaming fashion, meaning you don't need to load entire large files into memory at once, and encryption can begin before the entire file is available.
AES-256-GCM is specifically chosen for its performance characteristics. Modern processors often include hardware acceleration for AES encryption, making the process very fast. The GCM mode is also optimized for performance while providing the authentication features needed for secure storage.
The computational overhead of the encryption process is minimal for the actual encryption and decryption operations. The most time-consuming part is the initial key derivation from your password, which is intentionally slow for security reasons. However, this only happens once per file, and the derived key is then used efficiently for all chunks of that file.
Last updated
Was this helpful?