[tahoe-lafs-trac-stream] [tahoe-lafs] #2018: padding to hide the size of plaintexts

[tahoe-lafs]

#2018: padding to hide the size of plaintexts
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  nejucomo
         Type:           |     Status:  new
  enhancement            |  Milestone:  undecided
     Priority:  normal   |    Version:  1.10.0
    Component:  code-    |   Keywords:  confidentiality privacy compression
  encoding               |  newcaps research
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by nejucomo):

 Replying to [comment:8 zooko]:

 [...]

 > My feeling is, if I want to make progress on this I should ignore the
 whole idea of a threat model and move ahead with implementation! That
 sounds wrong, but what's the next-step on the threat model?

 I wouldn't want to implement this feature yet without hearing more
 people's answers to these questions:

 * Do we believe range updates compromise the benefits of padding?  Under
 what conditions?
 * Will the implementation only work for files which disallow range updates
 (such as immutables or `SDMF` files)?
 * If so, how will the UI indicate to users which files / file types have
 which size confidentiality features?
 * -or, will users decide whether they prefer range updates or size
 confidentiality on a global scale, and change a configuration setting?
 * What should the default setting be?
 * Will we spend more effort improving confidentiality in this way, or more
 time improving update efficiency, or will we split our time between two
 features which may counteract each other?
 * Are there other approaches to efficient update that work well with other
 approaches to size confidentiality?

 For the last question, I'm interested in the proposed `LDMF` format which
 would store file data as snapshots with deltas.  The range offsets in the
 deltas can be encrypted for confidentiality.  The file content of the
 delta itself could be padded.  Now a storage operator can see the timing
 and padded size of deltas, but not which parts of a file they update, nor
 the exact size of the delta contents.

 So that last question is an example of how we might realize that we'd
 rather invest engineering into snapshot+delta formats instead of flat
 files with range updates.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2018#comment:12>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage