Re: Full Disk Encryption solutions selected for US Government use

[Ian G]

Peter Gutmann wrote:

Ben Laurie <[EMAIL PROTECTED]> writes:

Peter Gutmann wrote:



Given that it's for USG use, I imagine the FIPS 140 entry barrier for the
government gravy train would be fairly effective in keeping any OSS products
out.

? OpenSSL has FIPS 140.


But if you build a FDE product with it you've got to get the entire product
certified, not just the crypto component.

(Actually given the vagueness of what's being certified you might be able to
get away with getting just one corner certified, but then if you have to use a
SISWG mode you'd need to modify OpenSSL, which in turn means getting another
certification.  Or the changes you'd need to make to get it to work as a
kernel driver would require recertification, because you can't just link in
libssl for that.  Or...).



A slightly off-topic question:  if we accept that current 
processes (FIPS-140, CC, etc) are inadequate indicators of 
quality for OSS products, is there something that can be 
done about it?  Is there a reasonable criteria / process 
that can be built that is more suitable?


iang

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

Re: Full Disk Encryption solutions selected for US Government use

[Arshad Noor]

Saqib,

ALL the solutions include a KMS.  They all must, because encryption keys
must be generated, escrowed, recovered, managed, policies defined, etc.
for any encryption to work.

And *that* is the problem - each of the KMSs is implemented in the 
vendors own design, using the vendor's proprietary API and protocol.
Since the DAR RFP finally settled on 9 different FDE solutions, the 
end-result is that the agencies must now manage nine different KMSs 
and deal with all that that entails: 9 different KMS implementations,
9 different operating procedures, 9 different training sessions, 9 
different audits, and on and on...

In reality, the agencies are probably going to have to manage more than
9 KMS, because the RFP did not address encryption of databases, devices
(other than disks) and application data that is not persisted to disk.

And that is the precise problem that StrongKey addresses.  It is a single
enterprise-wide symmetric key-management system (SKMS) that provides an
open-source API for any application to integrate, and a potential OASIS
protocol that can work in most environments and platforms.  Our design
goal for StrongKey was that it must function like DNS or DHCP - a 
centralized server environment that defines and manages all KM functions
and a single library on the client to handle requests for any application
on the client while using an industry-standard protocol to get KM services 
from the server, securely.

Even the IEEE 1619.3 WG has recognized the importance of integrating 
their KM protocol for storage devices into an Enterprise Key Management 
Infrastructure (EKMI) and has carved out a name-space within its protocol 
for the OASIS work.

WRT transparency, StrongKey provides key-management services - not FDE - 
unless an OS driver integrated the StrongKey API or the SKSML protocol.  
The open-source implementation provides file, directory and column-level 
database encryption - but does not perform any of this automatically unless 
the application has integrated the Symmetric Key Client Library (SKCL) into
it.

While the standard response to this statement is - "applications will never
get modified to perform encryption and that all customers want automatic
and transparent encryption/decryption at the storage layer", our contention 
is that once you automatically encrypt/decrypt at the disk-drive layer, the 
attackers will just move up one layer above the application/OS stack and 
read-off the plaintext (see slides 21 and 22 for graphics) as the disk-drive
decrypts it for them.  Customers will then need to encrypt at a higher-layer
to protect data agin:

http://www.oasis-open.org/committees/download.php/24594/ekmi-webinar.pdf

Customers need to protect data - but they do not need to address the same
problem more than once.  Encrypting at the disk-firmware layer is a short-
term solution that will diminish in protection-value very quickly.  Until
the data is encrypted/decrypted in the final application that uses it, 
attackers will keep moving up the application stack.  

Note that this does not mean that encryption-enabled applications are
invulnerable to attacks; all it means is that the attack-surface has now
been reduced to a minimum and that developers/security professionals can
focus their energy on protecting the area that matters most - the actual
applications that use sensitive data.

Arshad Noor
StrongAuth, Inc.

- Original Message -
From: "Saqib Ali" <[EMAIL PROTECTED]>
To: "Arshad Noor" <[EMAIL PROTECTED]>
Cc: "Cryptography" 
Sent: Monday, October 8, 2007 11:52:28 AM (GMT-0800) America/Los_Angeles
Subject: Re: Full Disk Encryption solutions selected for US Government use

Arshad,

Some of the solutions already include a KMS. One of the key
requirements of this particular RFP was "Transparency". Can you please
elaborate more on how StrongKey KMS would have improved on
transparency?

Thanks
saqib
http://security-basics.blogspot.com/



