TL;DR: This article is a design exploration rather than a cryptographic proposal. It examines whether splitting encrypted files into independently stored fragments can reduce metadata leakage and make encrypted storage harder to analyze. The approach adds complexity and does not strengthen encryption itself.

1. The one-file-one-object problem

When people talk about file encryption, they usually focus on protecting file contents. If an attacker obtains a disk or a backup, the documents remain unreadable without the encryption key.

However, encryption does not necessarily hide everything about the storage.

Many encrypted storage systems follow a simple model: one original file becomes one encrypted object. The contents are protected, but the overall structure often remains visible. An observer may still be able to see how many objects exist, their approximate sizes, when new objects appear, and which objects change over time.

None of this reveals the plaintext directly. Still, it can provide useful clues about how the storage is organized and how it evolves.

This type of information is commonly referred to as metadata leakage. The exact amount of exposed metadata depends on the storage system, but the general problem remains the same: encryption protects data, while some information about that data may still be observable.

This raises an interesting question.

If encryption hides the contents of files, can we also make the structure of encrypted storage harder to analyze?

2. Fragmenting encrypted files

One possible way to reduce metadata exposure is to stop treating each encrypted file as a single storage object.

The file is encrypted as usual, but the resulting ciphertext is then split into multiple fragments that are stored independently.

Instead of a storage system containing a collection of encrypted files, the storage now contains a collection of encrypted fragments. An observer can still see the objects themselves, but determining which fragments belong together becomes less straightforward.

At first glance, this appears to improve privacy. The data remains protected by encryption, while the storage structure becomes less obvious.

It is important to keep the goal of fragmentation in perspective, however.

Fragmentation does not strengthen encryption, make key recovery harder, or replace proper key management. The confidentiality of the data still depends entirely on the underlying cryptographic mechanisms.

Its purpose is much narrower: to reduce the amount of structural information that can be inferred from the storage itself.

The question, therefore, is not whether fragmentation can replace encryption. It cannot.

The real question is whether fragmentation can make an already encrypted storage system more difficult to analyze.

3. Fragmenting files into a fixed number of parts

The simplest fragmentation strategy is to always split a file into the same number of fragments. For example, every encrypted file could be divided into 8, 16, or 32 parts regardless of its size.

This removes the direct one-file-one-object relationship, but it introduces a different problem.

When the number of fragments is fixed, fragment size becomes directly linked to the size of the original file. Larger files produce larger fragments, while smaller files produce smaller ones.

For example, splitting an 80 MB file into eight parts produces fragments of roughly 10 MB each. The same approach applied to an 8 MB file produces fragments of about 1 MB.

As a result, size-related metadata does not disappear. It simply moves from the file level to the fragment level. Fragments belonging to the same file tend to have similar sizes, making them easier to group and analyze.

This creates an interesting tradeoff. The direct relationship between a file and a storage object is removed, but a new relationship emerges between the file and the size of its fragments.

For that reason, splitting files into a fixed number of parts is best viewed as a first step rather than a complete solution. It obscures the storage structure, but still leaves patterns that can be observed through fragment sizes.

4. Fragmenting files into fixed-size parts

The limitations of the previous approach suggest a natural alternative: instead of fixing the number of fragments, fix their size.

For example, all encrypted data could be split into 1 MB blocks. Most fragments would then have the same size regardless of the original file.

This avoids the direct relationship between file size and fragment size, but it introduces a different form of metadata leakage.

With fixed-size fragments, file size is reflected in the number of fragments produced. A 400 MB file generates roughly 400 objects, while a 40 KB file may still occupy a single fragment.

In other words, the storage no longer reveals information through fragment sizes, but it still reveals information through fragment counts.

This becomes particularly noticeable for small files. A file that fits entirely within a single block effectively falls back to the familiar one-file-one-object model.

There is also a practical tradeoff when choosing a block size. Small blocks improve fragmentation but can generate huge numbers of objects for large files. Large blocks reduce object counts but provide little benefit for smaller data.

Compared to splitting files into a fixed number of parts, this approach hides metadata more effectively. However, the relationship between file size and storage structure remains visible, just in a different form.

5. Adaptive fragmentation

The previous approaches share a common weakness: they apply the same rule to every file.

When the number of fragments is fixed, file size is reflected in fragment size. When fragment size is fixed, file size is reflected in fragment count.

