Dwayne, I'd like your opinion on a slightly different approach than the one you recommended. Your suggestions to use unique salts and IV are much appreciated, and a definite improvement to the approach.
You suggested also encrypting the entire file. Instead of encrypting the entire file, which has substantial compatibility limitations (see https://bitbucket.org/kang/python-keyring-lib/issue/64/new- cryptedfilekeyring-doesnt-follow#comment-1530192). I'd like to retain more granularity in the password file. Would it be suitable to encrypt each password separately, but have a separate encrypted payload as a reference to validate the user's password when opening the file? This would necessarily mean that several ciphertexts share the same key and one of them has a known plaintext. I seem to recall from my crypto studies that such a situation is potentially less secure, but not necessarily insecure, depending on the algorithm. I'd like your opinion on the approach. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1004845 Title: python-keyring CryptedFileKeyring is insecure (was: doesn't work with python-crypto 2.6-1 (ValueError: IV must be 16 bytes long)) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-keyring/+bug/1004845/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
