-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hmmm... Interesting question. We've put a bit of thought into this
one here at Inprise, and Bryan Olson and I thought about it a great
deal when we were both at Uptronics.
At Uptronics, we felt that the best thing to do was simply to use a
crypto cop
> Is there a good solution to the problem of starting up a network server that
> needs access to an encrypted database?
> (They also give
> you the option of having the server store the pass phrase on disk, although
> they warn you that this is completely insecure.)
Is it really? That's not cl
> Your comments about locking down the server host are correct. I think the
> distinction becomes realistic in a worst case scenario.
I disagree, but that's what makes a horse race. :)
If the private key is ondisk, then the adversary can snarf it and
try various passphrases at their leisure unti
Rich Salz wrote:
>
> > Is there a good solution to the problem of starting up a network server that
> > needs access to an encrypted database?
>
> > (They also give
> > you the option of having the server store the pass phrase on disk, although
> > they warn you that this is completely insecure
On Tue, Jan 04, 2000 at 11:20:16AM -0800, Martin Minow wrote:
> Here's my translation of the law Eivind Eklund describes. Note that,
> while I am a fluent speaker of Swedish, Norwegian is a similar, but
> not identical language. This is a really quick translation and should
> not be relied upon fo
Rich, in the one case in order to steal your key (and thus masquerade
as you) the person has to break into your machine and read a file. In
the other case, the person has to break into your machine and *write*
a *specific* file. While both sorts of attacks are possible, the
first sort of attack
> Does that double the number of systems? Surely all the adversary has to
> do is substitute his own s/w for the thing that receives the passphrase
> and reboot A, not requiring a crack of B at all.
That's why I said S/Key. Rebooting A would get the two out of sync
and while the adversary might
Rich Salz wrote:
> Another approach would be to double the number of systems that the adversary
> must compromise. HostA will run the service, but only when HostB sends
> it startup info. At boot A pings B. B "calls back" over over an SSL link
> and sends the passphrase using something like S/Ke
> I believe better protection would be to
> keep private keys on external tamper-evident hardware.
This is certainly true. However, if somebody compromises your system
with the smart encryption card, then they can probably use the card to
sign things. This isn't as good as having your key, sin
> I was assuming the adversary had physical access to the machine's console
> and could reboot, etc., at will, which seems to make your defense moot,
> at least for the (very few) systems I'm aware of.
Yes, if they have physical access life gets very complicated. :'}
But most organizations I'v
Good note. Shows why we (should) all get paid the big bucks to create
secure systems. :) Everything's a trade-off.
I was assuming the adversary had physical access to the machine's console
and could reboot, etc., at will, which seems to make your defense moot,
at least for the (very few) system
On Wed, Jan 05, 2000 at 10:22:57AM -0500, Rich Salz wrote:
> > Your comments about locking down the server host are correct. I think the
> > distinction becomes realistic in a worst case scenario.
>
> I disagree, but that's what makes a horse race. :)
>
> If the private key is ondisk, then the a
12 matches
Mail list logo
