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 byte
>> 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 onl
>> 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 - SMT
> 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 c
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
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
(IMH
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
> 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
