[cryptography] rfc 4345 (arcfour) weakness
Hi list, Anyone know some paper or article citing vulnerabilities on the rfc 4345 version of RC4? I know of the article "A New Weakness in the RC4 Keystream Generator and an Approach to Improve the Security of the Cipher" by Paul and Preneel, that discovered a bias after the first 1536 first bytes of the stream, but if someone can provide a reference to other "weak distinguishers", or an attack on the RC4A algorithm proposed on that paper, I would greatly appreciate it. Best regards, Alfred ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
>> Given those shortcomings I think is not wise to recommend it unless your >> enemy doesn't have the resources of a country. That being said, it's the >> best tool at the moment, lights year ahead of other popular software >> like >> Cryptocat, whose end-point security should be considered not only >> sub-par >> but dangerous. (who in their right mind will consider browser crypto?) > > It's definitely a new field that needs a lot of work. I invite you to > read: > > The paper describing the improvements we're making for browser crypto: > http://arxiv.org/abs/1306.5156 > > My blog post on the improving state of browser crypto implementation: > http://log.nadim.cc/?p=33 > > NK Hi! nice to see that improvements are coming. I was reacting to some papers reporting about Cryptocat being used to defeat evil governments, etc. IMHO if the FBI can beat TOR, surely they can beat Cryptocat as well. But I don't blame you. I don't think any real-time chat can ever be made "safe" and by safe I mean anonymous, because of its low-latency nature. You can have privacy by using OTR and that's good in many situations, but won't protect you from somebody with enough money to hire techs and put some taps. And then your users get killed or thrown into prison and then can't report any bug. Crypto dev is like that :) Best regards, Alfred ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
>> The more interesting point is high vs low latency. I really like the >> idea of having a high-latency option in Tor. It would still need to >> have a lot of users to actually be useful, though. But it seems there >> are various protocols that would be ore high-latency-friendly than >> HTTP - SMTP, of course, and XMPP spring to mind. >> > I think if Tor had an arbitrary queue with store and forward as a high > latency module of sorts, we'd really be onto something. Then there would > be tons of traffic on the Tor relays for all kinds of reasons - high and > low latency - only to all be wrapped in TLS and then in the Tor protocol. I was looking for something like this. It would be incompatible with anything that uses TCP, but better that way. I have always found weird that there is no a UDP-like transport in tor. IMHO only the TCP initial hand-shake gives your attacker enough info to leak your position easily (just a tought, never did any sort of serious tests on this) but UDP would be immune to it, even more if it's implemented using high-latency queues. Probably most existing UDP services should work unmodified. Best regards, Alfred ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
> So then - what do you suggest to someone who wants to leak a document to > a press agency that has a GlobaLeaks interface? What do you suggest to > someone who wants to use a web email account that properly supports > HTTPS? What do you suggest to someone who wants location privacy from > their chat service? What do you suggest to someone who wants to buy > themselves time and not link their entire past to some event they think > might matter, thus attracting retroactive searches in the future? > I would suggest him to wait to authorities until better software arrives :) > It is also why we have multiple implementations as well. There is a Java > version of Tor that is nearly ready for release and it will solve a > number of the C implementation concerns and exchange them for Java > related concerns. There are a few other Tor implementations in the wild, > each serving an interesting subset of users. Diversity is important. > > Still - having a bug in Tor as a client is a lot less likely than in > whatever application you'll use with Tor - web browsers come to mind > here but other chat clients, like Pidgin or Thunderbird, they also come > to mind. Didn't know about the java version. I agree, browsers and other clients are the prime attack surface. > >> 2) Network analysis: Tor is vulnerable to network analysis. FBI has made >> arrests to people that were specifically using TOR to hide their >> activities, and their use of network analysis to unmask them is documented >> (Jeremy Hammond, Stratfor case). >> > > What is public about Jeremy Hammond is worth reading. It suggests the > FBI has the lamest of all Network analysis techniques - a very simple > traffic confirmation attack. They appear to disconnect a person's > internet and then they ask their snitch if the person signs off from > their chat service. Yet it worked and the guy is in jail. It shows that you only need a single bit leak to get into trouble. And they were the police, the mafia may require less than one bit. > There are solutions - one of them is to run a second > machine reachable by (Stealth) Tor Hidden Service with your chat client > in gnu screen - login to that system, attach to the screen and chat away > - sometimes, you'll get disconnected but no one will see it. > > There are social issues that are more concerning though - if you > normally are quite chatty, only to stop chatting, they might suggest > that not speaking is confirmation, etc. So this issue issue, like any > solution, is partially a technical issue and partially a social issue. Maybe software can help in this regard, to protect you from yourself. >> Some months ago I tried to fix some shortcomings of Tor by wrapping it in >> a higher layer and using it for simple network-analysis resistant chat. >> The result was a protocol so slow that's almost unusable, if someone want >> to take a look at it it's here: https://github.com/alfred-gw/torirc >> > > This is awesome! > > I've git clone'd it. I'm going audit it and send you > feedback/patches/etc. Thanks for hacking on Tor related software! Thanks you. I'm thinking of making it work with the new tor python bindings. It's just an experiment, nothing serious. > my first thought is that you might consider making it use OTR for p2p > chats on the server - there is no good multi-party OTR implementation > yet, so at that point, I might just look at the mpOTR paper from > Goldberg et al. A number of us worked on a spec that is so far from done > that it isn't worth linking at the moment. Ahh that's an awesome idea. Will look into it. > > I feel OK about not having another layer of crypto on top of a Tor HS > but in your protocol's case, I'd encourage you to use Stealth Hidden > Services - so at least then the only people connecting are the ones who > are cryptographically authenticated in some manner. I used regular hidden services. Didn't know there were a stealthier ones. Will look into it. BTW, didn't like the fixed 1024 RSA key for hidden services. Hope it changes in the future. > > You will probably very much like Pond: > > https://github.com/agl/pond/ > > I use it daily. It is perhaps my favorite application, ever, for use > with Tor. Very good project. Fortunately I have no use for it yet, might steal some ideas from it. > >> I would like to see a tor configuration flag that sacrifices speed for >> anonymity. > > You're the first person, perhaps ever, to make that feature request > without it being in a mocking tone. At least, I think you're not mocking! :) > > All the best, > Jacob > Of course I'm not mocking you :) as some people already said, low-latency is comfortable but if you life is in danger, I'm sure you can wait a little longer for your messages to arrive :) Best regards, Alfred ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
Oops, miscalculation. That should be a 6.5 Ghz clock for 100 Gbps. ((100 Gbps/8)/2) . Anyway I don't think anybody has hardware that fast except maybe for IBM with the Power8. > The fastest hardware implementation of RC4 that I know is 2 bytes/clock. I > personally programmed a 1 byte/clock RC4 in a FPGA, it's quite simple. > > At 2 bytes/clock you still need a clock of 10 gigahertz to encrypt 100 > Gbps. That's unfeasible, the way it's done is using paralelism, then you > can use any algorithm you want as long as you have silicon available. > Consider there are 400 Gbps systems coming online. > > Using a PC for that kind of workload is a waste of money and power. FPGAs > are not that expensive nowadays. > > > > >> Just as a data point, on x86 processors with AESNI you can encrypt AES >> in, >> say, XTS mode with about 0.75 cycles / byte on each core. >> >> On an Intel Xeon E5-2690 'openssl speed -multi 4 -evp aes-128-xts' tops >> out >> at 13.5 GB/s for 8k blocks, which is 108 Gbps. That's only using half >> the >> physical cores and no hyperthreading. >> >> However, that's unlikely a realistic benchmark for whatever context the >> original question was referring to. >> >> >> On Sat, Jun 22, 2013 at 5:25 PM, Peter Maxwell >> wrote: >> >>> >>> >>> On 22 June 2013 23:31, James A. Donald wrote: >>> On 2013-06-23 6:47 AM, Peter Maxwell wrote: I think Bernstein's Salsa20 is faster and significantly more secure than RC4, whether you'll be able to design hardware to run at line-speed is somewhat more questionable though (would be interested to know if it's possible right enough). I would be surprised if it is faster. >>> >>> Given the 100Gbps spec, I can only presume it's hardware that's being >>> talked about, which is well outwith my knowledge. We also don't know >>> whether there is to be only one keystream allowed or not. >>> >>> However, just to give an idea of performance: from a cursory search on >>> Google, once can seemingly find Salsa20/12 being implemented recently >>> on >>> GPU with performance around 43Gbps without memory transfer (2.7Gbps >>> with) - >>> http://link.springer.com/chapter/10.1007%2F978-3-642-38553-7_11 ) - >>> unfortunately I don't have access to the paper. >>> >>> On a decent 64-bit processor, the full Salsa20/20 is coming in around >>> 3-4cpb - http://bench.cr.yp.to/results-stream.html - and while cpb >>> isn't >>> a great measurement, it at least gives a feel for things. >>> >>> >>> Going on a very naive approach, I would imagine the standard RC4 will >>> suffer due to being byte-orientated and not particularly open to >>> parallelism. Salsa20 operates on 32-bit words and from a cursory >>> inspection of the spec seems to offer at least some options to do >>> operations in parallel. >>> >>> If I were putting money on it, I suspect one could optimise at least >>> Salsa20/12 to be faster than RC4 on modern platforms; whether this has >>> been >>> done is another story. Fairly sure Salsa20/8 was faster than RC4 >>> out-of-the-box. >>> >>> As with anything though, I stand to be corrected. >>> >>> >>> >>> >>> ___ >>> 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 > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
I believe Anonymity is a problem orders of magnitude bigger than privacy. Tor seems like the only serious project aiming at solving it but I think you should be wise by choosing your enemies and Tor in its current state is useless against government-type surveillance for the following reasongs (IMHO): 1) Endpoint security: Tor is a big C project, needs much more code review until it's considered safe. 2) Network analysis: Tor is vulnerable to network analysis. FBI has made arrests to people that were specifically using TOR to hide their activities, and their use of network analysis to unmask them is documented (Jeremy Hammond, Stratfor case). Given those shortcomings I think is not wise to recommend it unless your enemy doesn't have the resources of a country. That being said, it's the best tool at the moment, lights year ahead of other popular software like Cryptocat, whose end-point security should be considered not only sub-par but dangerous. (who in their right mind will consider browser crypto?) Some months ago I tried to fix some shortcomings of Tor by wrapping it in a higher layer and using it for simple network-analysis resistant chat. The result was a protocol so slow that's almost unusable, if someone want to take a look at it it's here: https://github.com/alfred-gw/torirc I would like to see a tor configuration flag that sacrifices speed for anonymity. > Michael Rogers: >>> So who's out there developing any useful protocols for >>> anonymization today? *Anybody*? Could we try to start a new project >>> (if needed) to create one? >> >> I'd love to see a revitalisation of remailer research, focussing on >> unlinkability (which we know many people would benefit from) rather >> than sender anonymity (which fewer people need, and which is prone to >> abuse that discourages people from running mixes). >> > > I'd also like to see revitalisation of remailer research. Though > anonymity as Tor is designed is specifically about unlinkability. To > reduce it to sender anonymity is pretty ... ridiculous. What one does > with an anonymous communications channel is up to them - many people do > actually want that feature for chatting, web browsing, news, email, etc. > > 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] 100 Gbps line rate encryption
The fastest hardware implementation of RC4 that I know is 2 bytes/clock. I personally programmed a 1 byte/clock RC4 in a FPGA, it's quite simple. At 2 bytes/clock you still need a clock of 10 gigahertz to encrypt 100 Gbps. That's unfeasible, the way it's done is using paralelism, then you can use any algorithm you want as long as you have silicon available. Consider there are 400 Gbps systems coming online. Using a PC for that kind of workload is a waste of money and power. FPGAs are not that expensive nowadays. > Just as a data point, on x86 processors with AESNI you can encrypt AES in, > say, XTS mode with about 0.75 cycles / byte on each core. > > On an Intel Xeon E5-2690 'openssl speed -multi 4 -evp aes-128-xts' tops > out > at 13.5 GB/s for 8k blocks, which is 108 Gbps. That's only using half the > physical cores and no hyperthreading. > > However, that's unlikely a realistic benchmark for whatever context the > original question was referring to. > > > On Sat, Jun 22, 2013 at 5:25 PM, Peter Maxwell > wrote: > >> >> >> On 22 June 2013 23:31, James A. Donald wrote: >> >>> On 2013-06-23 6:47 AM, Peter Maxwell wrote: >>> >>> >>> >>> I think Bernstein's Salsa20 is faster and significantly more secure >>> than RC4, whether you'll be able to design hardware to run at >>> line-speed is >>> somewhat more questionable though (would be interested to know if it's >>> possible right enough). >>> >>> >>> I would be surprised if it is faster. >>> >>> >>> >> >> Given the 100Gbps spec, I can only presume it's hardware that's being >> talked about, which is well outwith my knowledge. We also don't know >> whether there is to be only one keystream allowed or not. >> >> However, just to give an idea of performance: from a cursory search on >> Google, once can seemingly find Salsa20/12 being implemented recently on >> GPU with performance around 43Gbps without memory transfer (2.7Gbps >> with) - >> http://link.springer.com/chapter/10.1007%2F978-3-642-38553-7_11 ) - >> unfortunately I don't have access to the paper. >> >> On a decent 64-bit processor, the full Salsa20/20 is coming in around >> 3-4cpb - http://bench.cr.yp.to/results-stream.html - and while cpb isn't >> a great measurement, it at least gives a feel for things. >> >> >> Going on a very naive approach, I would imagine the standard RC4 will >> suffer due to being byte-orientated and not particularly open to >> parallelism. Salsa20 operates on 32-bit words and from a cursory >> inspection of the spec seems to offer at least some options to do >> operations in parallel. >> >> If I were putting money on it, I suspect one could optimise at least >> Salsa20/12 to be faster than RC4 on modern platforms; whether this has >> been >> done is another story. Fairly sure Salsa20/8 was faster than RC4 >> out-of-the-box. >> >> As with anything though, I stand to be corrected. >> >> >> >> >> ___ >> 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] University of Waterloo's Quantum Cryptography School for Young Students
> There is already too much hype over QKD. It's "unbreakable" (if you pay > no attention to all those vulnerabilities at the physical layer that can > be exploited by attackers anywhere in between the encrypter and the > decrypter). > > David > But software crypto algorithms suffer from the same problems, say RSA it's unbreakable if you pay no attention to all software vulnerabilities in the implementation like memory corruptions, weak key generation, etc. I see QC as security schemes relying in physical hard problems instead of a purely mathematical hard problems. As such they are often more expensive than software-only protocols but interesting nonetheless. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
