Re: [cryptography] DeCryptocat
Il 7/5/13 5:29 AM, Nadim Kobeissi ha scritto: Rest assured we're working on it as an extra precaution (as mentioned in the blog post). Also, our services use SSL forward secrecy. NK What's about embeding Tor binary (build as library) within the CryptoCat plugin and abbandon internet/SSL issues by going trough Tor Hidden Services? It does not seems quick easy to be implement from software engineering point of view, but definitely doable: Binary in Chrome Plugin trough NPAPI: http://developer.chrome.com/extensions/npapi.html Binary in Mozilla Plugin: https://wiki.mozilla.org/Mozilla_2/XPCOM_and_Binary_Embedding -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
On 2013-07-05, at 7:09 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-07-05, at 6:15 AM, Matthew Green matthewdgr...@gmail.com wrote: On Jul 5, 2013, at 12:01 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-07-05, at 3:15 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: Hello everyone, I urge you to read our response at the Cryptocat Development Blog, which strongly clarifies the situation: https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ Has there been a rotation of the certificate and keying material for all services that serve CryptoCat chat traffic? Rest assured we're working on it as an extra precaution (as mentioned in the blog post). Also, our services use SSL forward secrecy. I'm not really assured and I think I should clarify something that is perhaps slipping past like a ship in the night. I went to crypto.cat in Chrome only to find myself not connected in a forward secure manner. According to ssllabs[0], CryptoCat supports some odd SSL/TLS configurations: Protocols TLS 1.2 Yes TLS 1.1 No TLS 1.0 No SSL 3.0 Yes SSL 2.0 No Further more - it appears that CryptoCat supports SSL_RSA_WITH_RC4_128_SHA, as well as other non-forward secure modes Is there really any reason to support such a mode with 3DES in 2013 for this kind of service? TLS1.1 and 1.2 are both supported, actually, in addition to SSL 3.0. Why does ssllabs think otherwise, I wonder? It looks now like ssllabs thinks SSL 3, TLS 1.1 and TLS 1.2 are supported, while TLS 1.0 isn't. Did you reconfigure the protocols that are offered? Why offer SSL 3.0 but not TLS 1.0? TLS 1.0 is now offered. It was just a configuration mishap. Luckily, TLS 1.1 and 1.2 were supported. AES-GCM is already prioritized over RC4, but unfortunately most browsers don't support AES-GCM yet, which is why RC4 remains as the secondary choice. In the case that AES-GCM is not supported, we use RC4 instead of AES-CBC in order to mitigate for BEAST. If you have alternate suggestions to this, please let me know. None of the browsers supported by the plugin, certainly not those which support forward secrecy, should be vulnerable to the BEAST attack. I believe that almost everyone is using 1/n-1 record splitting or something that is functionally similar. Interesting, where can I find a reference for this? We've just removed some of the more obsolete suites that use 3DES. They were unlikely to be used anyway due to their very low priority. Are you sure? I'm still seeing SSL3 with RSA and RC4 in Chrome. If the SSL key is taken tomorrow, my session from today is compromised… Yes, I specifically said 3DES. The majority of Chrome and Firefox users still need a fallback. Not all browsers support all cipher suites. This is unfortunately a browser vendor issue that needs to be fixed. NK Also, I'm not sure if this is obvious but it appears that many users may be using SSL 3.0: Chrome 27 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Firefox 21 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Internet Explorer 10 SSL 3 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 Safari iOS 6.0.1TLS 1.2 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Safari 5.1.9 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 RC4 is not my favorite choice when all the other crypto has failed. Do you know how many users are impacted? How many users are actually choosing the forward secret protocols? Also, I'll ask again: Do you know how many users are impacted? How many users are actually choosing the forward secret protocols? All the best, Jacob ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
Nadim Kobeissi: Sorry, I wasn't meaning to avoid any questions. I simply forgot to answer them. It's best to assume good will from others on a discussion list. Glad to hear it. I do not know how many users choose forward secret protocols, nor do I imagine there is a standardized or easy way to derive that knowledge. This is why private keys were reset, even though we use forward secrecy. It appears that you're using nginx - it seems reasonable to discover this information: http://mailman.nginx.org/pipermail/nginx/2010-July/021228.html http://wiki.nginx.org/NginxHttpSslModule#Built-in_variables This directs us here: Module ngx_http_ssl_module supports the following built-in variables: $ssl_cipher returns the cipher suite being used for the currently established SSL/TLS connection $ssl_protocol returns the protocol of the currently established SSL/TLS connection — depending on the configuration and client available options it's one of SSLv2, SSLv3 or TLSv1 = If CryptoCat is not rotating keys frequently, as some companies do for these modes, I guess that one rotation is not enough. CryptoCat is currently offering non-forward secret modes for some people - so the original concern really holds, sadly. SSL and TLS security is really painful sometimes. :( I could imagine that people who select such dangerous modes could be redirected to a page that refuses chat service until they upgrade their browser? Or perhaps something else that mitigates likely harm? That at least prevents users from potentially using TLS in a dangerous manner as they have been for quite some time. However - if no one is using them, can't you just disable them? And if many people are using them, will you ensure that they will fail closed by disabling them? Or perhaps by rotating keys on a daily basis? This seems like an important and relevant set of points: https://www.imperialviolet.org/2013/06/27/botchingpfs.html All the best, Jake ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
Il 7/5/13 8:34 PM, Jacob Appelbaum ha scritto: Module ngx_http_ssl_module supports the following built-in variables: $ssl_cipher returns the cipher suite being used for the currently established SSL/TLS connection $ssl_protocol returns the protocol of the currently established SSL/TLS connection — depending on the configuration and client available options it's one of SSLv2, SSLv3 or TLSv1 As a mid-term move for CryptoCat server side it would be nice to make it's own minimal and secure XMPP Server, to be installed without any configuration burden, be secure by design and not necessarily by configuration Doing so, would facilitate the integration with Tor to easily let anyone startup it's own CryptoCat server (also on windows/macappstore), running over TorHS, making the architecture more distributed and SSL-free. A nice set of technology to do it could be: - Wokkel, XMPP Server based on Twisted http://wokkel.ik.nu/ - TxTorCon, to manage Tor process https://github.com/meejah/txtorcon - Pyinstaller to make windows/macosx package http://www.pyinstaller.org/ - Cyclone, to make web interface to manage it easily https://github.com/fiorix/cyclone -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] DeCryptocat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Sorry, long time lurker, first time poster. Hate my first post to be a negative one. http://tobtu.com/decryptocat.php Brief DecryptoCat v0.1 cracks the ECC public keys generated by Cryptocat https://crypto.cat/ versions 1.1.147 through 2.0.41. Cryptocat version 2.0.42 was released Feb 19, 2013 which increased the key space from 2^54.15 to 2^106.3. Decryptocat takes advantage of a meet-in-the-middle attack called baby-step giant-step you can effectively square root the key space. So 2^54.15 turns into 2^27.08 and 2^106.3 to 2^53.15. For Cryptocat versions before 2.0.42, doing a split of 2*10^9 and 10^7 it takes about a day to calculate data needed to crack any key in few minutes. tl;dr -If you used Cryptocat from October 17th, 2011 to June 15th, 2013 assume your messages were compromised. Also if you or the person you are talking to has a version from that time span, then assume your messages are being compromised. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJR1dxlAAoJED4YSmxlVKcxWKQH/j14Bp5R4kH8fu738n7TX/cz wPm5xhtFmpYJ78pLLkQ8JNUrckqrZVmj+SCgZeKDl9ESzy0qyXcGuJyKfVwZO4VJ 7z07awreT01NNafOCH2NtJSt6x/5WTYYVJDXrtdBMaVyeJkDV8T9Yca0YYfTVPsF q8xzzWm6rRg4WsDS5Zi07rMu5PN8Ijx7+sbjCmM4Bh2/VIdFjr9Llb2SyXQyi9AJ xFT+3iLHfEep0SDAg1MZSqb2Qryw95FOW2+FRdFwqD4lFM8otNbQAklCp7BJOENW eFvRG3dYQzw8T7FAp5vtkLaglGTbfptuijXuxsV1h/wb+a6O9HX1mOGr0AGid5k= =POme -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
On 2013-07-05 6:34 AM, Silas Cutler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Sorry, long time lurker, first time poster. Hate my first post to be a negative one. http://tobtu.com/decryptocat.php Brief DecryptoCat v0.1 cracks the ECC public keys generated by Cryptocat https://crypto.cat/ versions 1.1.147 through 2.0.41. Cryptocat version 2.0.42 was released Feb 19, 2013 which increased the key space from 2^54.15 to 2^106.3. Decryptocat takes advantage of a meet-in-the-middle attack called baby-step giant-step you can effectively square root the key space. So 2^54.15 turns into 2^27.08 and 2^106.3 to 2^53.15. For Cryptocat versions before 2.0.42, doing a split of 2*10^9 and 10^7 it takes about a day to calculate data needed to crack any key in few minutes. tl;dr -If you used Cryptocat from October 17th, 2011 to June 15th, 2013 assume your messages were compromised. Also if you or the person you are talking to has a version from that time span, then assume your messages are being compromised. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ randombit.net/mailman/listinfo/cryptography 106 bits is still far too small. Seems to me that they only increased it as needed to defeat DecryptoCat, not as needed to defeat an NSA farm running dedicated special purpose hardware. Why not use an elliptic curve whose points are, in compressed form, about 256 bits, which is the size I chose for Crypto Kong, many, many years ago, when computers were far less powerful. I chose that after looking at various cracking efforts as the minimum size that I was pretty sure that the NSA could not beat, then or in the reasonably near future. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/13 22:07, James A. Donald wrote: 106 bits is still far too small. Seems to me that they only increased it as needed to defeat DecryptoCat, not as needed to defeat an NSA farm running dedicated special purpose hardware. Why not use an elliptic curve whose points are, in compressed form, about 256 bits, which is the size I chose for Crypto Kong, many, many years ago, when computers were far less powerful. I chose that after looking at various cracking efforts as the minimum size that I was pretty sure that the NSA could not beat, then or in the reasonably near future. The choice of curve wasn't the problem - they were using Curve25519 but messing up the random number generation. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR1eafAAoJEBEET9GfxSfMfWwH/R/Rq/I02dMcmheZuIStT8lG dwTnBM7ZLqXywpvVjS4SDKDTcSC8EfrFx/QW2906VTqMDn5wNePe9BZegsZGIP5Q C+R/Kz8ahaUdJMbwHI0FrwdvrkCot1K8L8qWacUf/osZ/uP0Xrx7CEqk0Xi7OFLu jFTyj5hjSUWg7MctNfmCn6ElMaMO81Fc91aZGKxLRw4z7XBOSBGhcEuXoTpuQAAI 2Y7CkhXhuvdW1DpneD0EXRiyM0DK0/OKOQwoTvfHQXzHubss50Ke0OlqEiAhzRzw BPCTlVMCKF0dmgL7/EZ7Z60/JxSCRJ847uN1P76POEw+Ez9akzvaC9S/lveLyEs= =BggH -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
On 2013-07-05 7:18 AM, Michael Rogers wrote: The choice of curve wasn't the problem - they were using Curve25519 but messing up the random number generation. Ah, I see. They have company. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
Hello everyone, I urge you to read our response at the Cryptocat Development Blog, which strongly clarifies the situation: https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ Thank you, NK On 2013-07-04, at 11:38 PM, James A. Donald jam...@echeque.com wrote: On 2013-07-05 7:18 AM, Michael Rogers wrote: The choice of curve wasn't the problem - they were using Curve25519 but messing up the random number generation. Ah, I see. They have company. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
On 2013-07-05, at 3:15 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: Hello everyone, I urge you to read our response at the Cryptocat Development Blog, which strongly clarifies the situation: https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ Has there been a rotation of the certificate and keying material for all services that serve CryptoCat chat traffic? Rest assured we're working on it as an extra precaution (as mentioned in the blog post). Also, our services use SSL forward secrecy. NK All the best, Jacob ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
Nadim Kobeissi: On 2013-07-05, at 3:15 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: Hello everyone, I urge you to read our response at the Cryptocat Development Blog, which strongly clarifies the situation: https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ Has there been a rotation of the certificate and keying material for all services that serve CryptoCat chat traffic? Rest assured we're working on it as an extra precaution (as mentioned in the blog post). Also, our services use SSL forward secrecy. I'm not really assured and I think I should clarify something that is perhaps slipping past like a ship in the night. I went to crypto.cat in Chrome only to find myself not connected in a forward secure manner. According to ssllabs[0], CryptoCat supports some odd SSL/TLS configurations: Protocols TLS 1.2 Yes TLS 1.1 No TLS 1.0 No SSL 3.0 Yes SSL 2.0 No Further more - it appears that CryptoCat supports SSL_RSA_WITH_RC4_128_SHA, as well as other non-forward secure modes Is there really any reason to support such a mode with 3DES in 2013 for this kind of service? Also, I'm not sure if this is obvious but it appears that many users may be using SSL 3.0: Chrome 27SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Firefox 21 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Internet Explorer 10 SSL 3 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 Safari iOS 6.0.1TLS 1.2 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Safari 5.1.9 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 RC4 is not my favorite choice when all the other crypto has failed. Do you know how many users are impacted? How many users are actually choosing the forward secret protocols? All the best, Jacob [0] https://www.ssllabs.com/ssltest/analyze.html?d=crypto.cat ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
On Jul 5, 2013, at 12:01 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-07-05, at 3:15 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: Hello everyone, I urge you to read our response at the Cryptocat Development Blog, which strongly clarifies the situation: https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ Has there been a rotation of the certificate and keying material for all services that serve CryptoCat chat traffic? Rest assured we're working on it as an extra precaution (as mentioned in the blog post). Also, our services use SSL forward secrecy. I'm not really assured and I think I should clarify something that is perhaps slipping past like a ship in the night. I went to crypto.cat in Chrome only to find myself not connected in a forward secure manner. According to ssllabs[0], CryptoCat supports some odd SSL/TLS configurations: Protocols TLS 1.2 Yes TLS 1.1 No TLS 1.0 No SSL 3.0Yes SSL 2.0 No Further more - it appears that CryptoCat supports SSL_RSA_WITH_RC4_128_SHA, as well as other non-forward secure modes Is there really any reason to support such a mode with 3DES in 2013 for this kind of service? Also, I'm not sure if this is obvious but it appears that many users may be using SSL 3.0: Chrome 27 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Firefox 21 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Internet Explorer 10 SSL 3 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 Safari iOS 6.0.1TLS 1.2 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Safari 5.1.9 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 RC4 is not my favorite choice when all the other crypto has failed. Do you know how many users are impacted? How many users are actually choosing the forward secret protocols? All the best, Jacob [0] https://www.ssllabs.com/ssltest/analyze.html?d=crypto.cat ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
On 2013-07-05, at 6:15 AM, Matthew Green matthewdgr...@gmail.com wrote: On Jul 5, 2013, at 12:01 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-07-05, at 3:15 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: Hello everyone, I urge you to read our response at the Cryptocat Development Blog, which strongly clarifies the situation: https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptocat-details/ Has there been a rotation of the certificate and keying material for all services that serve CryptoCat chat traffic? Rest assured we're working on it as an extra precaution (as mentioned in the blog post). Also, our services use SSL forward secrecy. I'm not really assured and I think I should clarify something that is perhaps slipping past like a ship in the night. I went to crypto.cat in Chrome only to find myself not connected in a forward secure manner. According to ssllabs[0], CryptoCat supports some odd SSL/TLS configurations: Protocols TLS 1.2 Yes TLS 1.1 No TLS 1.0 No SSL 3.0Yes SSL 2.0 No Further more - it appears that CryptoCat supports SSL_RSA_WITH_RC4_128_SHA, as well as other non-forward secure modes Is there really any reason to support such a mode with 3DES in 2013 for this kind of service? TLS1.1 and 1.2 are both supported, actually, in addition to SSL 3.0. AES-GCM is already prioritized over RC4, but unfortunately most browsers don't support AES-GCM yet, which is why RC4 remains as the secondary choice. In the case that AES-GCM is not supported, we use RC4 instead of AES-CBC in order to mitigate for BEAST. If you have alternate suggestions to this, please let me know. We've just removed some of the more obsolete suites that use 3DES. They were unlikely to be used anyway due to their very low priority. Also, I'm not sure if this is obvious but it appears that many users may be using SSL 3.0: Chrome 27 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Firefox 21 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Internet Explorer 10 SSL 3 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 Safari iOS 6.0.1TLS 1.2 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 Safari 5.1.9 SSL 3 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128 RC4 is not my favorite choice when all the other crypto has failed. Do you know how many users are impacted? How many users are actually choosing the forward secret protocols? All the best, Jacob [0] https://www.ssllabs.com/ssltest/analyze.html?d=crypto.cat ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
On 2013-07-05, at 6:59 AM, Cool Hand Luke coolhandl...@coolhandluke.org wrote: Signed PGP part On 07/05, Nadim Kobeissi wrote: On 2013-07-05, at 3:15 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Has there been a rotation of the certificate and keying material for all services that serve CryptoCat chat traffic? Rest assured we're working on it as an extra precaution (as mentioned in the blog post). Also, our services use SSL forward secrecy. Just an update that we've finished rotating the SSL keys: https://twitter.com/cryptocatapp/status/353018036510404608 any chance that you'll be using an hsm (preferably) or a smart card (at the least) for generation and storage? An EntropyKey is used, but no other special hardware is employed. Aside from this, typical precautions are taken. NK - -chl - -- cool hand luke ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DeCryptocat
Nadim Kobeissi na...@nadim.cc writes: AES-GCM is already prioritized over RC4, but unfortunately most browsers don't support AES-GCM yet, which is why RC4 remains as the secondary choice. In the case that AES-GCM is not supported, we use RC4 instead of AES-CBC in order to mitigate for BEAST. If you have alternate suggestions to this, please let me know. This: http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-03 pretty much cancels out about ten years worth of attacks on SSL/TLS' integrity-checking. The only downside is that browser support at the moment isn't there yet, although a number of TLS toolkits already handle it. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
