oramfs - ORAM filesystem written in Rust

[Travis Biehn]

On Sat, Jul 3, 2021 at 5:08 PM coderman <coderman at protonmail.com> wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, July 1st, 2021 at 5:01 PM, Peter Fairbrother peter at 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 3186 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20210703/f7a30c3a/attachment.txt>