Re: IPsec +- Perfect Forward Secrecy

[Eric Rescorla]

John Denker <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
>
>> Uh, you've just described the ephemeral DH mode that IPsec
>> always uses and SSL provides.
>
> I'm mystified by the word "always" there, and/or perhaps by
> the definition of Perfect Forward Secrecy.  Here's the dilemma:
>
> On the one hand, it would seem to the extent that you use
> ephemeral DH exponents, the very ephemerality should do most
> (all?) of what PFS is supposed to do.  If not, why not?
>
> And yes, IPsec always has ephemeral DH exponents lying around.
>
> On the other hand, there are IPsec modes that are deemed to
> not provide PFS.  See e.g. section 5.5 of
>http://www.faqs.org/rfcs/rfc2409.html

Sorry, when I said IPsec I mean IKE. I keep trying to forget
about the manual keying modes. AFAICT IKE always uses the
DH exchange as part of establishment.

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Interesting project for C++ crypto programmer, referrals welcome

[The Promethean]

An interesting project is occupying a lot of my attention right now but
I don't have time to handle it myself. This project would be an
interesting application if it was implemented using good cryptography,
but the current team lacks the background for it. They've asked me to
help find the right talent for them.

It needs: 

Experienced C++ programmer with cryptography implementation 
experience. 

REQUIRED: 2+ Years C++, experience implementing SSL & TLS on an
application level (using public libraries, not a re-implementation of
the algorithms) for encryption and authentication. 

PREFERRED: 5+ years software engineering experience, Additional
cryptographic implementation experience a plus (DSA, ElGamal, CAST, AES,
Certificate Authorities and Public Key Infrastructure, etc).
Crossplatform, client-server (windows, linux, +). Can show a track
record of projects and results. Experience working on open source
projects. 

Short to long-term, contract to employment possibilities. Remote or
local (SF Bay Area, CA) ok. 

Other opportunities in the dev team exist as well, but filling this
opening is the key focus right now. 

Please feel free to forward to any deserving individual. Principals
only, please.

- G

-- 
Geoff Dale <[EMAIL PROTECTED]>
Methean Professional Services


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Anne & Lynn Wheeler]

At 02:53 AM 12/1/2004, Dirk-Willem van Gulik wrote:
Access to the private key of the server cert gives you the ability to do
active sniffing and in some subset of cases passive sniffing. Access to
the session key (which requires the right permissions and access to the
httpd server) gives you passive sniffing.
It is not uncommon to set this up for customers in the commercial/banking
sectors to help them comply with certain audit requirements.
Note however that in each case it requires violating the web servers
security realm and/or storing something in two places. So technically it
may make much more sense to plug a module into each webserver itself with
a sufficiently secure agregation backend to accomplish this.

the other attack is on the certification authorities business process 
... crook gets the issuing authority to give them a certificate with all 
the same information ... but their public key; the key-owner may have 
little control over the long term business process standards of the 
issuing certification authority

This is one of the attacks on SSL domain name server certificates.  
Supposedly the purpose for SSL domain name server certificates was some 
perceived vulnerabilities in the domain name infrastructure. Note, 
however, the authoritative agency(s) for domain name ownership is the 
domain name infrastructure. The current process has a SSL domain name 
server certificate applicant supplying some amount of identification 
information. The certification authority then has the error-prone and 
expensive job of contacting the domain name infrastructure 
(authoritative agency for domain name ownership) and comparing the 
supplied identification information (provided with the certificate 
application) with what is on file at the domain name infrastructure.

The attack isn't on the process that was used for the valid applicant 
... the issue is that at any time in the future, can an attacker 
compromise that process  using any recognized, valid, certification 
authority.

The side note is that the certification authority industry has somewhat 
pushed a business process where the domain name supplies their public 
key to the domain name infrastructure at the time they register the 
domain name. Then when somebody applies for a SSL domain name server 
certificate, they digitally sign the request. The certification 
authority then just has to retrieve the on-file public key from the 
domain name infrastructure and validate the digital signature. This 
turns an expensive and error-prone identification process into a much 
more reliable and less expensive authentication process.

The catch22 of course, is that if the certification authorities can 
retrieve public keys from the domain name infrastructure for 
authentication ... then just about anybody in the world could do the 
same thing  significantly reducing the need for any SSL domain name 
server certificates.

misc past postings:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
 
http://www.garlic.com/~lynn/subpubkey.html#certless


--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ 


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: IPsec +- Perfect Forward Secrecy

