diff options
| author | Joey Hess <joeyh@joeyh.name> | 2017-03-11 11:49:03 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2017-03-11 11:49:03 -0400 |
| commit | f06692d75041bd646539eb79f4809666038d8f5b (patch) | |
| tree | eaa1d3a5a94ff136e767d868441334742dfa9b19 | |
| parent | 99a5321aab580b2caa62559d3b6c016ccf15eb70 (diff) | |
| download | keysafe-f06692d75041bd646539eb79f4809666038d8f5b.tar.gz | |
remove AONT
If there are 3 chunks each split into 3 shares and distributed amoung 9
servers, and 2 shares are needed to recover each chunk, then with AONT,
6 servers need to collude to do so. Without AONT, a single chunk might
contain the actual gpg private key, and only 3 servers might need to
collude to recover that single chunk.
On the other hand, with 9 servers, SSS can split the data into 9 shares
with 6 needed for recovery. Thus, 6 servers will be needed to recover
any data at all, no matter how it's chunked or which chunks contain the
actual gpg key.
So, I think that tuning SSS can provide the same effects as AONT.
| -rw-r--r-- | TODO | 10 |
1 files changed, 0 insertions, 10 deletions
@@ -98,13 +98,3 @@ Encryption tunables changes: disaster. HKDF may prove more robust in the face of partial SHA-2 breaks. Deferred for now until tthere's some other reason to change keysafe's tunables. -* Thomas S points out that All-Or-Nothing Transform could be used to - prevent recovery of a partial key, when not all chunks are available to - an attacker. https://en.wikipedia.org/wiki/All-or-nothing_transform - For this to add security, there would need to be enough storage locations - that they can be partitioned into at least three sets, with the chunks split - amoung the three. One chunk probably contains the actual private - key material, a second signatures and other cruft, and the last chunk - would contain the AONT key. This would require all three sets of servers - to combine their material to crack the key. It would then make sense to - chunk even small keys. |