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@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org