On 10/8/07, Arshad Noor <[EMAIL PROTECTED]> wrote:
> We submitted a letter to the Program Manager, that while they RFP
> was asking for an FDE solution, they really needed to focus on Key
> Management across the agency, rather than the actual encryption
> solution itself, before they deployed any encryption product.
>
> We proposed our open-source Symmetric Key Management System (SKMS)
> software - StrongKey - as a solution since it includes utilities to
> perform file, directory and column-level database encryption using
> FIPS-certified tokens: smartcards, HSMs and software modules (NSS).
>
> Given that the solution we proposed was OSS, that it could leverage
> any FIPS-certified token through their published JCE/PKCS11 library,
> and that the StrongKey protocol is winding its way through OASIS
> towards becoming the Symmetric Key Services Markup Language (SKSML)
> with the support of 33 companies/individuals including the DoD, we
> believed that this solution was optimal for the government from many
> different points of view.
>

Re: Trillian Secure IM

[Steven M. Bellovin]

On Mon, 8 Oct 2007 09:17:48 -0700
"Alex Pankratov" <[EMAIL PROTECTED]> wrote:

>
> I am actually curious to see what was the DH modulus size in 
> T's versions that were blocked by AOL. Given T's installation
> base, strong SecureIM would've dramatically complicated "lawful 
> intercepts", which AOL is probably required to implement.
> 
They're not required to decrypt anything unless they're providing the
keys.  The lawful intercept requirement is to deliver the ciphertext in
this case.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

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

Re: Full Disk Encryption solutions selected for US Government use

[Ali, Saqib]

Arshad,

Some of the solutions already include a KMS. One of the key
requirements of this particular RFP was "Transparency". Can you please
elaborate more on how StrongKey KMS would have improved on
transparency?

Thanks
saqib
http://security-basics.blogspot.com/



On 10/8/07, Arshad Noor <[EMAIL PROTECTED]> wrote:
> We submitted a letter to the Program Manager, that while they RFP
> was asking for an FDE solution, they really needed to focus on Key
> Management across the agency, rather than the actual encryption
> solution itself, before they deployed any encryption product.
>
> We proposed our open-source Symmetric Key Management System (SKMS)
> software - StrongKey - as a solution since it includes utilities to
> perform file, directory and column-level database encryption using
> FIPS-certified tokens: smartcards, HSMs and software modules (NSS).
>
> Given that the solution we proposed was OSS, that it could leverage
> any FIPS-certified token through their published JCE/PKCS11 library,
> and that the StrongKey protocol is winding its way through OASIS
> towards becoming the Symmetric Key Services Markup Language (SKSML)
> with the support of 33 companies/individuals including the DoD, we
> believed that this solution was optimal for the government from many
> different points of view.
>
> However, because the RFP was narrowly written for FDE products only,
> our submission was not accepted.  That's life in the Federal
> procurement lane they think they're buying a state of the art
> security solution and they don't realize that the state of the art
> has already shifted under their feet.
>
> Arshad Noor
> StrongAuth, Inc.
>
> - Original Message -
> From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>
> On Mon, 18 Jun 2007 22:57:36 -0700
> "Ali, Saqib" <[EMAIL PROTECTED]> wrote:
>
> > US Government has select 9 security vendors that will product drive
> > and file level encryption software.
> >
> > See:
> > http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html
> > OR
> > http://tinyurl.com/2xffax
> >
>
> Out of curiousity, are any open source FDE products being evaluated?
>
> -
> 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: Trillian Secure IM

[Leichter, Jerry]

| > But, opportunistic cryptography is even more fun.  It is 
| > very encouraging to see projects implement cryptography in 
| > limited forms.  A system that uses a primitive form of 
| > encryption is many orders of magnitude more secure than a 
| > system that implements none.
| 
| Primitive form - maybe, weak form - absolutely not. It 
| is actually worse than having no security at all, because 
| it tends to create an _illusion_ of protection. 
This is an old argument.  I used to make it myself.  I even used to
believe it.  Unfortunately, it misses the essential truth:  The choice
is rarely between really strong cryptography and weak cryptography; it's
between weak cryptography and no cryptography at all.  What this
argument assumes is that people really *want* cryptography; that if you
give them nothing, they'll keep on asking for it; but if you give them
something weak, they'll stop asking and things will end there.  But in
point of fact hardly anyone knows enough to actually want cryptography.
Those who know enough will insist on the strong variety whether or not
the weak is available; while the rest will just continue with whatever
they have.

