On Mar 20, 2010, at 10:00 AM, Robert J. Hansen wrote:
> On 3/20/2010 8:41 AM, egg...@gmail.com wrote:
>> Maybe I'm doing it wrong, but all I see are patents and research
>> projects ongoing at IBM.
>
> You're doing it wrong. Keep searching. I know there's at least one
> paper readily findable i
On 3/20/2010 8:41 AM, egg...@gmail.com wrote:
> Maybe I'm doing it wrong, but all I see are patents and research
> projects ongoing at IBM.
You're doing it wrong. Keep searching. I know there's at least one
paper readily findable in Google Scholar that tells you exactly how
BitLocker does it.
M
On Fri, Mar 19, 2010 at 06:48:52PM -0400, Robert J. Hansen wrote:
> On 3/19/2010 5:36 PM, FederalHill wrote:
> > Are there refernces where such procedures are detailed that I might look at?
>
> http://scholar.google.com
>
> Check for "encrypted database rekeying".
>
>
Maybe I'm doing it wrong,
On 3/19/2010 5:36 PM, FederalHill wrote:
> Are there refernces where such procedures are detailed that I might look at?
http://scholar.google.com
Check for "encrypted database rekeying".
smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnup
Are there refernces where such procedures are detailed that I might look at?
--- On Fri, 3/19/10, Robert J. Hansen wrote:
From: Robert J. Hansen
Subject: Re: Secure unattended decryption
To: gnupg-users@gnupg.org
Date: Friday, March 19, 2010, 5:30 PM
On 3/19/2010 4:26 PM, egg
On 3/19/2010 4:26 PM, egg...@gmail.com wrote:
> Yes, well, changing the AES key on a database (Which may be several
> hundred gigabytes) is time consuming.
Only if you design your database poorly. This is a solved problem in
both database design and filesystem design.
smime.p7s
Description: S/
On 3/19/2010 1:17 PM, M.B.Jr. wrote:
>>
>> The encryption key for the databases is stored on-disk, encrypted with PGP
>> (Gnupg specifically).
>
>
> Sort of a conceptual remark at this point.
>
> See, this database password you refer to is a symmetrical one. And you
> stated you keep it on-disk,
On Fri, Mar 19, 2010 at 02:17:12PM -0300, M.B.Jr. wrote:
> Hi Daniel,
>
>
> On Thu, Mar 18, 2010 at 8:50 AM, Daniel Eggleston wrote:
> > 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 d
Hi Daniel,
On Thu, Mar 18, 2010 at 8:50 AM, Daniel Eggleston wrote:
> 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 s
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
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
16 matches
Mail list logo
