Mailinglist Archive: opensuse (1898 mails)

[Greg Freemyer <greg.freemyer@xxxxxxxxx>]

Jim,

Below is the info from their website.  I'm not enough of an encryption
expert to comment on how effective this is.

===
Encryption Specifications

SpiderOak uses a layered approach to encryption, using a combination
of 2048 byte RSA and 256 bit AES.

Most importantly, however, the outer level keys are never stored
plaintext on the SpiderOak server. They are encrypted with 256 bit
AES, using a key created by the key derivation/strengthening algorithm
pdkdf2 (using sha256), with 16384 rounds, and 32 bytes of random data
("salt"). This approach prevents brute force and pre-computation or
database attacks against the key. This means that a user who knows her
password, can generate the outer level encryption key using pdkdf2 and
the salt, then decipher the outer level keys, and be on the way to
decrypting her data. Without knowledge of the password, however, the
data is quite unreadable.
User Authentication Process

Consider the scenario where a user has lost all of their data (an
unrecoverable hard drive failure, for example) and needs to
authenticate into their SpiderOak account to recover. SpiderOak
servers have the user's data and encryption keys, but cannot read the
contents of either because the encryption keys themselves are
encrypted. The user knows her password, but does not have her own
encryption keys locally. This requires a different approach from the
traditional challenge/response authentication methods.

When a client first creates their account, that signup process happens
within the SpiderOak desktop application (so that the server does not
play any role in the key generation process, and never knows the
contents.) The first SpiderOak upload transaction the client creates
contains the following data:

salt1.rnd      32 bytes of random data, stored plain
salt2.rnd      32 bytes of random data, stored plain
publickey.key  2048 byte serialized RSA public key, stored plain
challenge.key  32 bytes, output of pdkdf2(password, salt1)
               used in the construction of auth challenges
keypair.key    2048 byte serialized RSA keypair, stored AES
               encrypted using pdkdf2(password, salt2) as key

In the situation where a client must authenticate by simply proving
that they know their password (and without telling us that password),
this protocol is followed:

The server sends a challenge, with these 3 data items:

aes_encrypt(data=random1, key=challenge.key, iv=h(timestamp))
salt1
timestamp

The client correctly answers the challenge by using the data in
random1, which is a string of 32 random bytes, as the key to its own
encrypted reply of the timestamp:

aes_encrypt(data=time, key=random1, iv=h(timestamp))

The client can generate the contents of challenge.key using only
pdkdf2(password, salt1), and thus has all available information
required to answer the challenge.

In this process, the only real information given by the server to a
client is the contents of salt1, which is simply 32 bytes of random
data, and should in no way aid in allowing an attacker to predict the
password or key. In the client's response, she sends no additional
information that was not already included in the server's challenge.

Sometimes an exchange like this is called a zero knowledge proof of
knowledge, or a zero knowledge password proof.
===

Greg
-- 
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx