Forgot your password?
typodupeerror

Comment: The whole thing is unsubstantiated FUD (Score 1) 282

by fgrieu (#44496397) Attached to: Math Advance Suggest RSA Encryption Could Fall Within 5 Years

The whole thing is unsubstantiated FUD. I base my judgment on the slides at
https://media.blackhat.com/us-13/us-13-Stamos-The-Factoring-Dead.pdf

The whole argument boils down to:
a) there has recently been huge progress [*] in solving the Discrete Log Problem over fields of small characteristic;
b) progress in solving the DLP have historically implied progress in factorization, and vice versa;
c) factorization breaks RSA, and solving the DLP breaks DSA;
d) thus RSA and DSA are dead, move to ECDSA.

The fallacy of it is that in b) and c), the DLP is exclusively over fields of huge characteristics (thousands of bits), making the algorithms in a) powerless. The slides do not hint at the faintest research lead towards moving to huge characteristics. Best argument is that "renewed interest could result in further improvements".

One the positive side, the author is honest: "I’m not a mathematician, I just play one on stage".

    François Grieu

[*] See e.g. this recent paper and its references
Razvan Barbulescu, Pierrick Gaudry, Antoine Joux, Emmanuel Thomé: A quasi-polynomial algorithm for discrete logarithm in finite fields of small characteristic
http://hal.inria.fr/docs/00/83/54/46/PDF/quasi.pdf

Comment: The report's author are pretty convincing (Score 1) 133

