Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Police post plausible statement (Score 1) 415

Apparently the Rhode Island State Police posted a photo and plausible statement:

https://www.facebook.com/Rhode...

The post says the canine is "trained to detect electronic devices".

That does not look as bogus a claim as training specifically for storage media: the chemicals used in the soldering, cleaning, and IC packaging conceivably could have a detectable smell.

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

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

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

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

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

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

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

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

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.

Slashdot Top Deals

Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson

Working...