At 17:05 -0400 2006/10/12, Steven M. Bellovin wrote:
This is a very interesting suggestion, but I suspect people need to be
cautious about false positives. MP3 and JPG files will, I think, have
similar entropy statistics to encrypted files; so will many compressed
files.
Actually, no. I have
On 10/13/06, Kuehn, Ulrich <[EMAIL PROTECTED]> wrote:
With reliably stopping the boot process I mean the following: Given that
stage i of the process is running, it takes the hash of the next stage,
compares that to an expected value. If they match, the current stage extends
the TPM register (whe
| > Beyond that: Are weak keys even detectable using a ciphertext-only
| > attack (beyond simply trying them - but that can be done with *any* small
| > set of keys)?
|
| Yes, generally, that's the definition of a weak key.
Which weak keys would those be? The DES weak keys are self-inverting:
En
> From: Ivan Krstić [mailto:[EMAIL PROTECTED]
> Kuehn, Ulrich wrote:
> > Who is "we"? In the case of my own system I payed for (so
> speaking for
> > myself) I would like to have such a mechanism to have the
> system prove
> > to me before login that it is not tampered with. The TCG
> approac
Am Freitag 13 Oktober 2006 12:26 schrieb Thomas:
> Am Freitag 13 Oktober 2006 12:05 schrieb Travis H.:
> > On 10/13/06, Thomas <[EMAIL PROTECTED]> wrote:
> > > Maybe RFC289.
> >
> > I assume you mean 2289, which appears to describe the OTP scheme used by
> > S/key.
>
> sorry, it was too early fo
Am Donnerstag, den 12.10.2006, 14:31 -0400 schrieb Ivan Krstić:
> Kuehn, Ulrich wrote:
> > Who is "we"? In the case of my own system I payed for (so speaking
> > for myself) I would like to have such a mechanism to have the system
> > prove to me before login that it is not tampered with. The TCG
>
"Travis H." <[EMAIL PROTECTED]> writes:
> On 10/12/06, Leichter, Jerry <[EMAIL PROTECTED]> wrote:
>> Beyond that: Are weak keys even detectable using a ciphertext-only
>> attack (beyond simply trying them - but that can be done with *any* small
>> set of keys)?
>
> Yes, generally, that's the defi
Am Freitag 13 Oktober 2006 12:05 schrieb Travis H.:
> On 10/13/06, Thomas <[EMAIL PROTECTED]> wrote:
> > Maybe RFC289.
>
> I assume you mean 2289, which appears to describe the OTP scheme used by
> S/key.
sorry, it was too early for an copy-n-paste ;)
i meant:
B. Kaliski;
Am Dienstag 10 Oktober 2006 01:35 schrieb Travis H.:
> What is the accepted way to derive several keys from a user-supplied input?
Maybe RFC289.
AFAIK it also describes the reason why it protects against dictionary attacks.
Bye,
Thomas
--
Tom <[EMAIL PROTECTED]>
fingerprint = F055 43E5 1F3C 4F
Read RFC4055 for RSA with various hashes, OAEP, and PSS combinations.
- Tolga
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Alex Alten
> Sent: Tuesday, October 10, 2006 9:47 AM
> To: Russ Housley; cryptography@metzdowd.com
> Cc: [EMAIL PROTECTED]
Here is a posting from the cypherpunks mailing list describing the
capabilities of Intel's new virtualization/TPM technology. Gets a bit
ranty but still good information.
CP
-- Forwarded message --
From: "Anonymous Remailer (austria)" <[EMAIL PROTECTED]>
Date: Fri, 29 Sep 2006 03
On 10/12/06, Leichter, Jerry <[EMAIL PROTECTED]> wrote:
Beyond that: Are weak keys even detectable using a ciphertext-only
attack (beyond simply trying them - but that can be done with *any* small
set of keys)?
Yes, generally, that's the definition of a weak key.
But that's an odd
attack to
James A. Donald:
>> Well obviously I trust myself, and do not trust
>> anyone else all that much, so if I am the user, what
>> good is trusted computing?
>>
>> One use is that I can know that my operating system
>> has not changed behind the scenes, perhaps by a
>> rootkit, know that not only have
On 10/10/06, Adam Back <[EMAIL PROTECTED]> wrote:
I think the current CPUs / memory managers do not have the ring -1 /
curtained memory features, but already a year ago or more Intel and
AMD were talking about these features. So its possible the for
example hypervisor extra virtualization functi
| > This suggests that,
| > rather than looking for weak keys as such, it might be worth it to
| > do "continuous online testing": Compute the entropy of the generated
| > ciphertext, and its correlation with the plaintext, and sound an
| > alarm if what you're getting looks "wrong". This might b
On Thu, 12 Oct 2006 16:50:13 -0400 (EDT), "Leichter, Jerry"
<[EMAIL PROTECTED]> wrote:
> This suggests that,
> rather than looking for weak keys as such, it might be worth it to
> do "continuous online testing": Compute the entropy of the generated
> ciphertext, and its correlation with the plain
| Given how rare weak keys are in modern ciphers, I assert that code to cope
| with them occurring by chance will never be adequately tested, and will be
| more likely to have security bugs. In short, why bother?
Beyond that: Are weak keys even detectable using a ciphertext-only
attack (beyond si
http://www.philly.com/mld/inquirer/news/local/states/pennsylvania/counties/philadelphia_county/philadelphia/15727557.htm
The feds were unable to break the encrypted email files until one admin
came up with a password list on a portable drive. I wonder if they
tried to brute-force the password?
n
Kuehn, Ulrich wrote:
> Who is "we"? In the case of my own system I payed for (so speaking
> for myself) I would like to have such a mechanism to have the system
> prove to me before login that it is not tampered with. The TCG
> approach does not provide this.
What does "prove" mean here? Does hav
Alexander Klimov wrote:
> Since a regular installation
> should not change ``reported OS hash,'' TPM will not be able to detect
> the difference. Am I missing something?
You're missing the marketing value of saying "this piece of hardware,
that you probably wouldn't otherwise want in your machine
Travis H. wrote:
> I can validate everything else, but as long as the BIOS is
> motherboard-specific and closed source, I don't see why I should trust
> it. We need to get rid of this legacy crud. LinuxBIOS is a good step
> but unfortunately it is only supported on a few motherboards.
We're shi
cyphrpunk wrote:
> 1. The issue is still moot at present. We are a long way from where
> open, public, remote attestion will be possible. See this diagram from
> the Trousers open-source TPM software stack project which shows which
> pieces are still missing:
>
> http://trousers.sourceforge.net/re
22 matches
Mail list logo
