From f06692d75041bd646539eb79f4809666038d8f5b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 11 Mar 2017 11:49:03 -0400 Subject: 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. --- TODO | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/TODO b/TODO index 5ddc006..7b56c90 100644 --- a/TODO +++ b/TODO @@ -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. -- cgit v1.2.3