[Comevius]

This works like TrueCrypt hidden volumes, which are volumes created in the free space of volumes.

This is not secure against multi-snapshot adversaries, like those who can take multiple snapshots of your storage at different times.

The solution is to hide the access pattern, for example by using a write-only oblivious RAM.

I'm currently working on a cloud database that uses searchable encryption. In a database the smallest things can hurt you, both the access and search pattern (must hide the encrypted data that satisfies the query condition or multiple query conditions, the volume of that data, and hide which queries are identical). And the attacker can have auxiliary information (known-data, known-query, inference). On top of that the database must be verifiable (authentical, sound, complete, fresh). Encrypted and non-encrypted data might be searched together (partitioned data security). A database must be resizable, that's the point of a cloud database. And then there is data sharing. And it must be cheap. The existing solutions in the literature either compromise security or practical efficiency.

[anonypla]

TrueCrypt was abandoned/discontinued and forked 7 years ago and replaced by Veracrypt ... Just sayin ...

[Comevius]

TrueCrypt has other forks and implementations like tcplay.

[temptemptemp111]

Can you share more about this project? Thoughts on management engined access to registers and DMA being a weakness?

[Comevius]

Sure, the project is called Endpipe and it's an attempt to create a privacy-preserving cloud database. The idea is a Google Cloud Firestore alternative that works offline and synchronizes in real-time, but without the data being accessible to the server. The encryption key never leaves the client or trusted proxy.

We want to keep sensitive data like Protected Health Information (PHI) from getting into the wrong hands. Any hands really, but yours. You own your data.

https://www.inkandswitch.com/local-first.html

Endpipe is offline-first and needs client storage to be secure and practically efficient, so it's different than most cloud databases. The client is trusted, and there can be also a trusted proxy, the server is untrusted. The server is distributed and maliciously secure, it can have arbitrary number of Byzantine-faulty replicas. It is a multi-model database (document, object and file) with range queries, automatic indexing and eventual consistency with explicit causality, which is used for conflict resolution. There are conflict-free operations for collaboration. It is multi-platform, the client core is being written in C/Zig/WASM on top of SQLite. Android, iOS, Linux, macOS and Windows are supported, eventually the web will be once there is a better File System Access API with origin private file system support. A Dart/Flutter library is the first priority, that is the beachhead. The supported data types are Bool, Int, BigInt, Double, String, DateTime, List<E>, Set<E>, Map<K,V>, Uint8List, Uint16List, Uint32List, Uint64List, Int8List, Int16List, Int32List, Int64List, Float32List and Float64List. Collections are generic, E, K and V identifies the type of objects they can store, which make collections homogeneous, but heterogeneous collections are also possible by not specifying the type. Our serialization format is space efficient, integers up to 127 are represented by one byte, smaller and larger integers use a variable-length (1 to 9 bytes) zigzag integer encoding. There are holes for supporting arbitrary-precision binary and decimal floating point numbers in the future. Large values up to 16 TiB are supported. Query results are available as data streams, they receive realtime updates, however Endpipe can delay updates for query smoothing. Endpipe can issue fake queries, prefetch or buffer data from the server data structure, which is essentially a dynamic volume-hiding encrypted multi-map with forward and backward privacy.

> management engined access to registers and DMA being a weakness

If you are talking about Intel ME on the client, we trust the client, we have no other choice. Client-side encryption is planned, it would offer some protection against snapshot adversaries, but not against a persistent adversary that has access to your device. History independence to be able to do secure deletion is not a goal.

On the server it doesn't matter whether it is curious or malicious, our threat model is a persistent adversary that has continuous total access to the server. Endpipe uses the server interactively to store and retrieve encrypted data, and the server is allowed to spy and lie, it's only function is to send the original data back, which the client can verify.