| Which is by the way exactly the case with SecureIM. How 
| hard is it to brute-force 128-bit DH ? My "guesstimate"
| is it's an order of minutes or even seconds, depending
| on CPU resources.
It's much better to analyze this in terms of the cost to the attacker
and the defender.  If the defender assigns relatively low value to his
messages, an attack that costs the attacker more than that low value is
of no interest.  Add in the fact that an attacker may have to break
multiple message streams before he gets to one that's worth anything at
all.

Even something that takes a fraction of a second to decrypt raises the
bar considerably for an attacker who just surfs all conversations,
scanning for something of interest.  It's easy to search for a huge
number of keywords - or even much more complex patterns - in parallel at
multi-megabyte/second speeds with fgrep-like (Aho-Corasick) algorithms.
A little bit of decryption tossed in there changes the calculations
completely.

I'm not going to defend the design choices here because I have no idea
what the protocol constraints were, what the attack model was (or even
if anyone actually produced one), what the hardware base was assumed to
be at the time this was designed, etc.  Perhaps it's just dumb design;
perhaps this was the best they could do.  Could it be better?  Of
course.  Is it better to not put a front door on your house because
the only ones permitted for appearance's sake are wood and can be
broken easily?
-- Jerry


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

Re: Full Disk Encryption solutions selected for US Government use

[Stephan Somogyi]

At 02:11 +1300 09.10.2007, Peter Gutmann wrote:


But if you build a FDE product with it you've got to get the entire product
certified, not just the crypto component.


I don't believe this to be the case.

FIPS 140(-2) is about validating cryptographic implementations. It is 
not about certifying entire products that contain ample functionality 
well outside the scope of cryptographic evaluation. That's more of a 
Common Criteria thing.


That said, one problem with selling FIPSed products to USG is that 
some auditors are sticklers for version numbers. They can require 
proof/rep&warrant that the FIPSed version of the crypto is actually 
in use.


Audit appeasement requirements frequently cause considerable 
annoyance to both vendors and the end user.


At 14:04 +0100 08.10.2007, Ben Laurie wrote:


? OpenSSL has FIPS 140.


OpenSSL FIPS Object Module 1.1.1 has FIPS 140-2 when running on SUSE 
9.0 and HPUX 11i, according to




In the context of a conversation about whether something formally has 
FIPS validation or not, the details are important.


Back to the original question...

At 11:27 + 08.10.2007, Steven M. Bellovin wrote:


Out of curiousity, are any open source FDE products being evaluated?


As far as I recall, none such were submitted for consideration. Bear 
in mind that the process isn't just about software, but that a 
commercial entity submits both a product that meets the list of 
capability checkboxes, and that the entity itself is viable and can 
provide support and the like.


s.

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

Re: Full Disk Encryption solutions selected for US Government use

[Arshad Noor]

We submitted a letter to the Program Manager, that while they RFP
was asking for an FDE solution, they really needed to focus on Key
Management across the agency, rather than the actual encryption
solution itself, before they deployed any encryption product.  

We proposed our open-source Symmetric Key Management System (SKMS) 
software - StrongKey - as a solution since it includes utilities to 
perform file, directory and column-level database encryption using 
FIPS-certified tokens: smartcards, HSMs and software modules (NSS).

Given that the solution we proposed was OSS, that it could leverage
any FIPS-certified token through their published JCE/PKCS11 library,
and that the StrongKey protocol is winding its way through OASIS 
towards becoming the Symmetric Key Services Markup Language (SKSML) 
with the support of 33 companies/individuals including the DoD, we 
believed that this solution was optimal for the government from many 
different points of view.

However, because the RFP was narrowly written for FDE products only,
our submission was not accepted.  That's life in the Federal
procurement lane they think they're buying a state of the art
security solution and they don't realize that the state of the art
has already shifted under their feet.  

Arshad Noor
StrongAuth, Inc.

- Original Message -
From: "Steven M. Bellovin" <[EMAIL PROTECTED]>

On Mon, 18 Jun 2007 22:57:36 -0700
"Ali, Saqib" <[EMAIL PROTECTED]> wrote:

> US Government has select 9 security vendors that will product drive
> and file level encryption software.
> 
> See:
> http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html
> OR
> http://tinyurl.com/2xffax
> 

Out of curiousity, are any open source FDE products being evaluated?

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

RE: Trillian Secure IM

[Alex Pankratov]

 