A more flexible approach is to choose the fragment size from a predefined set.

KB = 1024
MB = 1024 * KB

FRAGMENT_SIZES = [
    1 * KB,
    2 * KB,
    4 * KB,
    8 * KB,
    16 * KB,
    32 * KB,
]

Instead of treating every file identically, the system selects a size that produces a reasonable number of fragments.

For example, the goal might be to keep most files within a range of roughly 8–32 fragments.

TARGET_MIN = 8
TARGET_MAX = 32

for fragment_size in FRAGMENT_SIZES:
    count = math.ceil(file_size / fragment_size)

    if TARGET_MIN <= count <= TARGET_MAX:
        return fragment_size

This avoids the extremes of the previous strategies. Large files no longer explode into thousands of fragments, while smaller files are less likely to remain represented by a single object.

An additional benefit is that many unrelated files end up using the same fragment sizes. The storage gradually fills with large numbers of similar-looking objects, making size-based analysis less reliable.

The choice of fragment sizes, however, introduces its own tradeoff.

A large number of size options allows more precise tuning but also creates more distinct size categories within the storage. Fewer size options reduce the amount of information available to an observer, but make fragmentation less adaptable.

In practice, a relatively coarse scale is often sufficient:

FRAGMENT_SIZES = [
    1 * KB,
    4 * KB,
    16 * KB,
    64 * KB,
    256 * KB,
    1 * MB,
    4 * MB,
    16 * MB,
]

Even with adaptive sizing, deterministic behavior can still reveal patterns. A file of a particular size will usually be fragmented in exactly the same way every time.

One way to reduce this predictability is to introduce a small amount of randomness.

Instead of selecting a single "best" size, the system can choose from several nearby candidates.

best_index = FRAGMENT_SIZES.index(best_size)

candidates = FRAGMENT_SIZES[
    max(0, best_index - 1):
    min(len(FRAGMENT_SIZES), best_index + 2)
]

fragment_size = random.choice(candidates)

For example, if 1 MB is considered optimal, the system might choose 512 KB, 1 MB, or 2 MB. All options remain reasonably close to the target fragmentation level, but the resulting storage layout becomes less predictable.

As a result, two files of the same size may be fragmented differently, and even uploading the same file twice can produce different fragment layouts.

The relationship between file size and storage structure does not disappear entirely. However, it becomes significantly less direct than in either of the fixed-rule approaches.

6. The reconstruction map

At this point, a practical question becomes unavoidable.

If a file has been split into dozens or even hundreds of encrypted fragments, how does the system know which fragments belong together?

The answer is that fragmentation requires an additional metadata structure that describes how files can be reconstructed. We can call it a reconstruction map.

In its simplest form, it might contain information such as:

file_id
original_name
original_size
fragment_ids[]
fragment_order[]
checksum/hash

The reconstruction map stores the relationships between files and fragments, allowing the system to locate the required objects and reassemble them in the correct order.

Without it, the fragments are simply a collection of unrelated encrypted objects.

This observation reveals an important property of fragmentation.

Fragmentation does not eliminate metadata. Instead, it relocates the most valuable metadata into a dedicated structure.

In fact, the reconstruction map contains much of the information that fragmentation attempts to hide from an external observer. It knows which fragments belong together, how many fragments exist, and how they should be reassembled.

For that reason, storing such information alongside the fragments in plaintext would defeat much of the purpose of fragmentation. In practice, the reconstruction map would need to be protected separately, whether as an encrypted database, an encrypted manifest, or a dedicated secrets store.

This leads to an important conclusion.

The structure of the storage never truly disappears. Fragmentation merely makes that structure less visible and concentrates the knowledge required to reconstruct it into a separate component that must be protected just as carefully as the data itself.

7. Correlating fragments by creation time

Even if fragments contain no identifying information and are assigned completely random identifiers, one source of metadata still remains: time.

When a file is written to storage, all of its fragments are typically created within a very short period. As a result, they often share similar timestamps and appear in the filesystem as part of the same operation.

For an observer, this can become another useful signal. A group of objects created at nearly the same moment is likely to be related, even if their contents and identifiers reveal nothing.

The issue extends beyond timestamps themselves. Most filesystems maintain additional metadata associated with each object. For example, ext4, XFS, and UFS store information such as creation times, modification times, sizes, and filesystem-specific records.

