Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MasterPassphrase" page has been changed by GregStein: http://wiki.apache.org/subversion/MasterPassphrase?action=diff&rev1=15&rev2=16 Comment: add PBKDF2 and IV notes === High-level notions === At a minimum, we'll need: - * Access to a library for doing AES-256 encryption/decryption in CBC mode (see below). + * Access to a library for doing AES-256 encryption/decryption in CBC mode (see below), and a PBKDF2 library. * A mechanism for telling Subversion to use a master passphrase. Probably a runtime configuration variable (`use-master-passphrase`, e.g.). * A way to know how to find the master passphrase in existing keyring caches. Probably a static string ("Subversion Master Password") or somesuch. * A means for verifying that a user- or keystore-provided passphrase is the correct one, such as a self-check against a known string. We might want two strings here, actually: one stored in the authn cache files themselves (to verify that the passphrase was the one used for that set of credentials), and one stored in a provider- and realmstring-independent location (to confirm the current master passphrase). The former of those is probably only necessary if the decryption algorithm is able to return valid-looking-yet-wrong results. If, however, the decryption algorithm can detect the attempted use of the wrong secret, we only need the single this-confirms-the-current-master-password known-text string. @@ -71, +71 @@ To prevent dictionary attacks against the encrypted passwords, they will be prefixed with 4 bytes (32 bits) of random data. - The encryption algorithm requires a 16 byte key (technically, it can also be 24 or 32 bytes), and a 16 byte [[http://en.wikipedia.org/wiki/Initialization_vector|initialization vector]]. More research needed, but one or both of these need to be stored within the block of data encrypted by the master password. The master password decrypts that data block, and the resulting crypt key and IV can decrypt the target password. + The encryption algorithm requires a 16 byte key (technically, it can also be 24 or 32 bytes), and a 16 byte [[http://en.wikipedia.org/wiki/Initialization_vector|initialization vector]]. The crypt key will be constructed as a derivation of the master password (see [[http://en.wikipedia.org/wiki/PBKDF2|PBKDF2]]. PBKDF2 requires a 64 bit salt. The IV is a random 16 byte value. The salt and IV will be stored within the block of data encrypted by the master password. The master password decrypts that data block, uses the salt to generate the (de)crypt key, then pairs it with the IV to decrypt the target password. == Benefits == * Centralization: Rather than spread repository credentials cross a variety of stores (on-disk, keystores, etc.), we return to a single, easy-to-manage storage solution: the on-disk store in {{{~/.subversion/auth/}}}
