Re: SSL/TLS passive sniffing

[Ian Grigg]

> 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.  If you learn the private exponent that one
> endpoint used for a given connection, and if you have intercepted that
> connection, you can derive the session key and decrypt the intercepted
> traffic.

I wasn't familiar that one could think in those terms.  Reading
here:  http://www.rsasecurity.com/rsalabs/node.asp?id=2248 it
says:

In recent years, the original Diffie-Hellman protocol
has been understood to be an example of a much more
general cryptographic technique, the common element
being the derivation of a shared secret value (that
is, key) from one party's public key and another
party's private key. The parties' key pairs may be
generated anew at each run of the protocol, as in
the original Diffie-Hellman protocol.

It seems the compromise of *either* exponent would lead to
solution.

> Perhaps the distinction you had in mind is forward secrecy.  If you use
> a different "private key" for every connection, then compromise of one
> connection's "private key" won't affect other connections.  This is
> true whether you use RSA or Diffie-Hellman.  The main difference is
> that in Diffie-Hellman, "key generation" is cheap and easy (just an
> exponentiation), while in RSA key generation is more expensive.

Yes.  So if a crypto system used the technique of using
Diffie-Hellman key exchange (with unique exponents for each
session), there would be no lazy passive attack, where I
am defining the lazy attack as a once-off compromise of a
private key.  That is, the attacker would still have to
learn the individual exponent for that session, which
(assuming the attacker has to ask for it of one party)
would be equivalent in difficulty to learning the secret
key that resulted and was used for the secret key cipher.

iang

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

SSL/TLS passive sniffing

[David Wagner]

Ben Nagy wrote:
>Recently a discussion came up on firewall-wizards about
>passively sniffing SSL traffic by a third party, using a copy of the server
>cert (for, eg, IDS purposes).

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?
Now if I had a copy of the server's private key, that would help, but such
private keys are supposed to be closely held.

Or are you perhaps talking about some kind of active man-in-the-middle
attack, perhaps exploiting DNS spoofing?  It doesn't sound like it, since
you mentioned passive sniffing.

And it doesn't matter whether you use Diffie-Hellman or RSA with Verisign
certs; either way, SSL should be secure against passive eavesdropping.

I think you need to elaborate before we can give any sensible responses.

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

SSL/TLS passive sniffing

[David Wagner]

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.  If you learn the private exponent that one
endpoint used for a given connection, and if you have intercepted that
connection, you can derive the session key and decrypt the intercepted
traffic.

Perhaps the distinction you had in mind is forward secrecy.  If you use
a different "private key" for every connection, then compromise of one
connection's "private key" won't affect other connections.  This is
true whether you use RSA or Diffie-Hellman.  The main difference is
that in Diffie-Hellman, "key generation" is cheap and easy (just an
exponentiation), while in RSA key generation is more expensive.

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

Re: SSL/TLS passive sniffing

[Jerrold Leichter]