None of this metadata directly reveals which fragments belong together. However, it can provide enough clues to support correlation and analysis.

One possible way to weaken these signals is to periodically recreate some existing fragments.

Instead of leaving fragments untouched after their initial creation, the system can occasionally select a subset of them, generate new identifiers, and write replacement objects containing the same encrypted data.

The contents remain unchanged, but the associated filesystem metadata is refreshed.

Over time, this makes creation timestamps less reliable as an indicator of when data originally entered the system. Fragments that were once created together gradually become harder to distinguish from fragments produced by unrelated operations.

This does not eliminate time-based metadata, but it can make temporal analysis significantly less useful.

8. The reshuffling algorithm

Once fragments begin to be recreated over time, the next question becomes obvious: how many should be reshuffled during each operation?

Recreating every fragment would be the most effective way to break temporal relationships, but it would also be prohibitively expensive. Even a minor change could trigger a rewrite of the entire storage.

At the opposite extreme is doing nothing at all, leaving timestamp-based correlations intact.

A practical solution lies somewhere in between.

One approach is to let the amount of reshuffling grow much more slowly than the storage itself. For example:

shuffle_count = ceil(log2(total_fragments + 1))

This produces roughly the following behavior:

100 fragments      → 7 recreations
1,000 fragments    → 10 recreations
10,000 fragments   → 14 recreations
100,000 fragments  → 17 recreations

In practice, minimum and maximum limits are usually desirable:

shuffle_count = min(
    MAX_SHUFFLE,
    max(
        MIN_SHUFFLE,
        math.ceil(math.log2(total_fragments + 1))
    )
)

With this approach, temporal relationships gradually become less reliable without forcing the system to constantly rewrite large portions of the storage.

The goal is not to erase the history of the data completely. It is simply to make that history less obvious and less useful for analysis.

9. The cost of fragmentation

By this point, fragmentation may seem like an attractive way to reduce metadata exposure. However, these benefits come at a cost.

The most obvious consequence is the growing number of storage objects. In a traditional system, one file usually corresponds to one object. With fragmentation, the same file may be represented by dozens or even hundreds of fragments.

This increases the amount of filesystem metadata, the number of objects that must be tracked, and the overall complexity of storage operations.

The reconstruction map introduces additional overhead as well. Every fragmented file requires metadata describing which fragments belong together and how they should be reassembled. As the number of fragments grows, so does the amount of information needed to manage them.

File operations also become more expensive.

Reading a file requires locating all relevant fragments and reconstructing them in the correct order. Writing a file requires encryption, fragmentation, metadata updates, and, potentially, reshuffling of existing fragments.

Storage scalability becomes another consideration.

If files are fragmented aggressively, object counts can increase much faster than the amount of stored data. A storage system containing 100,000 files may easily end up managing millions of fragments.

Modern filesystems can handle such workloads, but large object counts can affect indexing, backup operations, directory traversal, and general maintenance tasks. In filesystems such as ext4, every object also requires its own inode, making metadata consumption a practical concern rather than a purely theoretical one.

Perhaps the most significant cost, however, is architectural complexity.

A fragmented storage system requires reconstruction maps, fragment management, reassembly logic, reshuffling mechanisms, consistency guarantees, and recovery procedures. Over time, it begins to resemble a second filesystem built on top of the existing one.

For that reason, fragmentation is difficult to describe as a free security improvement.

It can reduce the amount of metadata available to an observer, but it achieves this by introducing additional overhead, greater implementation complexity, and new operational challenges.

Conclusion

Encryption protects the contents of data. Fragmentation can make the structure of that data more difficult to analyze.

By breaking the direct relationship between files and storage objects, a fragmented storage system can reduce some forms of metadata leakage and make storage layouts less transparent to an observer.

At the same time, fragmentation does not strengthen encryption and does not eliminate metadata entirely. Much of the structural information is simply moved into a reconstruction mechanism that must be protected separately.

The approach also introduces significant costs. More objects must be managed, additional metadata must be maintained, and the overall architecture becomes considerably more complex.

As a result, fragmentation is best viewed as a complementary technique rather than a replacement for encryption. It addresses a different problem: not protecting the contents of data, but reducing the amount of information that can be inferred from the structure of the storage itself.