Re: [cryptography] Asynchronous forward secrecy encryption
Thats a good approach but note it does assume your messages are delivered in
the same order they are sent (even though they are delivered
asynchronously). That is generally the case but does not have to be -
neither email nor UDP for example guarantee that.
Maybe you would want to include an authenticated sequence number so the
recipient can detect gaps and out of order messages, though that does create
an attack where the attacker can delete a message, and cause the recipient
to keep messages.
Or better the actual key used could be derived to fix that. eg
k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i values. In
that way you can keep keys for a gap with no security implication other than
the missing/delayed message security. Other messages that come afterwards
would be unaffected.
Adam
On Tue, Sep 17, 2013 at 04:14:09PM -0700, Trevor Perrin wrote:
On Tue, Sep 17, 2013 at 2:01 PM, Michael Rogers
mich...@briarproject.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Marco,
This is a problem we're working on as part of the Briar project. Our
approach is pretty simple: establish a shared secret when you first
communicate, periodically run that secret through a one-way function
to get a new shared secret, and destroy the old one.
Why not have separate symmetric keys for each direction of
communication (Alice - Bob, Bob-Alice).
Then whenever a party encrypts or decrypts a message, they can update
the corresponding key right away, instead of having to wait.
(Or look at OTR's use of updating Diffie-Hellmans).
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On 18/09/13 00:01 AM, Michael Rogers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marco, This is a problem we're working on as part of the Briar project. Our approach is pretty simple: establish a shared secret when you first communicate, periodically run that secret through a one-way function to get a new shared secret, and destroy the old one. Symmetric keys for encryption and authentication are derived from the current shared secret. If I compromise your first shared secret, does that mean every shared secret thereafter is compromised? The rotation period depends on the latency of the underlying communication channel. For example, if you're communicating by email, you might rotate to a new shared secret once a week, to allow the other party to spend a week offline without losing any messages. How do you coordinate between endpoints for the rotation? Is it strictly time-based? Or is there some sense of searching the space by hashing forward multiple rotations until the message decrypts? On the other hand if you're communicating by SD cards attached to migrating geese, you might rotate less often. Ah, but does it consider the pâté attack? ;) On 16/09/13 12:45, Marco Pozzato wrote: I'm looking for an asynchronous messaging protocol with support for forward secrecy: I found some ideas, some abstract paper but nothing ready to be used. Without some idea of the problem space you are trying to address, it's hard to do more than pluck ideas from existing protocols. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 00:14, Trevor Perrin wrote: Why not have separate symmetric keys for each direction of communication (Alice - Bob, Bob-Alice). We derive separate keys for each direction from the shared secret. Then whenever a party encrypts or decrypts a message, they can update the corresponding key right away, instead of having to wait. (Or look at OTR's use of updating Diffie-Hellmans). We did look at OTR, but unfortunately it's not suitable for our use case. We want to be able to operate over a wide range of communication channels, including one-way channels and unreliable, high-latency channels like the postal service. OTR's forward secrecy requires an ongoing back-and-forth between the two parties. Our approach doesn't provide forward secrecy as quickly as OTR's if there's a constant back-and-forth, but it tolerates lost and reordered messages, one-way communication, and long pauses in communication. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSObasAAoJEBEET9GfxSfMrRQH/1DKnD3NhMeKgX3CY/Wk0LrR MLM3SBd6rCHYh3kcVFmR/e08jaTRIF00/6FWJMCRgB5MAxU3iP/9+fXuLhQGHM4u O3nF2PXBnDYGv+bDwyDhErea9RjfFqIh7MIe2m6VgtOv399aiIvbUH0WrK6RADL3 Gz/VmCKZPZD6ZhPj67YQKOfG7BBmAY3znCCGv+yxDaoxGygqdydOGqRQaAumnAie 5Gvmmc63JYQTlFGd6MUgxa2HJben9PkE1mz5Qy5nlUnUY+fcoLRr9OznTxGTS7cT W5fU00g95SCUwT3q2cBxNV6J8RMCedWuDyP1htrZcAVEs5ZLk9t/U71IqQOfccE= =JYLo -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/09/13 08:12, Adam Back wrote:
Or better the actual key used could be derived to fix that. eg
k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i
values. In that way you can keep keys for a gap with no security
implication other than the missing/delayed message security.
Other messages that come afterwards would be unaffected.
This is very close to the way we currently derive keys. We also derive
a pseudo-random tag corresponding to each key, which is prepended to
the encrypted data so the recipient can detect reordering (using a
sliding window as in IPSec) and use the correct key.
However, this approach is fragile because it requires persistent
storage of a counter - if the app crashes after using a key but before
persistently storing the updated counter, you can end up reusing a
key. Unfortunately, since hard disks and operating systems lie about
having persistently stored data, this can happen even if you store the
counter and call fsync before using the key. So we're moving to a less
fragile approach:
* Rotate the shared secret periodically
* Derive temporary encryption and authentication keys for each
direction from the current shared secret
* Each time you want to send some data, generate a random IV and
ephemeral encryption and authentication keys
* Use the temporary keys and the random IV to encrypt and authenticate
the ephemeral keys
Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJSObpCAAoJEBEET9GfxSfMrKIH/jfQwJzBaPLx7uKzJdoGHQkJ
8NWSYh3/YePrY8Ukbx9qZUMyBwghRecgf0u/pJeId5+fktgc2u1BVXQCekBIyYCO
YSxmHBDsfQ3cC+5JRMH8U7JwsRMvWDBYJdDCX3IR4ofGJ7+aaJuwqo13vhoToO4C
kkPGvXIvTSpP6YLSvy1wlbHwFy9hb3e3ywvt91jsGvk/nIfBX+eQLEixu/HqjVkN
g6IGvyMgm7B5m5puiodwH7k3fL0vIkdnWAtQZu7S3UztovyFqaJY34NCV+JgusYD
X0cmojyKf1/quePi8exMkeQaibrOPUG3a+O8f+Jhld3Gfv4fyO8EIK3PVoKIMbY=
=2Vz/
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 08:23, ianG wrote: If I compromise your first shared secret, does that mean every shared secret thereafter is compromised? Yes. (Improvements are possible here, by sending and acking fresh key material inside the encrypted envelopes, but that requires two-way communication, so in the one-way case we'd always be vulnerable to the initial secret being compromised.) How do you coordinate between endpoints for the rotation? Is it strictly time-based? Or is there some sense of searching the space by hashing forward multiple rotations until the message decrypts? It's strictly time-based. The rotation period is based on the maximum latency of the communication channel and the maximum difference between the endpoints' clocks, such that if the sender thinks it's rotation period p at the time of sending, the recipient will think it's no earlier than period p-1 and no later than period p+1 at the time of receipt. If the endpoints have very inaccurate clocks, you get longer rotation periods but the protocol still works - as long as the endpoints know roughly how inaccurate their clocks might be. Ah, but does it consider the pâté attack? ;) Is that a type of meat-in-the-middle attack? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSOb2KAAoJEBEET9GfxSfMae8IAMR0HxXQYUwIgJrQ5byQnIdO /z8frXW4qhBKtyt+zimpS1N0qBxg5hbQKoSYqSsIq/Et80/Lmjivnv/bHrVvfCeI RX0aFVvZi3BXthuYqr8x/AAbYun9y/jGAz6UoIDyXXA9oljom//e5AqZK3p9o9sg eWDltbuc4R5QBMEeMvbL7MM5PxrpSEVGfh0KzQZFn/MOCg6pjDuXWnfWWajf1Eg0 FZvaGNKu9DmNU9hxI8MOZePmiTy9S/Bjayp6Syt1cJTKKT9lT8IQJwRb1tERf/Go DqrdZBUZmsR1CIlzy9eS2XSUD4hyBqfp+Y2hjWanzsA1JWx7XrcDxxy5jTRJ3+c= =R1L+ -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Wed, Sep 18, 2013 at 7:35 AM, Michael Rogers
mich...@briarproject.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/09/13 08:12, Adam Back wrote:
Or better the actual key used could be derived to fix that. eg
k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i
values. In that way you can keep keys for a gap with no security
implication other than the missing/delayed message security.
Other messages that come afterwards would be unaffected.
This is very close to the way we currently derive keys. We also derive
a pseudo-random tag corresponding to each key, which is prepended to
the encrypted data so the recipient can detect reordering (using a
sliding window as in IPSec) and use the correct key.
However, this approach is fragile because it requires persistent
storage of a counter - if the app crashes after using a key but before
persistently storing the updated counter, you can end up reusing a
key. Unfortunately, since hard disks and operating systems lie about
having persistently stored data, this can happen even if you store the
counter and call fsync before using the key. So we're moving to a less
fragile approach:
* Rotate the shared secret periodically
Hmm, I would've thought clocks are *less* reliable than storage on most devices.
Certainly this has worse forward-secrecy than updating keys
per-message, as keys for old ciphertext are kept around for some
period.
Trevor
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Wed, Sep 18, 2013 at 12:12 AM, Adam Back a...@cypherspace.org wrote:
Thats a good approach but note it does assume your messages are delivered in
the same order they are sent (even though they are delivered
asynchronously). That is generally the case but does not have to be -
neither email nor UDP for example guarantee that.
Maybe you would want to include an authenticated sequence number so the
recipient can detect gaps and out of order messages, though that does create
an attack where the attacker can delete a message, and cause the recipient
to keep messages.
Or better the actual key used could be derived to fix that. eg
k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i values. In
that way you can keep keys for a gap with no security implication other than
the missing/delayed message security. Other messages that come afterwards
would be unaffected.
Yeah! That's a great way to do it.
In case of out-of-order delivery, you could eventually delete unused
sk_i values once they get too old.
You could also encrypt the sequence numbers with some static key so as
not to leak info on the # of messages exchanged.
Trevor
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [liberationtech] Ibis: An Overlay Mix Network for Microblogging by Ian Goldberg
- Forwarded message from Steve Weis stevew...@gmail.com - Date: Wed, 18 Sep 2013 08:50:09 -0700 From: Steve Weis stevew...@gmail.com To: liberationt...@lists.stanford.edu liberationt...@lists.stanford.edu Subject: [liberationtech] Ibis: An Overlay Mix Network for Microblogging by Ian Goldberg Reply-To: liberationtech liberationt...@lists.stanford.edu Ian Goldberg is speaking about Ibis: An Overlay Mix Network for Microblogging today at the Stanford security seminar. The talk is 4:30pm in the Gates building, room 463A. http://crypto.stanford.edu/seclab/sem-12-13/goldberg.html Abstract: Microblogging services such as Twitter are extremely popular. While they are commonly used by people who wish to reveal their names and friends to the world, some users, such as activists on the ground, may wish to be able to post without automatically revealing their identities or locations. An obvious approach is to use a low-latency anonymity system, such as Tor. However, low-latency systems fall prey to end-to-end timing attacks easily accomplished by an ISP or a government monitoring clients while also watching for posts to appear in real time on the microblogging site. We present Ibis, a high-latency mix network designed specifically for microblogging. Ibis is an overlay network: the mix nodes can be microblogging clients that come online only sporadicly, and the intermediate encrypted messages are themselves posted as microblogged entries. We accomplish this through a novel cryptographic mix message format that uses only 47 bytes of overhead, while maintaining three-hop, 128-bit security against offline attack. This is joint work with Paul Hendry. Bio: Ian Goldberg is an Associate Professor of Computer Science and a University Research Chair at the University of Waterloo, where he is a founding member of the Cryptography, Security, and Privacy (CrySP) research group. He holds a Ph.D. from the University of California, Berkeley, where he discovered serious weaknesses in a number of widely deployed security systems, including those used by cellular phones and wireless networks. He also studied systems for protecting the personal privacy of Internet users, which led to his role as Chief Scientist at Zero-Knowledge Systems (now Radialpoint). His research currently focuses on developing usable and useful technologies to help Internet users maintain their security and privacy. He is a Senior Member of the ACM and a winner of the Early Researcher Award, the Outstanding Young Computer Science Researcher Award, and the Electronic Frontier Foundation's Pioneer Award. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 17:27, Trevor Perrin wrote: Hmm, I would've thought clocks are *less* reliable than storage on most devices. That may be true, but this isn't a choice between relying on the clock or relying on storage. It's a choice between relying on both, or relying only on the clock. Certainly this has worse forward-secrecy than updating keys per-message, as keys for old ciphertext are kept around for some period. Yes, updating keys per-message would be preferable if we could assume an ongoing two-way exchange of messages. For OTR's instant messaging use case that's a reasonable assumption. For Briar's use case it's not. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSOeFqAAoJEBEET9GfxSfMJFEH/jnyd3SAYKhNAhQVFOYlvyy1 zckK4VQClQPEOwRcidSud9zSxblRQXQGJSO+pB23niHgpbomzDx7fc5jKlShF/yt sZ8qJ2gj13xZey0rp+DWK3DCcKq0erEbDd58bngJsHtFoVyjYpsZKfMi8Mqhl3iN 2QvEXkwkUzVTSX8bks30WRgGAObimvEHAOU7eOY32xZgy/l2VwUDOws5fd0lc5+p +HcEQLyckkSZnaF6C/vXa6jbNYigRLzR+UslIVnshg1BWrgShxe+f+2TtWhLDNqD 1y0vRdhW+JzQYcwmmTQyHpKGl5qCQ6vmkYxdmsm6JvGLFR06q+FG8thaWE/VCU4= =hmqv -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Wed, Sep 18, 2013 at 10:22 AM, Michael Rogers mich...@briarproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 17:27, Trevor Perrin wrote: Hmm, I would've thought clocks are *less* reliable than storage on most devices. That may be true, but this isn't a choice between relying on the clock or relying on storage. It's a choice between relying on both, or relying only on the clock. A quick glance at Briar makes it looks like it already uses local storage: Certainly this has worse forward-secrecy than updating keys per-message, as keys for old ciphertext are kept around for some period. Yes, updating keys per-message would be preferable if we could assume an ongoing two-way exchange of messages. For OTR's instant messaging use case that's a reasonable assumption. For Briar's use case it's not. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSOeFqAAoJEBEET9GfxSfMJFEH/jnyd3SAYKhNAhQVFOYlvyy1 zckK4VQClQPEOwRcidSud9zSxblRQXQGJSO+pB23niHgpbomzDx7fc5jKlShF/yt sZ8qJ2gj13xZey0rp+DWK3DCcKq0erEbDd58bngJsHtFoVyjYpsZKfMi8Mqhl3iN 2QvEXkwkUzVTSX8bks30WRgGAObimvEHAOU7eOY32xZgy/l2VwUDOws5fd0lc5+p +HcEQLyckkSZnaF6C/vXa6jbNYigRLzR+UslIVnshg1BWrgShxe+f+2TtWhLDNqD 1y0vRdhW+JzQYcwmmTQyHpKGl5qCQ6vmkYxdmsm6JvGLFR06q+FG8thaWE/VCU4= =hmqv -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/09/13 18:56, Trevor Perrin wrote: Sorry, mis-send... I meant: A quick glance at Briar makes it looks like it already uses local storage: Neither endpoint can send more than 2^32 connections to the other during a given rotation period. Each endpoint persistently stores the highest connection number it has sent to the other during the current rotation period, together with a sliding window of the highest connection numbers it has received from the other during each of the current retention periods. The persistent storage of these values is vital, so BTP cannot be used by endpoint devices that lack writable persistent storage (unless the devices never reboot). Yup, that's the fragile current design I mentioned. :-) The new design still depends on persistent storage, but it avoids the risk of key reuse if the persistent storage is unreliable. But I don't know enough about the protocol to be giving advice, so I'll stop... No, it's always good to get people's views on the design - thanks! The per-message symmetric-key update that Adam and I sketched doesn't require a 2-way exchange of messages. Even a one-way stream of message would receive good forward secrecy. Ah, sorry, I was thinking of OTR's per-message update rather than yours! The method you and Adam suggested would be suitable for our use case, and much more elegant than what we're using now, except that it requires a plaintext sequence number. We've tried to avoid plaintext fields in BTP to make it harder to design filter rules to detect or block the protocol. So we rely on the pseudo-random tag to tell the recipient (a) which sender the message comes from, (b) which rotation period the sender was in when the message was sent, and (c) the sequence number. The recipient precalculates a limited number of tags in a sliding window, which allows a limited amount of message loss or reordering - but if too many messages are lost, the sender's sequence number will move beyond the recipient's window, and they'll have to wait until the next rotation period to resynchronise (the sequence number is reset at the start of each rotation period). This is all rather clunky, and I'd love to find a better way to do it, but so far I haven't been able to work out how. Suggestions welcome! :-) Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSOg7cAAoJEBEET9GfxSfMZuAH/jQhZXDNMs0LszDoAE72SNaO et+uwRk1m8wnChhU1WCuQ8Cmc//tJxcdly9BfzqUafs7q4dj1pl7YEoRI152bs9J mFcF/Z7oF5/ueZ6m/deuR8e9Lf2oGgIvP8K87/E/DRQFGKR/As7rGs7Or9lchpey m7OFztfP0BB+uRkHrC7vfdgWqPOQeDnuHa1pItA+zXLqRloze4pPSpuHhvc2EGz2 JqckFQ4b0GRKFdHReYv/S46TO/g96qLjz+wNu9QUw9oAUiSHcuhQcJ7FX0dEXm77 mk78jRRBpaEjLCF03Zt+wcFSHJ30/GSqtdKyYnuJ2OfjMpkF6Ym3odWfzKtoYw4= =I+Be -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] RSA equivalent key length/strength
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-14 08:53, Peter Fairbrother wrote: I get that 1024 bits is about on the edge, about equivalent to 80 bits or a little less, and may be crackable either now or sometime soon. Moti Young and others wrote a book back in the 90's (or perhaps) 80's, that detailed the strength of various RSA key lengths over time. I am too lazy to look up the reference or locate the book on my bookshelf. Moti: help me out here? :-) According to published reports that I saw, NSA/DoD pays $250M (per year?) to backdoor cryptographic implementations. I have knowledge of only one such effort. That effort involved DoD/NSA paying $10M to a leading cryptographic library provider to both implement and set as the default the obviously backdoored Dual_EC_DRBG as the default RNG. This was $10M wasted. While this vendor may have had a dominating position in the market place before certain patents expired, by the time DoD/NSA paid the $10M, few customers used that vendor's cryptographic libraries. There is no reason to believe that the $250M per year that I have seen quoted as used to backdoor commercial cryptographic software is spent to any meaningful effect. - ---Lucky -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) iQIcBAEBAgAGBQJSOhm/AAoJEARVjUj9NCi09/wP/jlBE78qlZdPctkhXXC8CblP oOYD7OhrxP5eaI6UVHN8gJBZidrYZmGp6a9bGLtqzLZmx1L2DEhrKojyUy8lic71 LyZs2ulIY6GU87xr4k7w9ce25+WvK7LviGCjq1WfRxJtmoTSUpNcRI/CNHHnueWE lGKFip0RVS0YPnVvgQ5pvDmJUW+2vb/4xi6cx592TaQKmgRQoY7gsFCDwuJsy3K/ OUhaEoM6OIMkboCU7CAtC7w1sqP+6GnDg0ZEUvZ8ILFkPYKyEGgJ+RNiUNOsMlIt dvCEgmT1jL6tgZWHfByAfsYN54uWp5QMuL277ZKlvcjF2KNN7cPcsA4Y76RxTH7L 7gnzB2aQUn13O4dsmsB/54Mbg2Y+LvYCa40Q5RIi45evjANxx9Bx3sFMr3HbXArO ijT081OUy6/tZYDXruWHlh3j4RAYp/fHecm4/25pQS9NrTAQnaCCnGMHRiP6/PEw GtMWsW3TkDts3h41HJ5wU6Rppr1hX3pRn1ZgeNJbtRezcC4BL0pTX0PEZ76bhXze 231wdd15/Fnb8e30HbWLUiRSLKAbY4KWSdfdZBRzty7ZiiCTI3O8vQLg2Ld0iR1a VYZX+hySDG8ZJvj8qoN3d7AR9q7WJk554aOSGb1ooBafm4YjbzAVglu/Afi48DHu xZFLLjzDm5BhP5eGvsli =TsSq -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
