On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:
I believe that those who supply security products have a responsibility
to consider the knowledge, experience, and tendencies of their likely
users to the greatest extent to which they're able, and supply products
which will
On Mon, 5 May 2008, Ariel Waissbein wrote:
[Moderator's note: Again, top posting is discouraged, and not editing
quoted material is also discouraged. --Perry]
Hi list,
Interesting. Great work! I had been looking *generic* predicate
encryption for some time. Encryption over specific predicates
Jack Lloyd [EMAIL PROTECTED] writes:
As a standard, this is specification is a disaster.
Somewhat more strongly worded than my comments :-), but I had the same
feeling: Why yet another bunch of arbitrary PRF/KDFs to implement? We now
have ones for SSL, for TLS, for SSH, for IKE, for PGP, for
Perry E. Metzger wrote:
What you can't do, full stop, is
know that there are no unexpected security related behaviors in the
hardware or software. That's just not possible.
Ben Laurie wrote:
Rice's theorem says you can't _always_ solve this problem. It says
nothing about figuring out
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Steven M. Bellovin
Sent: 03 May 2008 00:51
To: Arcane Jill
Cc: cryptography@metzdowd.com
Subject: Re: SSL and Malicious Hardware/Software
I can't think of a great way of alerting the user,
I would be
Call for Participation
MetriCon 3.0
Third Workshop on Security Metrics
Tuesday, 29 July 2008, San Jose, California
Overview
Security metrics -- an idea whose time has come. No matter whether you
read the technical or the business press, there is a desire for
converting security from a world
Jonathan Katz wrote:
On Mon, 5 May 2008, Ariel Waissbein wrote:
[Moderator's note: Again, top posting is discouraged, and not editing
quoted material is also discouraged. --Perry]
Hi list,
Interesting. Great work! I had been looking *generic* predicate
encryption for some time.
On Sun, 04 May 2008 11:22:51 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Steven M. Bellovin wrote:
On Sat, 03 May 2008 17:00:48 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Peter Gutmann) writes:
I am left with the strong suspicion that SSL VPNs are easier to
On Sat, 03 May 2008 19:50:01 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:
Almost exclusively the use for such things is nailing up a tunnel to
bring someone inside a private network. For that, there is no need for
per user auth -- the general assumption is that the remote box is a
single
Just a few reminders from your moderator about posting etiquette:
0) Text only, please. HTML and text encoded weird ways like base-64,
as well as MIME multiparts, are a big pain in the neck. I generally
just reject them rather than repairing them.
1) Please do not top post when replying to
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:
In particular, with TLS the session key can be negotiated between
two user contexts; with IPsec/IKE, it's negotiated between a user
and a system. (Yes, I'm oversimplifying here.)
Is there any reason (in principle) that
In article [EMAIL PROTECTED] you write:
On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:
I believe that those who supply security products have a responsibility
to consider the knowledge, experience, and tendencies of their likely
users to the greatest extent to which
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:
Experiment part two: implement remote login (or remote IMAP, or remote
Web with per-user privileges, etc.) under similar conditions. Recall
that being able to do this was a goal of the IPsec working group.
I think that part
On Tue, May 06, 2008 at 11:40:53AM -0700, David Wagner wrote:
- With the upcoming EECDH support, users don't choose curves
directly, they again choose a security grade, and the correspnding
curves are configurable via parameters they are not expected to
ever look at or modify.
On May 6, 2008, at 1:14 AM, James A. Donald wrote:
Perry E. Metzger wrote:
What you can't do, full stop, is
know that there are no unexpected security related behaviors in the
hardware or software. That's just not possible.
Ben Laurie wrote:
Rice's theorem says you can't _always_ solve
The same is true in the source code, unsafe
practices are avoided globally, (e.g. both strcpy()
and strncpy() are absent together with fixed size
automatic buffers) rather than used with care
locally. I won't bore you with all the
implementation safety habits, but there are many.
16 matches
Mail list logo
