Re: New types for transparent encryption

ac(at)esilo(dot)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/>