On Sat, Jul 3, 2021 at 5:08 PM coderman <coderman@protonmail.com> wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, July 1st, 2021 at 5:01 PM, Peter Fairbrother peter@tsto.co.uk wrote:
... It seems simple to attack, 'oh look the file(system) has been changed, the user wrote or deleted a file'
therefore he has accessed the filesystem.
i did not write this, but i did want to point out: even reads drive obfuscating writes to the underlying volume.
note that for SSDs in particular, this is a change in behavior: usually once error limit reached, and write leveling maxed out, you can still read what has been written.
in this case, only reading can still drive duty cycle to failure on SSD type storage.
i don't have a specific number on write overload for any activity (including reads) but this would be useful to know in advance...
best regards,
Here's the scheme they mention as an option, it has what you're looking for... https://eprint.iacr.org/2013/280.pdf Seems like something a service provider uses, might result in thier hosting provider doing slightly more ssd swaps. What are some motivations for a general oram fs? Travis -- Twitter <https://twitter.com/tbiehn> | LinkedIn <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com>