By an interesting coincidence, the article below appeared in the on-line
Computerworld today.
-- Jerry

  Universities grapple with SSL-busting spyware
  Marketscore could be used to intercept sensitive
  information, security experts say

  News Story by Paul Roberts
  NOVEMBER 30, 2004 (IDG NEWS SERVICE) -
  U.S. universities are struggling with a flare-up of dangerous
  spyware that can snoop on information encrypted using
  Secure Sockets Layer (SSL). Experts are warning that the
  stealthy software, called Marketscore, could be used to
  intercept a wide range of sensitive information, including
  passwords and health and financial data.

  In recent weeks, IT departments at a number of
  universities issued warnings about problems caused by the
  Marketscore software, which promises to speed up Web
  browsing. The program, which routes all user traffic
  through its own network of servers, poses a real threat to
  user privacy, security experts agree.

  Columbia University, Cornell University, Indiana
  University, the State University of New York (SUNY) at
  Albany and Pennsylvania State University are among those
  noting an increase in the number of systems running
  Marketscore software in recent weeks. Each institution
  warned its users about Marketscore and posted instructions
  for removing the software.

  The software is bundled with iMesh peer-to-peer software,
  and may have made it onto university networks that way,
  said David Escalante, director of computer security at
  Boston College.

  The company that makes the software, Marketscore Inc., has
  headquarters in Reston, Va., at the same mailing address
  as online behavior tracking company ComScore Networks Inc.
  ComScore Networks did not respond to repeated requests for
  comment.

  Reports of infected systems on campuses ranged from a
  handful to as many as 200 on one large campus network,
  Escalante said.

  Marketscore is the latest incarnation of a spyware program
  called Netsetter, which first appeared in January, said
  Sam Curry, vice president of eTrust Security Management at
  Computer Associates International Inc.

  "Basically it takes all your Web traffic and forces it
  through its own proxy servers," he said.

  The redirection speeds up Web surfing, because pages
  cached on Marketscore's servers load faster than they
  would if they were served directly from the actual Web
  servers for sites such as Google or Yahoo. However, those
  performance benefits have been elusive.

  "People who have installed the software complain to us
  that they're not getting any improvement," Curry said.

  Richard Smith, an independent software consultant in
  Boston, is also skeptical of performance improvement
  claims made by Marketscore and others, especially since
  many Internet service providers already offer Web caching
  for their dial-up customers, he said in an e-mail message.

  Cornell's IT security office blocked connections between
  the university's network and the Marketscore servers,
  according to a message posted on the university's Web
  site. Administrators at SUNY Albany took similar steps,
  according to a message posted on that school's Web site.

  While other legal software programs make similar claims
  about improving Web browsing speed as Marketscore,
  Internet security experts are troubled that the software
  creates its own trusted certificate authority on
  computers. That certificate authority intercepts Web
  communications secured using SSL, decrypting that traffic,
  then sending it to the Marketscore servers before
  encrypting the traffic and passing it along to its final
  destination. That traffic could include sensitive
  information, including passwords, credit card and Social
  Security numbers, Curry said.

  Marketscore should be a big concern for companies, such as
  banks, with employees who handle sensitive data, Escalante
  said.

  "I don't know how good it is for parties on either end of
  a transaction to have a third party listening in

Re: SSL/TLS passive sniffing

[Jack Lloyd]

On Tue, Nov 30, 2004 at 01:39:42PM -0500, Victor Duchovni wrote:

> The third mode is quite common for STARTTLS with SMTP if I am not
> mistaken. A one day sample of inbound TLS email has the following cipher
> frequencies:
> 
> 8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> 6529(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>  186(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
>  117(using TLSv1 with cipher RC4-SHA (128/128 bits))
>   59(using SSLv3 with cipher RC4-SHA (128/128 bits))
>   40(using SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
>   28(using TLSv1 with cipher RC4-MD5 (128/128 bits))
>   16(using SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>   14(using TLSv1 with cipher DES-CBC3-SHA (168/168 bits))
>1(using SSLv3 with cipher RC4-MD5 (128/128 bits))
>1(using SSLv2 with cipher DES-CBC3-MD5 (168/168 bits))

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 suspect you'd see about the same results for any other SSL service that's not
HTTP. I'm surprised to see that SSLv2 connection at the bottom... considering
that STARTTLS didn't exist until, well, TLS, I wonder what logic went into
supporting only SSLv2.

> it is my perhaps misguided impression that the both the EDH and the DHE
> cipher-suites provide PFS. Is there in fact a difference between EDH
> and DHE?

OpenSSL just calls them differently depending on the ciphers in use (an
artifact of the specifications, I think).

-Jack

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

RE: RSA Implementation in C language

[Trei, Peter]

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]

Re: SSL/TLS passive sniffing

[Victor Duchovni]

On Tue, Nov 30, 2004 at 07:15:44AM -0800, Eric Rescorla wrote:

> SSL has all three of these modes, actually, so perhaps the question
> you want to ask is why noone uses #3. The main argument against it is
> that it's about half as fast (on the server) in the best case because
> you need to do both a signature and a key exchange operation.
> On the client it's *much* slower because RSA public-key encryption
> is very fast (private-key decryption is much slower). 
> 

The third mode is quite common for STARTTLS with SMTP if I am not
mistaken. A one day sample of inbound TLS email has the following cipher
frequencies:

8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
6529(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
 186(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 117(using TLSv1 with cipher RC4-SHA (128/128 bits))
  59(using SSLv3 with cipher RC4-SHA (128/128 bits))
  40(using SSLv3 with cipher DES-CBC3-SHA (168/168 bits))
  28(using TLSv1 with cipher RC4-MD5 (128/128 bits))
  16(using SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
  14(using TLSv1 with cipher DES-CBC3-SHA (168/168 bits))
   1(using SSLv3 with cipher RC4-MD5 (128/128 bits))
   1(using SSLv2 with cipher DES-CBC3-MD5 (168/168 bits))

it is my perhaps misguided impression that the both the EDH and the DHE
cipher-suites provide PFS. Is there in fact a difference between EDH
and DHE?

-- 

 /"\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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

Re: SSL/TLS passive sniffing

[Ian Grigg]

Ben raises an interesting thought:

> There was some question about whether this is possible for connections that
> use client-certs, since it looks to me from the spec that those connections
> should be using one of the Diffie Hellman cipher suites, which is obviously
> not vulnerable to a passive sniffing 'attack'. Active 'attacks' will
> obviously still work. Bear in mind that we're talking about deliberate
> undermining of the SSL connection by organisations, usually against their
> website users (without talking about the goodness, badness or legality of
> that), so "how do they get the private keys" isn't relevant.

We have the dichotomy that DH protects against all passive
attacks, and a signed cert protects against most active attacks,
and most passive attacks, but not passive attacks where the
key is leaked, and not active attacks where the key is
"forged" (as a cert).

But we do not use both DH and certificates at the same time,
we generally pick one or the other.

Could we however do both?

In the act of a public key protected key exchange, Alice
generally creates a random key and encrypts that to Bob's
public key.  That random then gets used for further traffic.

However could one do a Diffie Hellman key exchange and do this
under the protection of the public key?  In which case we are
now protected from Bob aggressively leaking the public key.
(Or, to put it more precisely, Bob would now have to record
and leak all his traffic as well, which is a substantially
more expensive thing to engage in.)

(This still leaves us with the active attack of a forged
key, but that is dealt with by public key (fingerprint)
caching.)

Does that make sense?  The reason I ask is that I've just
written a new key exchange protocol element, and I thought
I was being clever by having both Bob and Alice provide
half the key each, so as to protect against either party
being non-robust with secret key generation.  (As a programmer
I'm more worried about the RNG clagging than the key leaking,
but let's leave that aside for now...)

Now I'm wondering whether the key exchange should do a DH
within the standard public key protected key exchange?
Hmmm, this sounds like I am trying to do PFS  (perfect
forward secrecy).  Any thoughts?

iang


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

Re: SSL/TLS passive sniffing

[Ian Grigg]

Hi Ben,

> I'm a bumbling crypto enthusiast as a sideline to my other, real, areas of
> security expertise.

That's what most of us really are, to be fair.  Crypto is
such a small part of security that most all crypto people
move across to general security once they realise there
isn't much work around for a pure crypto person.  Which is
good, because only in the general security field can one
really make a difference, IMHO, because that's when starts
to understand what is needed, as opposed to what's cool.

> Recently a discussion came up on firewall-wizards about
> passively sniffing SSL traffic by a third party, using a copy of the server
> cert (for, eg, IDS purposes).

OK.  A nice challenge to assumptions!

> There was some question about whether this is possible for connections that
> use client-certs, since it looks to me from the spec that those connections
> should be using one of the Diffie Hellman cipher suites, which is obviously
> not vulnerable to a passive sniffing 'attack'. Active 'attacks' will
> obviously still work. Bear in mind that we're talking about deliberate
> undermining of the SSL connection by organisations, usually against their
> website users (without talking about the goodness, badness or legality of
> that), so "how do they get the private keys" isn't relevant.

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...

( I had at first thought this would be related to the many
and various ways to acquire a "forged cert" but it is not.
You have to have access to the actual key in use at the
time, to conduct a passive attack.  Mind you, if you had
access to a forged cert then you could conduct an active
MITM.  But that then equates it to an active attack against
Diffie Hellman. )

> However, I was wondering why the implementors chose the construction used
> with the RSA suites, where the client PMS is encrypted with the server's
> public key and sent along - it seems to make this kind of escrowed passive
> sniffing very easy. I can't think why they didn't use something based on DH
> - sure you only authenticate one side of the connection, but who cares? Was
> it simply to save one setup packet?
>
> Anyone know?

Well.  I would say that "knowing" is rather difficult in
precise terms, even for the people who were involved in
the essential design of the first version of the PKI.  But,
for what it is worth, here are my impressions, derived from
a couple of years of (amateur) research into why SSL/PKI
is so ... obscure?  Well, pick your own term.



In the design of the SSL protocol and its associated PKI
using x.509 certs, there are a lot of decisions that are
questionable on security grounds.

There are a lot of ideas that simply don't make a lot of
sense if one is thinking from a pure security sense.  By
way of quick example, they were nominally trying to protect
credit cards from being sniffed, which would be a low value
attack.  But, they decided to downgrade things like Diffie
Hellman, which would easily have defeated a credit card
sniffing attack, by forcing in place an MITM, which would
have left easy tracks to follow.  And they downgraded the
self-signed cert, which properly employed defeats phishing
(they weren't to know that then, but clearly their view
of attacks was incomplete).  There is more and if you are
interested I'd invite you to spend an afternoon on the
rants at http://iang.org/ssl/ .

So, eventually, in searching for the driving forces behind
the protocol, one is directed away from "defeating the
threat" that was nominally on paper to other areas.  And the
goal that seems to come up most is "using CA-signed certs."

If one thinks in terms of a protocol designed to use lots of
certs, then SSL would fit that bill;  it explains in some
sense why the user cannot just create their own cert and
use that to talk to their bank.  Instead, the bank must
demand a cert, and thus demand a particular cert, one
which presumably came with specific requirements as okayed
by the bank.  It explains why email using the certs is a
dead duck;  because there is no button on people's mailers
to create a user cert.

Now, I always assumed that what was happening here was that
the original advisers to the SSL team were trying to set up
a franchise to sell certs.  There is quite a lot of evidence
to this effect.  The whole pre-crash history of Verisign is
basically that;  RSADSI had a *lot* to do with it, and they
had a financial interest in Verisign.  In the commentary of
the times, you will see repeated reference to "the search for
the revenue model."  If you recall, Netscape was caught
between a wildly successful IPO and a big barrel of cash,
and no way to return any investment to the shareholders ...

(a bit like google is now ;)

So my personal theory is that the emphasis was placed on
"the cert secures all" because "the cert wil

Re: SSL/TLS passive sniffing

[Eric Rescorla]

"Ben Nagy" <[EMAIL PROTECTED]> writes:
> 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
> cert (for, eg, IDS purposes).
Yep. ssldump (http://www.rtfm.com/ssldump), for instance, will
do this.

> There was some question about whether this is possible for connections that
> use client-certs, since it looks to me from the spec that those connections
> should be using one of the Diffie Hellman cipher suites, which is obviously
> not vulnerable to a passive sniffing 'attack'.
Client certificates and DH key exchange are orthogonal. Client auth
looks just like non client auth SSL except that the client signs
some data with its private key and provides its certificate. In general
it has no effect on the keying material. It's true that there is a mode
where the shared key is derived from the client and server's DH shares
in their certificates (static DH) but to a first order it's never used.

> However, I was wondering why the implementors chose the construction used
> with the RSA suites, where the client PMS is encrypted with the server's
> public key and sent along - it seems to make this kind of escrowed passive
> sniffing very easy. I can't think why they didn't use something based on DH
> - sure you only authenticate one side of the connection, but who cares? Was
> it simply to save one setup packet?

The environment in which SSL was designed to operate was one where 
in general only the server would have a certificate. In this environment,
there are approximately three different approaches:

1. Use RSA as in the current approach.
2. Have the server's DH key in its certificate and the client generates
   a random DH key for each connection. 
3. Have the server generate a new DH key for each connection and 
   sign it with its long-term key.

Now, modes (1) and (2) both have the property that someone with the
server's private key can recover the connection plaintext (you only
need one of the DH shares to recover the shared DH key). Only mode
(3) has the property (called Perfect Forward Secrecy) that having
the long-term key doesn't let you get access to the plaintext.

SSL has all three of these modes, actually, so perhaps the question
you want to ask is why noone uses #3. The main argument against it is
that it's about half as fast (on the server) in the best case because
you need to do both a signature and a key exchange operation.
On the client it's *much* slower because RSA public-key encryption
is very fast (private-key decryption is much slower). 

For obvious reasons, the server operators want to minimize costs
on their side and since they're the ones who would be in a position
to mount this kind of attack, they're probably not overly concerned
about it. And since the users don't demand it...

-Ekr









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

Re: RSA Implementation in C language

[Adam Shostack]

http://www.homeport.org/~adam/crypto/

On Mon, Nov 29, 2004 at 01:47:05PM +0530, Sandeep N wrote:
| 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.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

SSL/TLS passive sniffing

[Ben Nagy]

Hi all,

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
cert (for, eg, IDS purposes).

There was some question about whether this is possible for connections that
use client-certs, since it looks to me from the spec that those connections
should be using one of the Diffie Hellman cipher suites, which is obviously
not vulnerable to a passive sniffing 'attack'. Active 'attacks' will
obviously still work. Bear in mind that we're talking about deliberate
undermining of the SSL connection by organisations, usually against their
website users (without talking about the goodness, badness or legality of
that), so "how do they get the private keys" isn't relevant.

However, I was wondering why the implementors chose the construction used
with the RSA suites, where the client PMS is encrypted with the server's
public key and sent along - it seems to make this kind of escrowed passive
sniffing very easy. I can't think why they didn't use something based on DH
- sure you only authenticate one side of the connection, but who cares? Was
it simply to save one setup packet?

Anyone know?

Cheers,

ben


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

Some Secret: Open House, Open Bar

[R.A. Hettinga]

>Must have passed some kinda big supplemental.

Cheers,
RAH
---



The Washington Post

washingtonpost.com
Round-Trip or One-Way Tickets?


By Al Kamen

 Wednesday, November 24, 2004; Page A19

Some Secret: Open House, Open Bar



Remember a while back when it came out that intelligence agencies such as
the National Security Agency -- the supersecret spy crowd -- did not have
the resources to keep up with the flood of intercepts to be able to
translate terrorists' chatter on a timely basis?

This naturally caused a big fuss, and Congress pledged big bucks to get the
spooks up to speed. Seems to have worked out fine, judging from an invite
we got to attend an open house Dec. 7 at the National Cryptologic Museum
behind the Shell station at Fort Meade.

Lots of fine finger food to be had, including a "brie encrote with brown
sugar and pecans," some "Swiss cheese and chablis stuffed mushroom caps," a
bit of roast turkey with cranberry mayo and "mini pumpkin cheesecakes."

Our very fine invite with the NSA gold-embossed seal notes "Open bar."

Must have passed some kinda big supplemental.

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Lycos screensaver to blitz spam servers

[R.A. Hettinga]

The Register


 Biting the hand that feeds IT


 Original URL: http://www.theregister.co.uk/2004/11/26/lycos_europe_spam_blitz/

Lycos screensaver to blitz spam servers
By Jan Libbenga (libbenga at yahoo.com)
Published Friday 26th November 2004 16:31 GMT

Lycos Europe has started to distribute a special screensaver
(http://makelovenotspam.com/intl) in a controversial bid to battle spam.
The program - titled Make Love Not Spam, and available for Windows and the
Mac OS - sends a request to view a spam source site. When a large number of
screensavers send their requests at the same time the spam web page becomes
overloaded and slow.

The servers targeted by the screensaver have been manually selected from
various sources, including Spamcop, and verified to be spam advertising
sites, Lycos claims. Several tests are performed to make sure that no
server stops working. Flooding a server with requests so that the server is
unable to respond to the volume of requests made - a process known as a
distributed denial of service (DDoS) attack - is considered to be illegal.


Lycos believes the program will eventually hurt spammers. 'Spamvirtised'
sites typically don't sell advertising, so they have to pay for bandwidth.
Therefore more requests means higher bills, Lycos argues.

A spokesman for Lycos in Germany told The Register he believed that the
tool could generate 3.4MB in traffic on a daily basis. When 10m
screensavers are downloaded and used, the numbers quickly add up, to 33TB
of 'useless' IP traffic. Seems Lycos may hurt not just spammers. ®

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

RSA Implementation in C language

[Sandeep N]

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]

ACLU concerned that microchip passports won't be encrypted

[R.A. Hettinga]

The Indianapolis Star

ACLU concerned that microchip passports won't be encrypted

Associated Press
November 27, 2004
  


WASHINGTON -- The Bush administration opposes security measures for new
microchip-equipped passports that privacy advocates contend are needed to
prevent identity theft, government snooping or a terrorist attack,
according to State Department documents released Friday.

The passports would emit radio waves that could be read electronically from
as far away as 30 feet, according to the American Civil Liberties Union,
which obtained the documents under a Freedom of Information Act request.

The ability to remotely read personal data raises the possibility that
passport holders would be vulnerable to identity theft, the ACLU said. It
also would allow government agents to find out covertly who was attending a
political meeting or make it easier for terrorists to target Americans
traveling abroad, the ACLU said.

Frank Moss of the State Department said the United States wants to ensure
the safety and security of Americans traveling abroad. But encrypting the
data might make it more difficult for other countries to read the
passports, Moss said.

All new U.S. passports issued by the end of 2005 are expected to have a
chip containing the owner's name, birth date, issuing office and a
"biometric" identifier -- a photo of the owner's face.
-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

I'm sorry, I haven't a clue

[R.A. Hettinga]

  Guardian |

 Comment
I'm sorry, I haven't a clue

However cracked they may be, our fascination for codes remains
Mark Lawson
Saturday November 27, 2004

The Guardian
The discovery of a code at Shugborough Hall, in Staffordshire -
"O.U.O.S.V.A.V.V" - that may disclose the location of the holy grail has
been widely compared to Dan Brown's super-selling novel The Da Vinci Code.

This Shugborough cryptograph - on which old Bletchley Park codebreakers
have been working - is seen as life imitating art, but the relationship
between popular fiction and reality is more often the reverse. Novels sell
well because they reflect our times: art imitating life, if often in heavy
disguise.

The biggest-selling novels of the 70s - Jaws and The Godfather - concerned
shadowy forces, fish and criminal, beneath the surface of society. We can
now see that these tales reflected the menaces to the American way from the
cold war, Vietnam and Watergate. Similarly, the millions drawn in Britain
at the same period to the animal epic Watership Down were drawn by a
sentimental regret that our traditional way of life was being swamped by
modernity.

So, if bestselling books contain hidden messages about our times, then The
Da Vinci Code, having cryptography as both content and method, may be the
ultimate popular fiction. We can guess that the reason Brown's book has
sold in such quantities is that we live surrounded by codes and puzzles
that we fear may be broken (such as our computer and digital
communications), or that we fear will not be (Osama bin Laden's
instructions to his followers, the "big wedding" in America that turned out
to be 9/11).

It's the same instinct - of fear and fascination with encryption - that
leads people to read both The Da Vinci Code and the newspaper stories about
a supposed clue to the holy grail. And, coincidentally, a new non-fiction
book reveals that one of the world's most famous figures believes that a
secret code gives meaning to his life. The Pope in Winter, by John
Cornwell, discusses John Paul II's conviction that his attempted
assassination in 1981 had been predicted by an apparition of Christ's
mother speaking to Portuguese children in 1917.

But the lesson of both the Shugborough puzzle and the Pope's divine code is
that predictive cryptography - as distinct from practical code-breaking,
such as the Enigma work at Bletchley - works better in fiction than fact.

The problem for code-breakers is that they are often forced to assume that
a setter sophisticated with letters or numbers would be sloppy with grammar
and spelling. Hence, notoriously, Nostradamus, credited by some fans with
predicting the rise of a German tyrant called "Hister", must be assumed to
have had massive predictive powers but limited dictionary skills.

So it is with Shugborough's O.U.O.S.V.A.V.V sequence. Cryptologists suggest
that the letters can be made to say the Hebrew phrase "Why Feather Curve"
or, in Latin, "Best wife, best sister, widower most loving vows
virtuously". But both interpretations feel like the kind of sentence you
end up with after failing to solve a puzzle, rather than what you would
begin with in setting one - a code consists of language to be broken, but
it's not clear why it would be rooted in broken English.

A similar application of linguistic imprecision to an art that should be
precise is the Pope's assumption of the Third Secret of Fatima. This final
dictation given to the Portuguese children by their shimmering vision was
sealed by the Vatican for many decades, leading to much prediction that it
contained the date of the end of the world. There were rumours of popes
fainting when they took the envelope out of their library.

At the turn of the millennium, John Paul II decided to break the code. He
revealed that the long-suppressed message foresaw that a "man in white"
would "fall to the ground". He was convinced that these words anticipated
his shooting in Rome.

In fact, as Cornwell's book points out, you have to arm-lock the prophecy
to get this reading. The seer in Portugal predicted that the white-clad man
would be "killed by a group of soldiers who fired bullets and arrows at
him". Numerous civilians would also die in the attack. This raises the
Nostradamus problem: why would someone with the ability to tell the story
of the future be shown such a corrupted narrative?

The need for codebreakers to ignore the bits that don't fit is why such
puzzles are most satisfying in novels where, unusually, both the cipher and
the solution are provided by the same mind and therefore must match. The
prophecies of Nostradamus have always sold well, but The Da Vinci Code is
Nostradamus without the bits that have proved to be embarrassingly wrong.

Those who believe that the road to the holy grail leads from a stone at
Lord Lichfield's family home should crack this code: T1BEM. The M, if it
helps, is "minute".

-- 
-
R. A. Hett

CFP-2005 Call for Proposals

[R.A. Hettinga]

--- begin forwarded text


Date: Fri, 26 Nov 2004 19:40:48 -0500
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: CFP-2005 Call for Proposals

COMPUTERS, FREEDOM, AND PRIVACY CONFERENCE:
Panopticon 2005

April 12-15, 2005, Westin Hotel, Seattle, WA

www.cfp2005.org

The 15th annual conference on Computers, Freedom & Privacy takes place
from Tuesday, April 12th, to Friday, April 15th, 2005, in Seattle,
Washington.

The Program Committee is now accepting proposals for conference
sessions and speakers for CFP2005. The deadline for submissions is
December 31, 2004

CFP serves as an internationally recognized forum for the members of
the technical, government, hacker, legal, business, education, media,
cyber-rights, and non-profit communities to address cutting edge
technical, business, legal and cultural issues. Programs, topics, and
speakers from prior years' CFP conferences can be found at: www.cfp.org

The CFP2005 Program Committee welcomes proposals on all aspects of
technology, freedom and privacy.  We are particularly interested in
receiving proposals that ask the hard questions about privacy and
freedom in emerging surveillance societies, and challenging those
assumptions.  For example, how much surveillance is too much?  When
does surveillance cease making us more secure and begin to change the
fabric of society?

The theme of the 15th CFP is "Panopticon 2005." Over time, and
particularly recently, surveillance of ordinary citizens has increased
to dramatic levels.  Not only are governments watching more aspects of
their citizens' lives, but those in the private sector are increasing
surveillance of people as well. Often lost in the race to "increase
intelligence" are discussions about different approaches to address
problems like the threat of terrorism that are equally or more
effective, but do not involve extensive and constant surveillance.

In addition to topics directly related to the Panopticon 2005 theme,
other areas of interest include:

1. domestic and international travel issues

2. communications surveillance

3. children and young adults growing up in a surveillance society

4. social networking

5. the flourishing of free speech (i.e. blogging) in spite of increased
watchfulness

6. RFIDs and other emerging technologies

7. Intellectual property issues

We are seeking proposals for tutorials, plenary sessions, workshops,
and birds-of-a-feather sessions. We are also seeking suggestions for
speakers and other relevant topics not listed above. Sessions should
present a wide range of thinking on a topic by including speakers from
different viewpoints. We particularly welcome proposals for non-
traditional presentations - those that utilize drama, "mock trials,"
interactivity, the performing arts, and audience participation.

Complete submission instructions appear on the CFP2005 web site:

www.cfp2005.org

All submissions must be received by December 31, 2004.  The CFP2005
Program Committee will notify submitters of the status of their
proposals by January 20, 2005.


Note: you have received this mailing because you were an attendee at
a previous CFP conference or because you have requested information
about CFP.

If you wish to be removed from our mailing list, please send your
request to:[EMAIL PROTECTED]and be sure to note the exact email
address at which you received this communication so we can purge it
from the list.

Please address all other queries to:  [EMAIL PROTECTED] Please do
not respond to the address on this announcement; mail to this address
is discarded without being read.


--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

MyKad too hi-tech to forge

[R.A. Hettinga]

The Star Online > News
Saturday November 27, 2004

MyKad too hi-tech to forge


BY JANE RITIKOS

KUALA LUMPUR: The National Registration Department has detected about 10
cases of forged MyKad issued to illegal immigrants in the country since it
was introduced in 2001. 

 However, the chips in the cards were not forged ones. 

 Its director-general Datuk Wan Ibrahim Wan Ahmad said those caught with
the fake cards were Indonesians and Bangladeshis, who claimed they had paid
about RM200 for the card.  

 The fake cards looked like genuine ones except that the forgers could not
duplicate the smart chip imbedded in MyKad.  

 "The physical appearance of the card looks real but the chip, a vital
component of the card, is functionless and cannot be used for transactions.
 

 "This is because the features of the MyKad chip are so high-tech that they
cannot be duplicated. Even if they could make a forged chip it has no data
that is linked to our database," he said.  

 Wan Ibrahim also said the chip in the fake MyKad was not readable.  

 "We don't believe the chip can ever be forged. The information in our chip
has data and biometric features," he said.  

 The MyKad chip stores information of the cardholders including their
identity cards, driving licences, passports and health data. 

 Wan Ibrahim said there were also those caught with fake MyKad which had
their laminated sheet tampered with to alter the physical details and
picture.  

 "When these cards are read, the identity of the bearer is that of someone
else. These included those who were checked at the Immigration checkpoints
at the airport. At a glance the cards looked real," he added.  


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

"Proving" the correctness of a network encryption system test system

[Fredrik Henbjork]

Alice has:
1. A system which does processing of encrypted network streams.
Alice wants the following from Bob:
2. A test system for the processing system in 1. This system is going to
be used to decide if the processing system in 1 is working (processing)
as it should.
3. A test system for the test system in 2. This system is going to be 
used
to decide if the test system in 2 is working (testing) as it should.

4. A specification for the test system in 3. This specification shall 
contain
explicit and well defined critera for how to decide that the test 
system in 2
is working (testing) as it should.

So the question really is; how does Bob convince Alice that the test 
system in
2 works (tests) as it should? Alice does not need strict formal 
mathematical
proofs for the correctness of 2, but neither is she going to be 
satisfied by
hearing Bob (in his best Snake Oil voice) say: "Trust me, I know what 
I'm
doing..." Does anyone have any good pointers to information about 
problems like
these?

Thanks in advance,
Fredrik Henbjork
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Hacking tool 'draws FBI subpoenas'

[R.A. Hettinga]

The Register


 Biting the hand that feeds IT

The Register » Security » Network Security »

 Original URL:
http://www.theregister.co.uk/2004/11/25/nmap_draws_fbi_subpoenas/

Hacking tool 'draws FBI subpoenas'
By Kevin Poulsen, SecurityFocus (klp at securityfocus.com)
Published Thursday 25th November 2004 10:42 GMT

The author of the popular freeware hacking tool Nmap warned users this week
that FBI agents are increasingly seeking access to information from the
server logs of his download site, insecure.org.

"I may be forced by law to comply with legal, properly served subpoenas,"
wrote "Fyodor," the 27-year-old Silicon Valley coder responsible for the
post scanning tool, in a mailing list message. "At the same time, I'll try
to fight anything too broad... Protecting your privacy is important to me,
but Nmap users should be savvy enough to know that all of your network
activity leave traces."

Probably the most widely-used freeware hacking tool, Nmap is a
sophisticated port scanner that sends packets to a machine, or a network of
machines, in an attempt to discern what services are running and to make an
educated guess about the operating system. An Nmap port scan is a common
prelude to an intrusion attempt, and the tool is popular both with security
professionals performing penetration tests, and genuine intruders with
mischief in their hearts.

Last year Nmap crept into popular culture when the movie the Matrix
Reloaded depicted Carrie-Anne Moss's leather-clad superhacker Trinity
performing an Nmap portscan
(http://www.theregister.co.uk/2003/05/16/matrix_sequel_has_hacker_cred/) on
a power grid computer prior to hacking in.

But success comes with a price, and on Tuesday Fyodor felt the need to
broach the "sobering topic" of FBI subpoenas with his users. He advised his
most privacy conscious users to use proxy servers or other techniques when
downloading the latest version of Nmap if they want to ensure their
anonymity.

In a telephone interview, Fyodor said the disclaimer wasn't prompted by any
particular incident, and that he'd received "less than half-a-dozen"
subpoenas this year. "It's not a huge number, but I hadn't received any
before 2004, and so it's a striking new issue," he said.

None of the subpoenas produced anything, Fyodor says, either because they
sought old information that had already been deleted from his logs, or
because the subpoenas were improperly served. In every case the request has
been narrowly crafted, usually directed at finding out who visited the site
(http://www.insecure.org/) in a very short window of time, such as a five
minute period. "They have not made any broad requests like, 'Give me anyone
who's visited insecure.org for a certain day,'" he says.

Fyodor theorizes the FBI is investigating cases in which an intruder
downloaded Nmap directly onto a compromised machine. "They assume that she
might have obtained that URL by visiting the Nmap download page from her
home computer," he wrote.

He confesses mixed feelings over the issue. "The side of me that questions
authority is skeptical of these subpoenas," he told SecurityFocus. "The
other side says, this may be a very serious crime committed ... and if I
were the victim of such a crime I would probably want people to cooperate"

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

QotD

[Udhay Shankar N]

found at http://webpages.charter.net/allanms/2004/07/instant-immortality.html
"Amateurs study cryptography; professionals study economics."
(Bob Hettinga, this is your cue. :)
Udhay
--
((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com))
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]