[Ach] OT: A Question About the Setup of "Cloud" E2E Encr

[Aaron Zauner]

Axel Hübl wrote:
> Hi,
> 
> 
> I guess that idea is a bit off-topic for the list but I was wondering
> about this since some weeks but never took the time to write it down.
> 
> In practice, one main thing that stops using end-to-end crypto in
> mainstream for (cloud) services is the annoying setup on distributed
> devices. One basically changes "one account + password" to "one account
> + password + key/2nd secret".
> 
> Wouldn't it be extremely trivial just to generate that information just
> from one "login" that is *not* shared with the provider?
> 

Yes.

tarsnap. Tahoe-LaFS et cetera.

> 
> Example "Dropbox"/Cloud encryption:
> 
> Choose a password, generate a sha512 and sha3 hash from it. [1]
> Set the sha512 as your user password (given to the provider as usual for
> authentication) and use the sha3 as a symmetric key for encryption
> (never shared with the provider).

something like a KDF? :)

https://en.wikipedia.org/wiki/Key_derivation_function
https://tools.ietf.org/html/rfc5869
https://en.wikipedia.org/wiki/PBKDF2

> 
> 
> Example PGP Keys:
> 
> Same idea. Upload the symmetrically encrypted private key (huh!) to your
> provider (e.g. in a specified IMAP folder or attribute). If your
> provider returns a tampered encrypted key to you (that you decrypt only
> locally with your 2nd password) the result should return crap - should
> be easy to detect. [2] The setup of a new device is as easy as setting
> up a device before but one can immediately import they keys.
> 
> 
> Am I missing something or did someone already implement that? [3] If we
> assume that the two "derived passwords" (one for the provider and one
> for the symmetric de/encryption) do not allow deduction to each other
> that should work pretty simple. [4]
> 
> That workflow does not solve any problems with authentication to "other
> users" (web of trust, CA system, ...) nor does it influence the created
> meta-data. But it lowers the burden of setting up multiple devices *of
> the same user* that are nevertheless the starting point. And of course
> it makes the egoistic self-sharing of calendars/mails/files easier.
> 
> Probably it's just extremely random, so I am already sorry for the noise
> in your inbox.
> 
> 
> Best,
> Axel
> 
> 
> No references, just random notes (buhh!):
> 
> [1] Alternatively: hash the password, use/hash each half of the initial
> has again to create two passwords.
> 
> [2] Next option: your provider hates you and removes your encrypted
> private key: change the provider and use your local usb-backup of your
> private key.
> 
> [3] There should be at least some drop-box encryption tools that do it
> like that, aren’t they? Anyway, someone heard something about that for
> IMAP/PGP?
> 
> [4] If your provider limits the password lengths: just crop the
> "password-hash" to e.g. 20 chars. That is still hard enough to
> brute-force it, assuming your input password was not trivial (else an
> attacker just tries hashes of that as usual).
> 
> 
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20150126/4b16a50f/attachment.sig>