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 CMichaelPilato: http://wiki.apache.org/subversion/MasterPassphrase?action=diff&rev1=33&rev2=34 Comment: Add an (edited) IRC transcript of conversation about this spec on irc.freenode.net ## crypto. * Implementation of built-in encryption mechanisms tied to a "master passphrase" secret key might possibly complicate Subversion's distribution per the export control restrictions placed on such technologies. We need to understand and carefully consider the scope of that complication. * Is the Subversion codebase -- and the authn subsystem specifically -- capable of handling this sort of approach? (Research continues.) + The following IRC conversation occurred in irc.freenode.net ##crypto, and carries some concerns/questions about the planned approach raised by a user therein: + + {{{ + <cmpilato> Hello, all. The Subversion version control system project + is toying with adding an encrypted store for user auth creds (of the + master-password-governed variety). The store would be used only for + auth data -- not file/wire encryption. I'm trying to figure out if + that would force us to do all the fun U.S. ECCN-related registration, + or if that usage is non-controlled. I *think* we'd be exempt under + the terms, but ... I'd feel better with supporting docs from a domain + that ended in ".gov". :-) Any advice (including "Go away -- you're + asking the wrong channel!")? + + <rizlah> hmm + + <rizlah> I doubt it + + <rizlah> If you distribute as source (e.g. linux) and add the + necessary warranty clause + + <rizlah> https://www.kernel.org/ , scroll to the bottom about + cryptographic software [ed: https://www.kernel.org/#crypto] + + <rizlah> iirc this would have been an issue back in the 90s, but + seeing as AES/etc are freely licensed, there isn't much the + governments will / want / can do about it being distributed + + <rizlah> But as always, IANAL (not a lawyer, for those who don't get + it) + + <cmpilato> rizlah: thanks! + + <yfeldblum> cmpilato, why not strong salted hashes instead? + + <yfeldblum> cmpilato, e.g., pbkdf2, iterated hmac-sha256, or bcrypt? + + <cmpilato> yfeldblum: here's the spec: + http://wiki.apache.org/subversion/MasterPassphrase any additional eyes + would be lovely! + + <yfeldblum> cmpilato, ah is this the subversion client, caching the + user's username+password combinations to multiple subversion server + endpoints? + + <cmpilato> yfeldblum: yep. + + <cmpilato> we currently store in plaintext or in an OS-provided + keyring, but are considering offering our own "keyring" of sorts for + uniformity and simplicity. + + <cmpilato> (plaintext with restricted filesystem perms, i should say, + but i realize that on a list such this that really just means we get + hit with green tomatoes instead of red ones) + + <yfeldblum> cmpilato, prefer either an authenticated encryption mode + or to MAC all encrypted messages (passwords) and always verify the + MACs first before attempting a decrypt (the MAC key should be + different from the AES key) + + <yfeldblum> cmpilato, re-encrypting is typically accomplished by + re-encrypting the master key only, not decrypting all saved passwords + and re-encrypting them + + <yfeldblum> cmpilato, IANAE, but otherwise it seems rather similar to + other decent schemes out there; but of course get a couple more + opinions on that + + <cmpilato> yfeldblum: Yes, that similarity is intentional. We + (Subversion devs) aren't trying to blaze new trails in the security + space. + + <cmpilato> yfeldblum: if i may return to a previous comment of yours: + "re-encrypting is typically accomplished by re-encrypting the master + key only, not decrypting all saved passwords and re-encrypting them" + + <yfeldblum> cmpilato, well, that's how changing the master password is + typically done + + <yfeldblum> cmpilato, keep the same master key, but decrypt it with + the old master password, then re-encrypt it with the new master + password, and save it + + <cmpilato> right. did you spot something on the wiki page that + indicated a different plan? + + <yfeldblum> cmpilato, not really, just not too much on the issue + overall + + <yfeldblum> cmpilato, also use pkcs#5/pkcs#7 block cipher padding, not + random padding, since the former is more interoperable + + <yfeldblum> cmpilato, i prefer returning a FULL_CIPHERTEXT as + IV . CIPHERTEXT; then a decrypt of the ciphertext starts with splitting + off the first 16 bytes as the IV + + <yfeldblum> cmpilato, since you will never need the IV apart from + performing a decrypt, it makes sense just to embed it in the + ciphertext string + + <cmpilato> rather than return distinct variables? + + <yfeldblum> cmpilato, right + + <yfeldblum> cmpilato, why are you generating a prefix? + + <yfeldblum> cmpilato, PREFIX = generate_random(PREFIX_LEN) <--- what's + that for? + + <cmpilato> "To prevent dictionary attacks against the encrypted + passwords, the plaintext password will be prefixed with 4 bytes (32 + bits) of random data before encryption. This should mean that reusing + a password on multiple realms doesn't result in the same encrypted + text." + + <yfeldblum> cmpilato, that's the whole purpose of the IV; since you're + using CBC and have an IV, you don't need the prefix + + <yfeldblum> cmpilato, the IV is effectively a prefix already + + <cmpilato> yfeldblum: would you be opposed to my posting in the wiki a + (trimmed) transcript of this IRC chat so that when I or others + eventually get back to working on this feature, we can consider your + input? + + <yfeldblum> cmpilato, if you include me saying IANAE (I Am Not An + Expert) and "Get A Second Opinion" in that + + <cmpilato> of course! + + <cmpilato> i'll even include you saying that i should include you + saying that. ;-) + + <yfeldblum> cmpilato, fantastic + }}} == Questions == * Since we use [[http://tools.ietf.org/html/rfc2898#section-5.2|PBKDF2]], should we also be using its sibling [[http://tools.ietf.org/html/rfc2898#section-6.2|PBES2]]? Or perhaps we're already doing just that, except for not calling it that? * How do we handle an accurately provided master passphrase that fails to decrypt some cached data (say, because the encrypted auth store is corrupt or has been manually tampered with)? Toss that data out? Leave it in place to continue failing indefinitely?
