I forwarded a couple of messages about US Customs seizing computers,
sometimes failing to return them, and demanding passwords. Cellphones
are also sometimes seized. The TSA claims it does not do this. This
can cause problems for people who travel with company-sensitive or
other private informa
On Sat, Feb 09, 2008 at 05:04:28PM -0800, David Wagner wrote:
> By the way, it seems like one thing that might help with client certs
> is if they were treated a bit like cookies. Today, a website can set
> a cookie in your browser, and that cookie will be returned every time
> you later visit th
On 2/9/08, David Wagner <[EMAIL PROTECTED]> wrote:
> By the way, it seems like one thing that might help with client certs
> is if they were treated a bit like cookies.
I don't see how this helps with phishing. Phishers will just go after
the password or other secrets used to authenticate a new sy
"Perry E. Metzger" <[EMAIL PROTECTED]> writes:
>EE Times: Toshiba tips random-number generator IC
>
> SAN FRANCISCO -- Toshiba Corp. has claimed a major breakthrough in
> the field of security technology: It has devised the world's
> highest-performance physical random-number generator (RNG)
David Wagner <[EMAIL PROTECTED]> writes:
>Tim Dierks writes:
>>(there are totally different reasons that client certs aren't being
>>widely adopted, but that's beside the point).
>
>I'd be interested in hearing your take on why SSL client certs aren't widely
>adopted.
Because they're essentially u
David Wagner wrote:
I'd be interested in hearing your take on why SSL client certs aren't
widely adopted. It seems like they could potentially help with the
phishing problem (at least, the problem of theft of web authenticators
-- it obviously won't help with theft of SSNs). If users don't know
Tim Dierks writes:
>(there are totally different reasons that client certs aren't being
>widely adopted, but that's beside the point).
I'd be interested in hearing your take on why SSL client certs aren't
widely adopted. It seems like they could potentially help with the
phishing problem (at leas
EE Times: Toshiba tips random-number generator IC
SAN FRANCISCO -- Toshiba Corp. has claimed a major breakthrough in
the field of security technology: It has devised the world's
highest-performance physical random-number generator (RNG)
circuit.
The device generates random nu
From: David Farber <[EMAIL PROTECTED]>
To: "ip" <[EMAIL PROTECTED]>
From: Sashikumar N [sashikumar.n@ ]
Sent: Thursday, February 07, 2008 1:46 PM
To: David Farber
Subject: U.S. Agents Seize Travelers' Devices
Dear Prof Dave,
Happen to read this link fr
> > E.g., here's such a specfication excerpt and is absolutely everything said
> > in
> > the spec wrt obtaining said signature keys:
> >
> > When generating MAC keys, the recommendations in [RFC1750] SHOULD be
> > followed.
>
> One point, RFC1750 has been superceded by RFC4086.
I'll point t
From:[EMAIL PROTECTED] (Dewayne Hendricks)
Subject: [Dewayne-Net] Encrypted laptop poses legal dilemma
To: Dewayne-Net Technology List <[EMAIL PROTECTED]>
Date:Thu, 07 Feb 2008 15:38:22 -0800
[Note: This item comes from reader Randall. DLH]
From: Randall <[EMAIL PROTECTED]>
Date:
| >All of this ignores a significant issue: Are keying and encryption
| >(and authentication) mechanisms really independent of each other? I'm
| >not aware of much work in this direction.
|
| Is there much work to be done here? If you view the keyex mechanism
| as a producer of an authenticated
List,
Finally, an open source FDE (Full Disk Encryption) for Win32. It is the
first one I am aware of:
www.truecrypt.org
TC is not a new player, but starting February 5th (version 5) it also
provides FDE.
Didn't get to try it yet.
Hagai.
-
[to and CC trimmed]
- Original Message -
From: "' =JeffH '" <[EMAIL PROTECTED]>
To: ""Hal Finney"" <[EMAIL PROTECTED]>; "Eric Rescorla"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Joseph Ashwood"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>;
Sent: Thursday, February 07, 2008 2:17 PM
Sub
- Original Message -
From: ""Hal Finney"" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Sent: Wednesday, February 06, 2008 8:54 AM
Subject: Re: questions on RFC2631 and DH key agreement
Joseph Ashwood writes, regarding unauthenticated DH:
I would actually recommend sending all the publ
"Leichter, Jerry" <[EMAIL PROTECTED]> writes:
>All of this ignores a significant issue: Are keying and encryption (and
>authentication) mechanisms really independent of each other? I'm not aware of
>much work in this direction.
Is there much work to be done here? If you view the keyex mechanism
Hi Jeff -
> How wise (in a real-world sense) is it, in a protocol specification, to
> specify that one simply obtain an ostensibly random value, and then use that
> value directly as the signature key in, say, an HMAC-based signature, without
> any further stipulated checking and/or massaging of
Jeff Hodges wrote:
> Thanks for your thoughts on this Hal. Quite educational.
>
> > Jeff Hodges wrote:
> > > It turns out the supplied default for p is 1024 bit -- I'd previously
> > > goofed
> > > when using wc on it..
> > >
> > > DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
I think I already know the answer to this question, but I just want to test my
understanding...
How wise (in a real-world sense) is it, in a protocol specification, to
specify that one simply obtain an ostensibly random value, and then use that
value directly as the signature key in, say, an HM
At Thu, 7 Feb 2008 14:42:36 -0500 (EST),
Leichter, Jerry wrote:
> | > Obviously, if you *really* use every k'th packet to define what is in
> | > fact a substream, an attacker can arrange to knock out the substream he
> | > has chosen to attack. So you use your encryptor to permute the
> | > subst
Thanks for your thoughts on this Hal. Quite educational.
> Jeff Hodges wrote:
> > It turns out the supplied default for p is 1024 bit -- I'd previously
> > goofed
> > when using wc on it..
> >
> > DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61EF75A2E27898B057
> > F9891C2E27A639
>> humans are not going to carry around large strong secrets every time
either end of the connection restarts
Which is what makes good crypto challenging. I think, though, that
because people can understand the concept of physical locks and keys,
that this should be carried forward...
Good secur
| So, this issue has been addressed in the broadcast signature context
| where you do a two-stage hash-and-sign reduction (cf. [PG01]), but
| when this only really works because hashes are a lot more efficient
| than signatures. I don't see why it helps with MACs.
Thanks for the reference.
| > Obv
Jeff Hodges wrote:
> It turns out the supplied default for p is 1024 bit -- I'd previously goofed
> when using wc on it..
>
> DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61EF75A2E27898B057
> F9891C2E27A639C3F29B60814581CD3B2CA3986D2683705577D45C2E7E52DC81C7A171876E5CEA7
> 4B1448BF
I quote from
http://www.washingtonpost.com/wp-dyn/content/article/2008/02/06/AR2008020604763_pf.html
By Ellen Nakashima
Washington Post Staff Writer
Thursday, February 7, 2008; A01
> The seizure of electronics at U.S. borders has prompted protests from
> travelers who say they now weigh
At Thu, 7 Feb 2008 10:34:42 -0500 (EST),
Leichter, Jerry wrote:
> | Since (by definition) you don't have a copy of the packet you've lost,
> | you need a MAC that survives that--and is still compact. This makes
> | life rather more complicated. I'm not up on the most recent lossy
> | MACing literat
| >I don't propose to get into an extended debate about whether it is
| >better to use SRTP or to use generic DTLS. That debate has already
| >happened in IETF and SRTP is what the VoIP vendors are
| >doing. However, the good news here is that you can use DTLS to key
| >SRTP (draft-ietf-avt-dtls-sr
> Thus unlike with bridges, you fundamentally can't
> evaluate the quality of a security system you built if you're unfamiliar
> with the state of the art of _attacks_ against security systems, and you
> can't become familiar with those unless you realize that these attacks
> have each brough
On Thu, Feb 07, 2008 at 08:47:20PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >While Firefox should ideally be developing and testing PSK now, without
> >stable libraries to use in servers and browsers, we can't yet expect anything
> >to be released.
>
> Is tha
| > - Truncate the MAC to, say, 4 bytes. Yes, a simple brute
| > force attack lets one forge so short a MAC - but
| > is such an attack practically mountable in real
| > time by attackers who concern you?
|
| In fact, 32-bit authentication tags are a featur
http://eprint.iacr.org/2008/058
Physical Cryptanalysis of KeeLoq Code Hopping Applications
Recently, some mathematical weaknesses of the KeeLoq algorithm have been
reported. All of the proposed attacks need at least 2^16 known or chosen
plaintexts. In real-world applications of KeeLoq
Victor Duchovni <[EMAIL PROTECTED]> writes:
>While Firefox should ideally be developing and testing PSK now, without
>stable libraries to use in servers and browsers, we can't yet expect anything
>to be released.
Is that the FF devlopers' reason for holding back? Just wondering... why not
releas
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>There's another issue: initial account setup. People will still need to rely
>on certificate-checking for that. It's a real problem at some hotspots,
>where Evil Twin attacks are easy and lots of casual users are signing up for
>the first time.
On Thu, 07 Feb 2008 17:37:02 +1300
[EMAIL PROTECTED] (Peter Gutmann) wrote:
> The real issues occur in two locations:
>
> 1. In the browser UI.
> 2. In the server processing, which no longer gets the password via an
> HTTP POST but as a side-effect of the TLS connect.
>
> (1) is a one-off cost f
Frank Siebenlist <[EMAIL PROTECTED]> writes:
>With the big browser war still going strong, wouldn't that provide fantastic
>marketing opportunities for Firefox?
There's always the problem of politics. You'd think that support for a free
CA like CAcert would also provide fantastic marketing oppor
"James A. Donald" <[EMAIL PROTECTED]> writes:
>However, seems to me that logging into the website using SRP is a non trivial
>refactoring, and not just a matter of dropping in TLS-SRP as a simple
>replacement of TLS-DSA-X509
I've discussed this with (so far) a small sample of assorted corporate T
Others have made similar points and suggestions, not picking on this
instance in particular:
On Mon, Feb 04, 2008 at 02:48:08PM -0700, Martin James Cochran wrote:
> Additionally, in order to conserve bandwidth you might want to make a
> trade-off where some packets may be forged with small probab
> Amateurs talk about algorithms. Professionals talk about economics.
That would be
Amateurs study cryptography; professionals study economics.
-- Allan Schiffman, 2 July 04
Quotationally yours,
--dan
-
The Cryptogra
38 matches
Mail list logo