> -Original Message-
> From: Marcos el Ruptor [mailto:[EMAIL PROTECTED] 
> Sent: Monday, October 08, 2007 6:21 AM
> To: Alex Pankratov
> Cc: cryptography@metzdowd.com
> Subject: Re: Trillian Secure IM
> 
> I found those threads:
> 
> http://forums.ceruleanstudios.com/showthread.php?t=53433
> 
> http://forums.ceruleanstudios.com/showthread.php?t=56207
> 
> As you can see from the last post in the second thread, ultimately  
> they agreed that 128-bit DH is secure and that I am just some crazy  
> guy trying to scare them.

Yickes. Ignorance is a bliss. 

I am actually curious to see what was the DH modulus size in 
T's versions that were blocked by AOL. Given T's installation
base, strong SecureIM would've dramatically complicated "lawful 
intercepts", which AOL is probably required to implement.

Alex

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

RE: Trillian Secure IM

[Alex Pankratov]

 

> -Original Message-
> From: Ian G [mailto:[EMAIL PROTECTED] 
> Sent: Monday, October 08, 2007 6:05 AM
> To: Peter Gutmann
> Cc: [EMAIL PROTECTED]; cryptography@metzdowd.com
> Subject: Re: Trillian Secure IM
> 
> Peter Gutmann wrote:
> > "Alex Pankratov" <[EMAIL PROTECTED]> writes:
> > 
> >> SecureIM handshake between two version 3.1 (latest) 
> clients takes about .. 48
> >> bytes. That's altogether, 32 bytes in one direction, and 
> 16 in another. And
> >> that's between the clients that have never talked to each 
> other before, so
> >> there's no "session resuming" business happenning.
> > 
> > Or they could be using static/ephemeral DH with fixed 
> shared DH key values,
> > which isn't much better.  (This is just speculation, it's 
> hard to tell without
> > knowing what the exchanged quantities are).
> 
> 
> Speculation is fun.
> 
> But, opportunistic cryptography is even more fun.  It is 
> very encouraging to see projects implement cryptography in 
> limited forms.  A system that uses a primitive form of 
> encryption is many orders of magnitude more secure than a 
> system that implements none.

Primitive form - maybe, weak form - absolutely not. It 
is actually worse than having no security at all, because 
it tends to create an _illusion_ of protection. 

Which is by the way exactly the case with SecureIM. How 
hard is it to brute-force 128-bit DH ? My "guesstimate"
is it's an order of minutes or even seconds, depending
on CPU resources.

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

Re: Trillian Secure IM

[Dave Howe]

Marcos el Ruptor wrote:

If that's DH exchange, then it's 128 bit one. Fertile ground
for some interesting speculation, don't you think ?


There is no speculation. It is 128-bit DH.

I have reported over three years ago to the Trillian forum that they are 
using 128-bit DH and that it is not secure. You can look up my messages 
about it and how much I got abused for it by everyone trying to explain 
to me that 1) it IS secure and 2) no one cares anyway. They did not 
change it since then although they promised to. 


Had a look, but it seems to me they said they wouldn't fix it unless 
there was an actual, active exploit for it, and my guess would be even 
then they would just make cosmetic changes to stop that particular 
instance of an exploit from working..


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

Re: Trillian Secure IM

[Marcos el Ruptor]

I found those threads:

http://forums.ceruleanstudios.com/showthread.php?t=53433

http://forums.ceruleanstudios.com/showthread.php?t=56207

As you can see from the last post in the second thread, ultimately  
they agreed that 128-bit DH is secure and that I am just some crazy  
guy trying to scare them.


Ruptor

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

Re: Full Disk Encryption solutions selected for US Government use

[Peter Gutmann]

Ben Laurie <[EMAIL PROTECTED]> writes:
>Peter Gutmann wrote:
>> "Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>>> On Mon, 18 Jun 2007 22:57:36 -0700 "Ali, Saqib" <[EMAIL PROTECTED]> wrote:
 US Government has select 9 security vendors that will product drive
 and file level encryption software.
>> Out of curiousity, are any open source FDE products being evaluated?
>>
>> Given that it's for USG use, I imagine the FIPS 140 entry barrier for the
>> government gravy train would be fairly effective in keeping any OSS products
>> out.
>
>? OpenSSL has FIPS 140.

But if you build a FDE product with it you've got to get the entire product
certified, not just the crypto component.

(Actually given the vagueness of what's being certified you might be able to
get away with getting just one corner certified, but then if you have to use a
SISWG mode you'd need to modify OpenSSL, which in turn means getting another
certification.  Or the changes you'd need to make to get it to work as a
kernel driver would require recertification, because you can't just link in
libssl for that.  Or...).

Peter.

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

Re: Full Disk Encryption solutions selected for US Government use

[Ben Laurie]