[John Denker]

Eric Rescorla wrote:
Uh, you've just described the ephemeral DH mode that IPsec
always uses and SSL provides.
I'm mystified by the word "always" there, and/or perhaps by
the definition of Perfect Forward Secrecy.  Here's the dilemma:
On the one hand, it would seem to the extent that you use
ephemeral DH exponents, the very ephemerality should do most
(all?) of what PFS is supposed to do.  If not, why not?
And yes, IPsec always has ephemeral DH exponents lying around.
On the other hand, there are IPsec modes that are deemed to
not provide PFS.  See e.g. section 5.5 of
  http://www.faqs.org/rfcs/rfc2409.html
Perhaps the resolution of the dilemma is to say that IPsec
"always" uses ephemeral DH for _some_ things, but it does not
"always" use ephemeral DH for some _other_ things.  Right?
Also note that 'ephemeral' is not a binary predicate.  Some
things are more ephemeral than others.  Can you also have
more-perfect PFS and less-perfect PFS?
===
There are plenty of things out there (including Cisco boxes,
in the default configuration) where the IPsec does not have
PFS turned on.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Eric Rescorla]

[EMAIL PROTECTED] writes:

>> -Original Message-
>> From: Eric Rescorla [mailto:[EMAIL PROTECTED] 
>> Sent: Wednesday, December 01, 2004 7:01 AM
>> To: [EMAIL PROTECTED]
>> Cc: Ben Nagy; [EMAIL PROTECTED]
>> Subject: Re: SSL/TLS passive sniffing
>> 
>> "Ian Grigg" <[EMAIL PROTECTED]> writes:
> [...]
>> > However could one do a Diffie Hellman key exchange and do this
>> > under the protection of the public key? [...]
>> 
>> Uh, you've just described the ephemeral DH mode that IPsec
>> always uses and SSL provides.
>> 
>> Try googling for "station to station protocol"
>> 
>> -Ekr
>
> Right. And my original question was, why can't we do that one-sided with
> SSL, even without a certificate at the client end? In what ways would that
> be inferior to the current RSA suites where the client encrypts the PMS
> under the server's public key.

Just to be completely clear, this is exactly whatthey 
TLS_RSA_DHE_* ciphersuites currently do, so it's purely a matter
of configuration and deployment.

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: RSA Implementation in C language

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Tue, 30 Nov 2004 10:16:11 -0500, "Trei, 
Peter" <[EMAIL PROTECTED]> said:

ptrei> Admittedly somewhat old and creaky, but try Googling 
ptrei> RSAREF. I don't know where that stands for IP rights
ptrei> (presumably we still have copyright), bout for
ptrei> research it's a startin point.

It's correct, RSA Labs have the copyright since March 16, 1994
(according to doc/license.txt that comes with RSAref 2).  The license
is fairly nice (although reciprocal, which some people do not like) to
non-commercial users.

Cheers,
Richard

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte   \ Tunnlandsvägen 52 \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-708-26 53 44
\  SWEDEN   \
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

-
A: Because it fouls the order in which people normally read text. 
Q: Why is top-posting such a bad thing? 
A: Top-posting. 
Q: What is the most annoying thing on usenet and in e-mail?

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Dirk-Willem van Gulik]

On Tue, 30 Nov 2004, Ben Nagy wrote:

> I'm a bumbling crypto enthusiast as a sideline to my other, real, areas of
> security expertise. Recently a discussion came up on firewall-wizards about
> passively sniffing SSL traffic by a third party, using a copy of the server

Access to the private key of the server cert gives you the ability to do
active sniffing and in some subset of cases passive sniffing. Access to
the session key (which requires the right permissions and access to the
httpd server) gives you passive sniffing.

It is not uncommon to set this up for customers in the commercial/banking
sectors to help them comply with certain audit requirements.

Note however that in each case it requires violating the web servers
security realm and/or storing something in two places. So technically it
may make much more sense to plug a module into each webserver itself with
a sufficiently secure agregation backend to accomplish this.

However due to widely varying workflow/bisprocesses at customers I have
found myself doing both.

As a closing note - the attitude of personal towards the confidentiality
of data gathered by IDS and Firewall running departments is often a lot
different than that of those directly resp. for the biz processes due to
their different roles and responsibilities ('everyone is bad' v.s.
'customers are sacret') - which is something you want to take into
account.

Dw.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: SSL/TLS passive sniffing

[ben]

