-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, 13 Mar 2010 20:05:21 + MFPA wrote:
>> I can't speak for other people, but I can for me. Take
>> > a look at the UIDs on my key, which is
>> > 0xC7C66ADF3DB6D884. And also, take a look at my master
>> > key 0x2188A92DF05045C2 that I sign
Yea, I don't need to have it entered automatically at boot time (if that's
possible, I've just thrown all semblance of true security out the window).
All I was looking for is a way to have gpg cache the passphrase for an
indefinite amount of time; and a human can enter the passphrase at boot.
It s
Hello:
I am Esteban Monge, I live in Costa Rica and help the Red Costarricense de
Software Libre (RCSL).
Sorry for my english... but I need help.
The day of FLISOL (April 24, 2010) we want make a little web conference
about GPG, the idea is make a little demo to firm mails o encrypt a
transmissi
On 3/18/2010 2:43 PM, Grant Olson wrote:
> On 3/18/2010 11:59 AM, Daniel Eggleston wrote:
>
> Not sure exactly what sort of database you're using, but gpg (to my
> knowledge) doesn't do block-level/random access. You can't just mount
> the database, stop using pgp, and write a block here and a bl
On 3/18/2010 11:59 AM, Daniel Eggleston wrote:
> Full-disk encryption still requires that the DBA enter a
> passphrase at the time of mounting the disks and doesn't solve anything
> (and is less cross-platform, there may be many different flavors of Unix
> including HP-UX, AIX, and Linux); and encr
Am 18.03.2010 12:50, schrieb Daniel Eggleston:
[...]
>
> The encryption key for the databases is stored on-disk, encrypted with
> PGP (Gnupg specifically). At first startup, it's no big deal to have the
> DBA enter a passphrase to start the database server. Once a failover
> occurs, though, time i
On Thu, Mar 18, 2010 at 10:37 AM, Grant Olson wrote:
> On 3/18/2010 7:50 AM, Daniel Eggleston wrote:
> > ..., with the ultimate goal
> > that if somebody does somehow walk out with the storage containing the
> > databases, there will be no way to gain access to the data.
>
> Physically walk out?
On 3/18/2010 7:50 AM, Daniel Eggleston wrote:
> ..., with the ultimate goal
> that if somebody does somehow walk out with the storage containing the
> databases, there will be no way to gain access to the data.
Physically walk out? You could use some full disk encryption instead.
And a lock on th
I know it's sort of a contradiction in terms, but hear me out:
The case I'm looking at is a High Availability environment hosting a
database. The database is comprised of many Unix files, encrypted via AES,
on shared storage. If the node accessing the database loses enough of its
redundant hardwar