by fgrieu (#44151325) Attached to: Backdoor Discovered In Atlassian Crowd

The original report says about the last vulnerability discussed (but not disclosed)

Indicators such as covert positioning, the use of special parameters, absence of log messages, facilitation of persistence, and apparent lack of legitimate purpose suggest that this vulnerability could be classified as a symmetric backdoor if malicious intent were to be established (which it has not).

I like the tone: they stop short of stating this is a deliberate backdoor of the worst kind, but give extremely convincing argument that it is one.

Comment: Re: Jupiter Tape? (Score 2) 621

by dachshund (#43643269) Attached to: Former FBI Agent: All Digital Communications Stored By US Gov't

There's a huge difference between this claim and lawful intercept on demand -- meaning that a formal request is made to the Telco to intercept such and such number for a period of time, then the calls are re-routed to special recording equipment.

In this case you'd need to have active real-time recording capability for every call made on every switch in the entire national phone network. You'd also have to hide this capability from the techs who work on the switches and/or swear them all to secrecy. That would be tens of thousands of switches, and many thousands of technicians.

Leaving aside the fact that you'd have to re-engineer the switches themselves, since they were not designed to support this kind of logging (no storage capacity, limited CPU, etc.)

All it would take at this point is a single wagging tongue or a Wikileaks dump to break the whole thing open. Since we've seen this happen for much smaller wiretapping deployments, I'm skeptical that you could pull anything like it off without everybody knowing.

What you can do is monitor trunk lines (which is what happened in the case of the Folsom Street tap, mentioned above) and you can certainly build your own wireless interception hardware. But this is a very different thing than what TFA claims.

Comment: Re:Jupiter Tape? (Score 2) 621

by dachshund (#43643217) Attached to: Former FBI Agent: All Digital Communications Stored By US Gov't

For the Boston Marathon bombers, this would have been a perfect investigative tool. Once you have the phone number of a target, you simply scan backwards through all of their recorded calls.

When I say nobody needs to mine the data, I don't mean nobody every looks at it. I simply mean that you don't mine it in real time. You simply record the text along with the call metadata, and wait until you have some specific targets to investigate. At that point you construct a graph from that starting point, and go back to listen to the relevant calls.

I think you're overestimating the need for voice recognition. People with burner phones still leave records. After the fact you'd look for obvious connections, paying particular attention to numbers classified as likely disposables.

(I have no doubt that some of this already happens at the metadata level, anyway. The question here is whether they actually record call contents to go with it.)

Comment: Re:Jupiter Tape? (Score 3, Informative) 621

by dachshund (#43638863) Attached to: Former FBI Agent: All Digital Communications Stored By US Gov't

Nobody needs to actively mine the data. The goal would be to collect it. Once you've collected it, you have the ability to follow leads you wouldn't have been able to follow had you not captured it in the first place.

You become aware that an individual may be a person of interest. Ordinarily you'd begin your investigation at that point. With this technology you can now go 'back in time' and figure out not only who that person spoke with, but exactly what was said in those calls. It would be incredibly useful.

I could even see Executive Branch lawyers convincing themselves that this was legal, provided the communications were not actually accessed without some sort of due process.

Of course, the problem with this theory is that it would be very hard to implement, since it would require massive and detectable changes to local telco infrastructure. On the other hand, intercepting wireless communications could be done without any such tampering, provided that the government could obtain a database of SIM credentials for decryption.

Comment: Do not judge us from what we show! (Score 2) 85

by fgrieu (#43513435) Attached to: CipherCloud Invokes DMCA To Block Discussions of Its Crypto System

The taken-down images, and the promotional video around 2:53
http://pages.ciphercloud.com/AnyAppfiveminutesdemo.html?aliId=1
make it clear that in these promotional materials, identical plaintext leads to identical ciphertext.

Ciphercould's DMCA takedown notice
http://meta.crypto.stackexchange.com/a/258/555
rebuts that as wrong ("Ciphercloud's product is not deterministic"), with a key point at the beginning of page 3:
"[detractor] implies that what was perceived from a public demo is Ciphercould's product offering".

Ciphercould's position is: you misjudged us from what we have shown, which is not the real thing.

Comment: Re:The real problem (Score 1) 347

by dachshund (#41958067) Attached to: Meet the Lawyer Suing Anyone Who Uses SSL

They're patenting a method of exchanging the keys to use for that cipher, and claiming using SSL/TLS to exchange the keys to use for RC4 violates their patent.

Not precisely. Here is Claim 1 of the patent:

providing a seed value to both said transmitter and receiver,
generating a first sequence of pseudo-random key values based on said seed value at said transmitter, each new key value in said sequence being produced at a time dependent upon a predetermined characteristic of the data being transmitted over said link,
encrypting the data sent over said link at said transmitter in accordance with said first sequence,
generating a second sequence of pseudo-random key values based on said seed value at said receiver, each new key value in said sequence being produced at a time dependent upon said predetermined characteristic of said data transmitted over said link such that said first and second sequences are identical to one another a new one of said key values in said first and said second sequences being produced each time a predetermined number of said blocks are transmitted over said link, and
decrypting the data sent over said link at said receiver in accordance with said second sequence.

So note that the keys are already provided (exchanged) in the first limitation. Then there's the issue of deriving the receiver and transmitter keys. This could refer to the pseudo-random function (PRF) used to generate session keys in TLS, but my understanding is that they're only asserting this against RC4 configurations.

That last clue is what makes me think that the "first sequence of pseudo-random key values" is RC4 output, and "encrypting" is XORing the plaintext with those values.

Comment: The real problem (Score 4, Interesting) 347

by dachshund (#41955803) Attached to: Meet the Lawyer Suing Anyone Who Uses SSL

Nevermind that the patent was actually filed in 1989, long before the World Wide Web was even invented.

The problem here is not that the patent was filed before SSL was invented (about 1995) -- that could be fine, if SSL was using a patented technology that pre-dated its own invention.

The problem here is that the attorneys are accusing the practice of 'sending network records over a wire and encrypting them with a stream cipher', where in this case the cipher is (I believe RC4). However RC4 was invented in the 1980s and should pre-date this patent. I'm certain that somebody used it to encrypt network traffic in an almost identical manner, so there should be prior art.

Moreover, stream ciphers in general have been around for much longer than that. Someone somewhere has published/deployed this idea before. It should not be a live patent. Note that the case has never been tested by a court.

Comment: Try "SearchMyFiles" (Score 1) 440

by fgrieu (#41205433) Attached to: Ask Slashdot: How Do I De-Dupe a System With 4.2 Million Files?

Recently had this situation.

Nirsoft's free "SearchMyFiles" http://www.nirsoft.net/utils/search_my_files.html has a straightforward Find Duplicates mode which helped a lot. It is easy (the most "complex" is designating the base locations for searches as e.g. K:\;L:\;P:\;Q:\), fast, never crashed on me, and had only cosmetic issues ("del" key not working). I recommend running it with administrative privileges so that it does not miss files.

Administration: An ingenious abstraction in politics, designed to receive the kicks and cuffs due to the premier or president. -- Ambrose Bierce

Working...