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

[Axel Hübl]

On 26.01.2015 23:46, Aaron Zauner wrote:
> 
> 
> 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).
>>

coming back to IMAP key syncs.

Does anyone know a technique to deploy IMAP accounts exactly the same
way? (as in example 2)

It's a pain to sync the private keys by hand to each tablet and
smartphone...


Best,
Axel

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