> -Original Message-
> From: Eric Rescorla [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, December 01, 2004 7:01 AM
> To: [EMAIL PROTECTED]
> Cc: Ben Nagy; [EMAIL PROTECTED]
> Subject: Re: SSL/TLS passive sniffing
> 
> "Ian Grigg" <[EMAIL PROTECTED]> writes:
[...]
> > However could one do a Diffie Hellman key exchange and do this
> > under the protection of the public key? [...]
> 
> Uh, you've just described the ephemeral DH mode that IPsec
> always uses and SSL provides.
> 
> Try googling for "station to station protocol"
> 
> -Ekr

Right. And my original question was, why can't we do that one-sided with
SSL, even without a certificate at the client end? In what ways would that
be inferior to the current RSA suites where the client encrypts the PMS
under the server's public key.

Eric's answer seems to make the most sense - I guess generating the DH
exponent and signing it once per connection server-side would be a larger
performance hit than I first thought, and no clients care.

Thanks for all the answers, on and off list. ;)

Cheers,

ben



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Peter Gutmann]

Jack Lloyd <[EMAIL PROTECTED]> writes"

>Looking at my logs, about 95% of all STARTTLS connections are DHE-RSA-AES256-
>SHA; I'm guessing this is because most STARTTLS-enabled SMTP servers (ie
>Postfix, Sendmail, Qmail) use OpenSSL, and recent versions of OpenSSL have
>DHE-RSA-AES256-SHA as the top preference cipher by default.

I was just about to point that out myself.  I'd expect for more usual TLS
usage (web browser/server) it'd be 99+% RSA-*.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: RSA Implementation in C language

[Tolga Acar]

Try Intel's open-sourced CDSA, available at SourceForge.

- Tolga

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-
> [EMAIL PROTECTED] On Behalf Of Trei, Peter
> Sent: Tuesday, November 30, 2004 7:16
> To: Sandeep N; [EMAIL PROTECTED]
> Subject: RE: RSA Implementation in C language
> 
> Admittedly somewhat old and creaky, but try Googling
> RSAREF. I don't know where that stands for IP rights
> (presumably we still have copyright), bout for
> research it's a startin point.
> 
> 
> 
> Peter
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of Sandeep N
> > Sent: Monday, November 29, 2004 3:17 AM
> > To: [EMAIL PROTECTED]
> > Subject: RSA Implementation in C language
> >
> >
> > Hi,
> >
> > Can anybody tell me where I can get an implementation of RSA
> > algorithm in C language? I searched for it, but could not locate one.
> > I would be grateful to you if you could give me the location of the
> > source code.
> >
> > Thanks and Regards,
> > Sandeep
> >
> > -
> > The Cryptography Mailing List
> > Unsubscribe by sending "unsubscribe cryptography" to
> > [EMAIL PROTECTED]
> >
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> [EMAIL PROTECTED]


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: SSL/TLS passive sniffing

[Ben Nagy]

OK, Ian and I are, rightly or wrongly, on the same page here. Obviously my
choice of the word certificate has caused confusion.

[David Wagner]
> This sounds very confused.  Certs are public.  How would 
> knowing a copy
> of the server cert help me to decrypt SSL traffic that I have 
> intercepted?

Yes, sorry, what I _meant_ was the whole certificate file, PFX style, also
containing private keys. I assure you, I'm not confused, just perhaps guilty
of verbal shortcuts. I should, perhaps, have not characterised myself as
'bumbling enthusiast', to avoid the confusion with 'idiot'. :/

[...]
> Ian Grigg writes:
> >I note that disctinction well!  Certificate based systems
> >are totally vulnerable to a passive sniffing attack if the
> >attacker can get the key.  Whereas Diffie Hellman is not,
> >on the face of it.  Very curious...
> 
> No, that is not accurate.  Diffie-Hellman is also insecure if 
> the "private
> key" is revealed to the adversary.  The "private key" for 
> Diffie-Hellman
> is the private exponent.

No, I'm not talking about escrowing DH exponents. I'm talking about modes
like in IPSec-IKE where there is a signed DH exchange using ephemeral DH
exponents - this continues to resist passive sniffing if the _signing_ keys
have somehow been compromised, unless I have somehow fallen on my head and
missed something.

> Perhaps the distinction you had in mind is forward secrecy.

Yes and no. Forward secrecy is certainly at the root of my question, with
regards to the RSA modes not providing it and certain of the DH modes doing
so. :)

Thanks!

ben
  


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]