Peter Gutmann wrote:
(Does anyone know of any studies that have been done to find out how prevalent
this is for servers? I can see why you'd need to do it for software-only
implementations in order to survive restarts, but what about hardware-assisted
TLS? Is there anything like a study showing
Thor Lancelot Simon wrote:
To the extent of my knowledge there are currently _no_ generally
available, general-purpose crypto accellerator chip-level products with
onboard key storage or key wrapping support, with the exception of parts
first sold more than 5 years ago and being shipped now from
Thor Lancelot Simon wrote:
No, no there's not. In fact, I solicited information here about crypto
accellerators with onboard persistent key memory ("secure key storage")
about two years ago and got basically no responses except pointers to
the same old, discontinued or obsolete products I was tr
On Sun, Mar 15, 2009 at 12:26:39AM +1300, Peter Gutmann wrote:
>
> I was hoping someone else would leap in about now and question this, but I
> guess I'll have to do it... maybe we have a different definition of what's
> required here, but AFAIK there's an awful lot of this kind of hardware
> floa
Thor Lancelot Simon writes:
>Almost no web servers run with passwords on their private key files. Believe
>me. I build server load balancers for a living and I see a _lot_ of customer
>web servers -- this is how it is.
Ah, that kinda makes sense, it would parallel the experience with client-sid
On Sat, Mar 07, 2009 at 07:36:25AM +1300, Peter Gutmann wrote:
>
> In any case though, how big a deal is private-key theft from web servers?
> What examples of real-world attacks are there where an attacker stole a
> private key file from a web server, brute-forced the password for it, and then
>
Thor Lancelot Simon writes:
>On Sat, Mar 07, 2009 at 05:40:31AM +1300, Peter Gutmann wrote:
>> Given that, when I looked a couple of years ago, TPM support for
>> public/private-key stuff was rather hit-and-miss and in some cases seemed to
>> be entirely absent (so you could use the TPM to wrap an
On Sat, Mar 07, 2009 at 05:40:31AM +1300, Peter Gutmann wrote:
>
> Given that, when I looked a couple of years ago, TPM support for
> public/private-key stuff was rather hit-and-miss and in some cases seemed to
> be entirely absent (so you could use the TPM to wrap and unwrap stored private
> keys
On Thu, Mar 5, 2009 at 12:13 PM, Kent Yoder wrote:
> Hi Peter,
>
>>>Apart from the obvious fact that if the TPM is good for DRM then it is also
>>>good for protecting servers and the data on them,
>>
>> In which way, and for what sorts of "protection"? And I mean that as a
>> serious inquiry, not
Hi Peter,
>>Apart from the obvious fact that if the TPM is good for DRM then it is also
>>good for protecting servers and the data on them,
>
> In which way, and for what sorts of "protection"? And I mean that as a
> serious inquiry, not just a "Did you spill my pint?" question. At the moment
>
Alexander Klimov wrote:
> On Wed, 11 Feb 2009, Ben Laurie wrote:
>> If I have data on my server that I would like to stay on my server
>> and not get leaked to some third party, then this is exactly the
>> same situation as DRMed content on an end user's machine, is it not?
>
> The treat model is
Ben Laurie wrote:
If I have data on my server that I would like to stay on my server and
not get leaked to some third party, then this is exactly the same
situation as DRMed content on an end user's machine, is it not?
No.
You want to keep control of the information on your server. DRM wants
On Wed, 11 Feb 2009, Ben Laurie wrote:
> If I have data on my server that I would like to stay on my server
> and not get leaked to some third party, then this is exactly the
> same situation as DRMed content on an end user's machine, is it not?
The treat model is completely different: for DRM the
Peter Gutmann wrote:
> Ben Laurie writes:
>
>> Apart from the obvious fact that if the TPM is good for DRM then it is also
>> good for protecting servers and the data on them,
>
> In which way, and for what sorts of "protection"? And I mean that as a
> serious inquiry, not just a "Did you spil
On Feb 2, 2009, at 2:29 AM, Peter Gutmann wrote:
Mark Ryan presented a plausible use case that is not DRM:
http://www.cs.bham.ac.uk/~mdr/research/projects/08-tpmFunc/.
This use is like the joke about the dancing bear, the amazing thing
isn't the
quality of the "dancing" but the fact that the
- Original Message -
From: "Jonathan Thornburg"
To: "Brian Gladman"
Cc: "John Gilmore" ; "Peter Gutmann"
; ;
Sent: Monday, February 02, 2009 3:53 AM
Subject: Re: full-disk subversion standards released
[snip]
It's this variety of
Ben Laurie writes:
>Apart from the obvious fact that if the TPM is good for DRM then it is also
>good for protecting servers and the data on them,
In which way, and for what sorts of "protection"? And I mean that as a
serious inquiry, not just a "Did you spill my pint?" question. At the momen
I wrote:
| Indeed, the classic question is "I've just bought this new computer
| which claims to have full-disk encryption. Is there any practical
| way I can assure myself that there are (likely) no backdoors in/around
| the encryption?"
|
| For open-source software encryption (be it swap-space,
Peter Gutmann wrote:
John Gilmore writes:
The theory that we should build "good and useful" tools capable of monopoly
and totalitarianism, but use social mechanisms to prevent them from being
used for that purpose, strikes me as naive.
There's another problem with this theory and that's the
On Sat, 31 Jan 2009, Peter Gutmann wrote:
> Even with the best intentions in the world, the only thing you
> can really usefully do with a TPM is DRM.
If there were a direct link from TPM to display and speakers and
all the content rendering were done by TPM itself, then TPM
would be useful for DR
Peter Gutmann wrote:
> John Gilmore writes:
>
>> The theory that we should build "good and useful" tools capable of monopoly
>> and totalitarianism, but use social mechanisms to prevent them from being
>> used for that purpose, strikes me as naive.
>
> There's another problem with this theory an
John Gilmore writes:
>The theory that we should build "good and useful" tools capable of monopoly
>and totalitarianism, but use social mechanisms to prevent them from being
>used for that purpose, strikes me as naive.
There's another problem with this theory and that's the practical
implementati
On Fri, Jan 30, 2009 at 04:08:07PM -0800, John Gilmore wrote:
>
> The theory that we should build "good and useful" tools capable of
> monopoly and totalitarianism, but use social mechanisms to prevent
> them from being used for that purpose, strikes me as naive.
Okay. In that case, please, expl
On Fri, Jan 30, 2009 at 03:37:22PM -0800, Taral wrote:
> On Fri, Jan 30, 2009 at 1:41 PM, Jonathan Thornburg
> wrote:
> > For open-source software encryption (be it swap-space, file-system,
> > and/or full-disk), the answer is "yes": I can assess the developers'
> > reputations, I can read the so
> Given such solutions, frameworks like what TCG is chartered to build are
> in fact good and useful. I don't think it's right to blame the tool (or
> the implementation details of a particular instance of a particular kind
> of tool) for the idiot carpenter.
Given the charter of TCG, to produce
On Fri, Jan 30, 2009 at 1:41 PM, Jonathan Thornburg
wrote:
> For open-source software encryption (be it swap-space, file-system,
> and/or full-disk), the answer is "yes": I can assess the developers'
> reputations, I can read the source code, and/or I can take note of
> what other people say who'
On Thu, 29 Jan 2009, John Gilmore wrote:
> If it comes from the "Trusted Computing Group", you can pretty much
> assume that it will make your computer *less* trustworthy. Their idea
> of a trusted computer is one that random unrelated third parties can
> trust to subvert the will of the computer'
On Thu, Jan 29, 2009 at 01:22:37PM -0800, John Gilmore wrote:
>
> If it comes from the "Trusted Computing Group", you can pretty much
> assume that it will make your computer *less* trustworthy. Their idea
> of a trusted computer is one that random unrelated third parties can
> trust to subvert th
If it comes from the "Trusted Computing Group", you can pretty much
assume that it will make your computer *less* trustworthy. Their idea
of a trusted computer is one that random unrelated third parties can
trust to subvert the will of the computer's owner.
John
-
29 matches
Mail list logo