Peter Gutmann wrote:
> "Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>> On Mon, 18 Jun 2007 22:57:36 -0700 "Ali, Saqib" <[EMAIL PROTECTED]> wrote:
>>> US Government has select 9 security vendors that will product drive
>>> and file level encryption software.
>> Out of curiousity, are any open source FDE products being evaluated?
> 
> Given that it's for USG use, I imagine the FIPS 140 entry barrier for the
> government gravy train would be fairly effective in keeping any OSS products
> out.

? OpenSSL has FIPS 140.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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

Re: Trillian Secure IM

[Marcos el Ruptor]

If that's DH exchange, then it's 128 bit one. Fertile ground
for some interesting speculation, don't you think ?


There is no speculation. It is 128-bit DH.

I have reported over three years ago to the Trillian forum that they  
are using 128-bit DH and that it is not secure. You can look up my  
messages about it and how much I got abused for it by everyone trying  
to explain to me that 1) it IS secure and 2) no one cares anyway.  
They did not change it since then although they promised to. I'd also  
made an open-source replacement DLL back then with 512-bit ECDH,  
which also supported their 128-bit DH clients if they initiated  
secure communication first, but it may have some compatibility issues  
with later versions of Trillian. It's supposed to display the common  
key fingerprint, not sure if it works now. Feel free to correct it  
and to improve it, but Cerulean Studios won't pay for it. It's still  
on http://cryptolib.com/ruptor/


Marcos el Ruptor

PS: There was also a buffer overflow in their original DLL if you  
send a very long key. I don't know if they have fixed it or not. I  
haven't used Trillian since I bought a Mac.


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

Re: Full Disk Encryption solutions selected for US Government use

[Peter Gutmann]

"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>On Mon, 18 Jun 2007 22:57:36 -0700 "Ali, Saqib" <[EMAIL PROTECTED]> wrote:
>> US Government has select 9 security vendors that will product drive
>> and file level encryption software.
>
>Out of curiousity, are any open source FDE products being evaluated?

Given that it's for USG use, I imagine the FIPS 140 entry barrier for the
government gravy train would be fairly effective in keeping any OSS products
out.

Peter.

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

Re: Trillian Secure IM

[Peter Gutmann]

"Alex Pankratov" <[EMAIL PROTECTED]> writes:

>SecureIM handshake between two version 3.1 (latest) clients takes about .. 48
>bytes. That's altogether, 32 bytes in one direction, and 16 in another. And
>that's between the clients that have never talked to each other before, so
>there's no "session resuming" business happenning.

Or they could be using static/ephemeral DH with fixed shared DH key values,
which isn't much better.  (This is just speculation, it's hard to tell without
knowing what the exchanged quantities are).

Peter.

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

Re: Full Disk Encryption solutions selected for US Government use

[Steven M. Bellovin]

On Mon, 18 Jun 2007 22:57:36 -0700
"Ali, Saqib" <[EMAIL PROTECTED]> wrote:

> US Government has select 9 security vendors that will product drive
> and file level encryption software.
> 
> See:
> http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html
> OR
> http://tinyurl.com/2xffax
> 

Out of curiousity, are any open source FDE products being evaluated?


--Steve Bellovin, http://www.cs.columbia.edu/~smb

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

Trillian Secure IM

[Alex Pankratov]

Hi,

I've been poking around Oscar (ICQ/AIM) protocol parsing 
and had a look at Trillian's SecureIM handshake protocol.

For those who don't know, Trillian is a very popular multi-
protocol instant messanging application for Windows. One of
its notable features, for which is got some rave/positive
reviews, is an ability to encrypt ICQ/AIM IMs exchanged by 
two Trillian instances. AOL made repeated attempts to block 
SecureIM, but eventually stopped them [1].

The protocol is closed, but it was reversed engineered by
some guys over at GAIM project. It appeared to be a Blowfish
encryption of bulk IMs using a key derived from an anonymous 
DH exchange [2]. This was also indirectly confirmed by another
project [3].

Leaving aside the lack of authentication and replay protection,
here's what is even more striking -

SecureIM handshake between two version 3.1 (latest) clients 
takes about .. 48 bytes. That's altogether, 32 bytes in one 
direction, and 16 in another. And that's between the clients 
that have never talked to each other before, so there's no 
"session resuming" business happenning.

If that's DH exchange, then it's 128 bit one. Fertile ground
for some interesting speculation, don't you think ?

Alex

[1]
http://en.wikipedia.org/wiki/Trillian_%28instant_messenger%29#Entry_into_mai
nstream_and_the_.22IM_Wars.22
[2]
http://sourceforge.net/tracker/download.php?group_id=235&atid=300235&file_id
=56799&aid=777300
[3] http://code.google.com/p/joscar/wiki/TrillianSecureIm


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