a...@esilo.com (Andrew Chernow) writes: > Would the IV be regenerated every time the plaintext is updated, to > avoid using it twice? For instace: update t set text = 'abc' where id > = 1 . ISTM that the IV for OLD.text should be thrown away. > > Where would the key come from? Where would it be stored? What cipher is > used?
LDAP authentication systems tend to use SSHA these days... http://www.openldap.org/faq/data/cache/347.html With SSHA, the key used for hashing passwords is picked randomly; often by grabbing a few bytes from /dev/random. It's not important that it be cryptographically secure, as it is presented directly as part of the stored password. In python, SSH hashes thus: You need two inputs: 1. "password", which is the value that is to be hidden 2. "salt", a seed value. The point isn't for "salt" to need to be super-secure, just for it to not be frequently repeated. "Fairly random" seems to be generally good enough. import sha from base64 import b64encode ctx = sha.new( password ) ctx.update( salt ) hash = "{SSHA}" + b64encode( ctx.digest() + salt ) Sort-of-aside: FYI, I tried implementing SSHA in pl/pgsql, with mixed results. It interoperated fine with other SSHA implementations as long as the salt values were plain text. The SSHA implementation in OpenLDAP (slappasswd) uses 4 byte binary values (I think it grabs them from /dev/random or /dev/urandom); unfortunately that wouldn't "play OK" with my pl/pgsql implementation. I think having that work would be pretty keen, could share code if anyone is interested... -- output = reverse("ofni.secnanifxunil" "@" "enworbbc") http://linuxdatabases.info/info/unix.html Rules of the Evil Overlord #145. "My dungeon cell decor will not feature exposed pipes. While they add to the gloomy atmosphere, they are good conductors of vibrations and a lot of prisoners know Morse code." <http://www.eviloverlord.com/> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
