OpenVPN does its own transport protocol (on top of UDP or whatever was configured) to wrap the SSL control connection in. And for that reason OpenVPN implements its own heartbeat protocol. Let me repeat that: there is no use for TLS heartbeats with OpenVPN.
Side-note: as OpenVPN does not use vanilla SSL sockets, simple-minded Heartbleed exploits that work against HTTPS etc. won't be usable against it, but it ispossible to hand-craft a Heartbleed attack against OpenVPN servers (or clients) running with unpatched libopenssl (although AFAIK such an attack has not been seen in the wild yet).
According to wikipedia, "Ettercap is a [..] tool for man-in-the-middle attacks on LAN". It requires you to gain access to a victim's LAN! If the wikipedia page is right, it performs ARP ARP poisoning to redirect vicitm's connections. This can be detected. On a properly administrated network, this attack can automatically be detected, alerting admins etc.
Requiring access to the LAN and being easily detected for me qualifies as "difficult to deploy". Also note that the computing resources needed to MiTM SSL are pretty enormous (SSL handshake takes a lot of computation). I don't think this will scale to substantial portions of the SSL traffic of a country. Compare that with the almost complete capturing of non-encrypted traffic allegedly implemented by NSA.
You suggest that MITM attacks on SSL are as bad as someone sniffing on unencrypted traffic. It is not! MITM attacks are active attacks and are much more invasive to carry out.
Is "false security" better or worse than "no security"?
I really don't understand why everybody tries to reduce these encryption problems on the "false security" vs. "no security" dichotomy. No this is not about false security. This is about security against undetectable passive attackers vs. detectable active attackers. The amount of data a detectable active attacker is able to collect about my person are many orders of magnitude smaller than the amount of data a passive attacker is able to obtain. The active attacker will also only be able to obtain data from the point of time I was chosen as a target. The passive attacker will be able to go back in time and look at my communication (probably many years) before I became interesting enough to be deemed a target.
This is why implementing SSL, even if no protection at all against MITM existed, is much much better than no SSL at all.
It is pretty dangerous for an adversary to carry out MITM attacks on a large scale, as sooner or later, this is going to be detected.
Apparently they weren't detected until the Snowden files showed it is widespread...(hacking into Belgacom for example), and wasn't the FBI requesting the SSL keys of Lavabit to decrypt traffic?
The attack the FBI attempted on Lavabit had no relation at all to certificate authorities. They merely requested the private host key of the server to be able to decrypt any recorded SSL traffic for that site. Note how this kind of attack only works when you have access to the server in question (in which case you would be able to directly monitor the plaintext communication anyway by tracing the web server executable). I repeat, this is not related at all to certificate authorities. Also note how this attack does not really scale, as it requires you to actively request and collect SSL host keys (not certs!) of all webservers whose traffic you are interested in. For that reason I would expect that information about your operations *will* inevitably leak to the public. Also web servers in other countries will be relatively well protected against this kind of attack.
The SSL Everywhere extension for example can (optionally) collect information for and check with the SSL Observatory to detect differing certificates that indicate MITM attacks.
a MITM attack would also patch (or redirect) SSL Observatory
only decentralized with checks on locally stored previously seen certificates can work, otherwise it's just security theater
But here again at MITM attack would be detectable. If the SSL Everywhere guys were not completely stupid they will check the host key of the SSL Observatory against a private certificate authority that they completely own (with the certifcate authorities' key hard-coded into their browser extension). Or more simple, they could just hard-code the public key of the observatory. Or implement certificate pinning etc. etc.
The only working attack would be for the NSA to MITM every download of the SSL Everywhere executable, patching the certificates contained in its code. But again, this is easy to detect after the fact by inspecting the sources, comparing checksums etc.
For that reason I'm not afraid at all about MITM, as it does not allow for the broad, secret, non-discriminatory data collection that Snowden's leaks show to be implemented by NSA.
The NSA likely has keys from all the major SSL cert vendors, rendering this "spamvertisement" moot. HTTPS does not mean that you're secure from everybody. It means you've added a layer of security that will thwart MOST prying eyes, but those that really want to know what you're doing WILL know what you're doing.
Having the keys from multiple SSL cert vendors does not help a bit (and having the keys from many vendors isn't much better than having the keys of a single vendor). It does NOT magically allow you to decrypt SSL traffic from servers whose host key was signed against that cert vendor's certificate!
To decrypt traffic of multiple SSL websites requires you to obtain the private part of the SSL host keys from all the web-servers themselves. Note that web server host keys are signed via signing requests that do not contain a copy of the private key, so even when the cert vendors (CAs) are hacked, you cannot directly listen in on SSL communication. When the servers implement Perfect Forward Secrecy, then even obtaining a copy of the server's host key won't help as each connection uses a temporary key that's exchanged via Diffie Hellman Key Exchange, a method that generates a key shared between two hosts, that (somewhat counter-intuitively) cannot be deduced by sniffing the traffic between those two participants.
What you can still do is to set up a MITM attack: you set up your own intermediate server with its own host key and sign your host key(s) using one of the SSL vendor's certs that you obtained. Then you redirect all traffic to the servers that interest you via your server (i.e. proxying all SSL connections) and then obviously in the process you obtain the cleartext of all SSL sessions running via your server.
However, the MITM attack is much more difficult to deploy and scale than simple monitoring and recording IP data. Also skilled users will easily detect the MITM attack, as the host key's public part of the servers in question will suddenly change. There are firefox extensions to check for these signs of a MITM. Even SSL Everywhere has a checker built in (via the SSL Observatory). Or try Certificate Patrol.
> this means that Firefox on Android with HTTPS Everywhere is now by far the most secure browser
> against dragnet surveillance attacks like those performed by the NSA, GCHQ, and other intelligence agencies.
While I certainly think it is a good idea to encrypt traffic, this statement is highly misleading or naive: Since the CA
system is *flawd by design* and every one of those "authorities" in the long list of built-in CA inside
your browser can, by negligence or choice, supply any of these and other agencies with a valid certificate for
*any hostname in the world*, initiatives like these protect your privacy only from your local sysadmin/ISP, and also
do nothing against traffic analysis.
Should a US person/company trust that "China Internet Network Information Center" isn't going to create a cert for a
US bank or company to perform a MITM attach with? Should a Chinese company trust "Wells Fargo" not to?
Should the Greeks trust "TÜRKTRUST Bilgi letiim ve Biliim Güvenlii Hizmetleri A.. (c) Aralk 2007", or the
Turks "Hellenic Academic and Research Institutions Cert. Authority"? What on earth makes you think ALL of these
companies can resists pressures to misbehave? Yet all of them are built-in to your browser and "you" trust them.
[..]
The Cert validation in the browsers leads to a *dangerous false sense of security* at most. This is crypto, a weakest-link business
[..]
You suggest that MITM attacks on SSL are as bad as someone sniffing on unencrypted traffic. It is not! MITM attacks are active attacks and are much more invasive to carry out. That's not all: in principle all these MITM attacks can be detected: the host key of the Man In The Middle will differ from the host key of the original server (though your browser will accept the differing host key when it is signed by a rogue CA).
It is pretty dangerous for an adversary to carry out MITM attacks on a large scale, as sooner or later, this is going to be detected. The SSL Everywhere extension for example can (optionally) collect information for and check with the SSL Observatory to detect differing certificates that indicate MITM attacks.
There's also the Certificate Patrol Firefox Extension that persistently remembers certificates and warns when certificates changed for no apparent reason.
Also a lot of houses have remote heating using residual heat from gas or coal power stations. This way these power stations get an efficiency rating of close to 100%, something that wouldn't be possible otherwise (due to the second law of thermodynamics).
Sigh...he is NOT talking about putting it into ROM, that is impossible with that chip. What he is talking about is putting a software "lock" on the chip so you can NOT UPDATE and that somehow magically makes it a "circuit" which just shows how cult like the man is, how he can just manipulate language to his own ends.
This is about putting dedicated hardware on board to load default firmware from a flash-ROM into the Marvell WLAN chip, so you d o not need to load the firmware after every boot. There is plenty of explanation on the project page , and quite clearly it writes
The task is to develop a prototype of a microcontroller that sends an immutable firmware program through an SDIO interface into a Marvell 8686 based WLAN chip independently from the main CPU.
But why bother reading about details when it is so much fun to just complain and whine and repeat your half understood rants on half understood topics, right?
Its like how his FSF sues people for violating the GPL but he says stealing copyrighted code is fine and dandy, even labels it "sharing with a neighbor"...WTF?
I won't even start to tell you how many mis-statements are contained in this sentence, let alone the whole paragraph I'm not bothering to quote. Luckily/. features a Foes list that will save me from ever attempting to argue on any matter with you again.
You know that Emacs does not parse most of its.elc or.el files at startup? These are parsed during Emacs compilation, then an image of the Emacs process' memory is dumped to disk and used for quick startup. Only system config files from/etc or ~/.emacs and dependent files need to be parsed.
Uhhh...its pretty obvious it was just Torvalds being a frustrated programmer and joking about a piece of software that was being a giant PITA, which we've ALL been there.
He was "joking" (?) about *his* piece of software, Git, quite clearly claiming that people complaining about it are just idiots. Using a pretty offensive language (even if just joking), on a public mailing list. If Linus was a little bit more open-minded or tolerant or spending one second of his time thinking about the users of his software (let's better call them victims), I think he might at least acknowledge that the problem might with Git's lack of consistency, lack of documentation and general complexity (when compared to alternate DVCS). There are more Linus-quotes that reflect a (IMO) questionable attitude towards his users, enough that I take everything he boasts about with a grain of salt. But we're getting off-topic.
I mean locking something down makes it "freer" than if you can update it? WTF? that sounds like the RIAA more than it does the FSF but it boils down to his own dogma simply doesn't work so he has to cook up hoops to jump through that defy logic so that he can jam that dogma into situations where it wouldn't otherwise go. I mean look at those two links, Its BETTER if you DO lock it down but WORSE if you can see and manipulate the code UNLESS that code is GNU....okay, how in the FUCK does that make ANY sense? At all? Its like Mad hatter logic!
Yeah, now I get the point you were referring to. It might seem inconsisten, but maybe you didn't think his reasoning to the end: If a WLAN-chip required a closed firmware to operate, than the Linux kernel has to be shipped with a copy of the (binary and non-modifyable!) firmware embedded. Now suddenly your operating system isn't free any more, as it's bound not only by the Linux license, but also by the license of the firmware. What when it stated that export to Cuba was forbidden? Or specific uses were excluded? You generally don't want to teint your GPLed operating system with non-GPLed bits and pieces protected by copyright. Putting the questionable firmware in an on-board ROM at leasts frees people that deal with the Linux-OS images from having to care about the copyrights of the non-free firmware (the board's manufacturer will still have to deal with it, though).
Please don't quote RMS. if you have a quote from Torvalds or Perens or frankly anybody else then great, but RMS tried to claim [..]
I won't consider myself a RMS fan or a free software zealot, just by knowing some of RMS' opinions and quoting them when I think they provide a valid point on some issue. On the other hand, you seem to be a complete anti-RMS zealot. "Please don't quote RMS"? Just because some of his stuff is too extreme for your taste?
You think Torvalds is any better? Hey, I have a quote for you (source)
We will hereby start scouring the net for people who say git is hard to
understand and use, and just kill them. They clearly are just polluting
the gene pool.
If I were you, I'd rather ask people to not quote Torvalds than to not quote RMS.
As a result they are only produced by one source which is facing some hurdles justifying their copying of IP.
I am the only one who's annoyed by the poster's complete lack of critical reflection on those "IP" claims? Are the IP lawyers and lobbyists now getting their anonymous postings on slashdot, too? I'm close to deleting my/. account.
BTW I'm also annoyed by the fact that people got so used to the somewhat nonsensical oxymoron "Intelectual Property".
What they found in her thesis is that she rightly referenced the authors she quoted word for word, but didn't reference the authors again in following sentences that were in relation to those first quotes in 56 cases.
No, what they found is that she copied other author's text including footnotes. At other places she reformatted in-line references of the original into footnotes of her text.
Whether she copied the text literally or not; if you copy references&footnotes, keeping the original order and semantics, it's pretty clear that you didn't think of your own. I don't think reformulating and reformatting skills entitle you to a PhD.
Cryptome has this leaked Digitask presentation, detailing how their "Remote Forensic Software" product works. Among others, the presentation lists HTTPS, IM-Clients, encrypted POP, SMTP, GPG, VPN, Skype and disk-encryption as possible targets for their "LI" (Lawful(!) Interception) systems.
It runs the software that you write, and you don't even need any SDK for that. Out of the box it runs Lua, Python, Tcl, Octave, Scheme, gForth, Emacs-Lisp, Shell Script and who knows what else. There's even a GCC toolchain package available, if you need it. If you're satisfied with the software that vendors throw at you or allow you to obtain via their managed app-store, than maybe NanoNote is not made for you.
Freescale iMX51 and TI OMAPs are completely proprietary, AFAIR. If at all you'll only get closed-source drivers for their built-in GPUs. That doesn't make them very sexy for such open-source hardware projects. Also I guess you'll soon run into real-time execution problems, if the GPU drivers aren't 100% perfect. Even with my ATI card I have these problems from time to time (something flushing GPU pipelines? no clue.). This FPGA CPU with RTOS kernel and custom-made 2-D acceleration will allow you to get perfect frames, all the time.
[..] To this day, the only thing I find lacking is multimedia players (and I especially miss Winamp).
Did you try the Audacious audio player? It was once forked from XMMS, which was a pretty good Winamp clone (for me anyways, haven't seen any Winamp since the year 2000:). I still have Audacious configured to start with the XMMS skin, which is pretty close to how Winamp looked in 2000.
With regard to media players, there's quite a lot of stuff around. Mplayer is certainly the best-performing media player on Linux. If you prefer a nicer GUI, there's also VLC. When you need more codecs, install Ubuntu package ubuntu-restricted-extras, and/or add the medibuntu repository to your package sources.
BTW, this mailing-list post contains all the details about how the MMC (SDIO) controller is used here. An earlier version relied on doing bit-banging with the MMC lines programmed as general-purpose I/Os, but didn't even reach QVGA resolution this way.
Ok sure, go ahead and run a 8k x 8k Linpack, tell me how that goes and how non-limited you are.
I guess if 8kx8k Linpack refers to matrix multiplication, I'm pretty sure that the Cell will perform at close to its 200GFLOP/s performance. Matrix multiplication can be really well broken down into block-matrix multiplications that nicely fit in the 256KB of available SRAM. Data transfer cost per block grows O(N^2), while FLOPs grow O(N^3). With 64x64 block matrixes you have to transfer 2*64*64 floats while having to compute 32 times as many multiply&adds. With 8 SPUs sharing the single XDR RAM you'll only have bandwidth to transfer 1/4 float per cycle and core. However, corresponding to that transfer rate, the core has to compute 32*1/4=8 madds per cycle, which happens to be twice the theoretical peak performance of the core. So no bandwidth problem at all. You'll be able to increase block size to 96x96 if you want to reduce bandwidth per FLOP even further. this paper claims close to peak performance for 2304x2304 sized matrices.
Sorry man, the Cell is fine for some things but the idea that it doesn't face the same realistic limits other hardware does is silly. You can talk all you like about high speed stuff on the cache, but that applies only for things that'll fit in there. When you have larger problem sets
that have to go back and forth to main memory a lot, I'm afraid it isn't so fast.
You'll have these kind of losses on any architecture, including GPUs. What i'm saying is that the Cell is designed so that you'll almost always be able to reach close to 100% utilization of the available peak FLOP/s. That is something that you won't ever normally achieve on a GPU. On the other hand, GPUs have a much higher peak FLOP/s so loosing half of that due to bandwidth problem seems to be more acceptible.
Regardless my point was simply how unrealistic it is to call the thing a supercomputer. If a couple hundred GFLOPS makes a supercomputer then my GPU is a supercomputer.
Don't downplay what GPUs can do computationally either. They are the kings of Folding, yes ahead of the PS3. So long as your problem meets some requirements (highly parallel, single precision FP, fits in to GPU memory, not a lot of branching and when it branches everything branches the same direction) they scream. Is that all things? No, certainly not, you can find things they drag ass on. However the same happens with the Cell when compared to something like a Core i7. For some things, due to the SPEs the Cell is faster, however for others, due to constraints of the PPE it is slower.
Well it's not the constraints on the PPE that make the Cell slow. The Cell is just as fast as 200GPLOP/s can be. Modern GPUs are much faster than that, even if they cannot utilize all their horsepower. The downside is that GPUs rely on very different programming&compiler paradigms, where Cell was designed to mostly use multi-core, shared memory pradigms and standard C compilers with SIMD extensions, everything nicely managed by a standard MMU-utilizing operating system.
It is an interesting architecture and useful for some things, but it is not particularly impressive compared to other modern processors. Doesn't mean it is worthless, just that it is not "OMG this is so fast!".
It was that fast when it came out. Unfortunately development of the successors was cancelled by IBM, probably due to GPGPU programming eating its lunch.
The best they claim is 25.6 GFLOPS per cell in theoretical performance, so 205 GFLOPS is the best you theoretically get, if there are no bandwidth constraints (which there are on a PS3) for single precision math. Ok well testing my actual Radeon 5870, I get 800 GFLOPS for single precision, 227 for double precision. That is an actual benchmark of the card running on my desktop.
As somebody who programmed Cell CPUs for signal processing (including to, but not limited to PS3s), let me tell you that the PS3's memory bandwidth is so close to unlimited, that you usually don't have to think about it. At least as long as you move data only on the Element Interconnect Bus, between the 256KB local SRAMs of each CELL core, which is sufficient for most of what I did. It moves up to 200 giga bytes per second, maximum 16 bytes per 2 cycles in and out per core. The DMA engines that do those transfer have their own 1024bit (!) read/write port into the SRAM, so they burst 128 bytes per cycle into the SRAM, and don't have to steel many RAM cycles. The wikidedia article has more details.
In my experience, you can usually come pretty close to the 200 GFLOP/s of the Cell-CPU. When relying on C-Compiler with SIMD intrinsics, you usually manage 100 GPFOP/s for algorithms that have as many read/write opcodes as arithmetic opcodes. Smaller problems can mostly be handled on registers only (per CPU we have 128 16-byte registers!) and will run even faster.
Also note that many algorithms nowadays are not bandwidth but memory latency limited. Having the Cell's per-core DMA engines do background transfers to large local S-RAMs, mostly eliminates these latency problems and is much cleaner than relying on CPU caches guessing what parts of RAM to prefetch next. BTW these are user-space DMA engines that undergo page translation and are fully compatible to unix vm concepts. Still programming directly accesses DMA registers and doesn't need any kernel calls.
Darwin, the core of Mac OS X, is open source, for example, as well as Webkit, Apple's browser layout engine used in most browsers today, including Google Chrome and Android. And Grand Central Dispatch. And FaceTime. I could go on.
I won't say that this argument proves much about Apple's attitude towards openness. Webkit is based on KHTML which is LGPL and authorship not residing with Apple, so they absolutely had to open it up to satisfy the license.
The Darwin kernel is based on other free software work (mostly BSD?), BTW. No, the BSD license might not force Apple to open-source it, but it doesn't hurt so much, open-sourcing code that's freely available anyways.
1 picosecond (ps) is 10^(-12) secs.
You can run a single instruction in a 1000 GHz CPU (please scale to your favourite multicore system) during 1 ps.
Actually you cannot even run a single instruction during 1ps. Modern CPUs are pipelined and make it look like an instruction takes one cycle. However, between loading of input, processing, and output, ca 20 cycles pass. It's just that with 20 instructions in the pipeline, you might get an effective throughput of 20 instructions per 20 cycles. And this does not even consider cache/memory and i/o access times.
Total I/O latency between signal arriving at PC, and PC answering may well be in the order of many 100 (if not 1000) cycles.
Playing games with ambiguity of the language I used? English grammar "a" is an indefinite article, hinting at a generic statement. Also if you look at the full post you might find sufficient redundancy to resolve any ambiguities.
I don't have any specific sources, other than the original paper linked by TFA. For my statements about using trellis algorithm, try any books about coding theory. Unfortunately the wikipedia article on trellis is not very helpful.
The more general idea behind this is dynamic programming. If you have an equation of N boolean variables, you can brute force in 2^N. If you have M equations of 2^N variables, where equation share variables only with one or more neighbouring equations, you can determine solutions for every equation on its own in M*2^N steps and save those (partial) solutions. Then to find a solution that satifies all equations you just have to find a "path" through all equations from left to right. That path has M*2^N nodes. The edges of the graph connect solutions that do not collide (i.e. where variables overlapping between solutions take the same value). Since only neighbouring equations overlap in their variables, the number of edges per node is some (not too large) constant. Finding such a path is now straight-forward and polynomial effort. see also here.
So for the riplets in this paper N is 3, so 2^N is a constant, leaving no exponential in the computational cost function.
I hoped other people could comment on their impression of the paper, but as this is/. RTFA is not so common I guess:)
This is not a P=NP paper. The paper solves a problem of a related data structure in polynomial time (quartic time), then shows that it can be used to solve some cases of 3SAT.
The 3 outputs the algorithm can give are "the formula is not satisfiable", "the formula is satisfiable" (and the solution is given), and "failure of classification" -- it couldn't solve the problem.
The important question we wait for on the experts on this paper isn't "is it correct" (it probably is) but "how effective is it".
In fact it does suffice to show that the algorithm determines satisfiability of a 3-SAT instance in polynomial time. Create a derived 3-SAT instance that adds a clause restricting one variable to value '1'. Then see whether it is still satisfiable. It is not? Ok, constrain the variable to '0', and add a constraint for the next variable. Is it now satisfiable? And on and on. You understand the pattern? For n variables it only takes O(n) time to turn the 3-SAT satisfiability testing algorithm into a 3-SAT solver. Or in CS terms: the 3-SAT decision problem is polynomial time reducable to the 3-SAT solving problem.
Slashdot Mirror
Side-note: as OpenVPN does not use vanilla SSL sockets, simple-minded Heartbleed exploits that work against HTTPS etc. won't be usable against it, but it is possible to hand-craft a Heartbleed attack against OpenVPN servers (or clients) running with unpatched libopenssl (although AFAIK such an attack has not been seen in the wild yet).
Requiring access to the LAN and being easily detected for me qualifies as "difficult to deploy". Also note that the computing resources needed to MiTM SSL are pretty enormous (SSL handshake takes a lot of computation). I don't think this will scale to substantial portions of the SSL traffic of a country. Compare that with the almost complete capturing of non-encrypted traffic allegedly implemented by NSA.
You suggest that MITM attacks on SSL are as bad as someone sniffing on unencrypted traffic. It is not! MITM attacks are active attacks and are much more invasive to carry out.
Is "false security" better or worse than "no security"?
I really don't understand why everybody tries to reduce these encryption problems on the "false security" vs. "no security" dichotomy. No this is not about false security. This is about security against undetectable passive attackers vs. detectable active attackers. The amount of data a detectable active attacker is able to collect about my person are many orders of magnitude smaller than the amount of data a passive attacker is able to obtain. The active attacker will also only be able to obtain data from the point of time I was chosen as a target. The passive attacker will be able to go back in time and look at my communication (probably many years) before I became interesting enough to be deemed a target.
This is why implementing SSL, even if no protection at all against MITM existed, is much much better than no SSL at all.
It is pretty dangerous for an adversary to carry out MITM attacks on a large scale, as sooner or later, this is going to be detected.
Apparently they weren't detected until the Snowden files showed it is widespread...(hacking into Belgacom for example), and wasn't the FBI requesting the SSL keys of Lavabit to decrypt traffic?
The attack the FBI attempted on Lavabit had no relation at all to certificate authorities. They merely requested the private host key of the server to be able to decrypt any recorded SSL traffic for that site. Note how this kind of attack only works when you have access to the server in question (in which case you would be able to directly monitor the plaintext communication anyway by tracing the web server executable). I repeat, this is not related at all to certificate authorities. Also note how this attack does not really scale, as it requires you to actively request and collect SSL host keys (not certs!) of all webservers whose traffic you are interested in. For that reason I would expect that information about your operations *will* inevitably leak to the public. Also web servers in other countries will be relatively well protected against this kind of attack.
The SSL Everywhere extension for example can (optionally) collect information for and check with the SSL Observatory to detect differing certificates that indicate MITM attacks.
a MITM attack would also patch (or redirect) SSL Observatory
only decentralized with checks on locally stored previously seen certificates can work, otherwise it's just security theater
But here again at MITM attack would be detectable. If the SSL Everywhere guys were not completely stupid they will check the host key of the SSL Observatory against a private certificate authority that they completely own (with the certifcate authorities' key hard-coded into their browser extension). Or more simple, they could just hard-code the public key of the observatory. Or implement certificate pinning etc. etc.
The only working attack would be for the NSA to MITM every download of the SSL Everywhere executable, patching the certificates contained in its code. But again, this is easy to detect after the fact by inspecting the sources, comparing checksums etc.
For that reason I'm not afraid at all about MITM, as it does not allow for the broad, secret, non-discriminatory data collection that Snowden's leaks show to be implemented by NSA.
The NSA likely has keys from all the major SSL cert vendors, rendering this "spamvertisement" moot. HTTPS does not mean that you're secure from everybody. It means you've added a layer of security that will thwart MOST prying eyes, but those that really want to know what you're doing WILL know what you're doing.
Having the keys from multiple SSL cert vendors does not help a bit (and having the keys from many vendors isn't much better than having the keys of a single vendor). It does NOT magically allow you to decrypt SSL traffic from servers whose host key was signed against that cert vendor's certificate!
To decrypt traffic of multiple SSL websites requires you to obtain the private part of the SSL host keys from all the web-servers themselves. Note that web server host keys are signed via signing requests that do not contain a copy of the private key, so even when the cert vendors (CAs) are hacked, you cannot directly listen in on SSL communication. When the servers implement Perfect Forward Secrecy, then even obtaining a copy of the server's host key won't help as each connection uses a temporary key that's exchanged via Diffie Hellman Key Exchange, a method that generates a key shared between two hosts, that (somewhat counter-intuitively) cannot be deduced by sniffing the traffic between those two participants.
What you can still do is to set up a MITM attack: you set up your own intermediate server with its own host key and sign your host key(s) using one of the SSL vendor's certs that you obtained. Then you redirect all traffic to the servers that interest you via your server (i.e. proxying all SSL connections) and then obviously in the process you obtain the cleartext of all SSL sessions running via your server.
However, the MITM attack is much more difficult to deploy and scale than simple monitoring and recording IP data. Also skilled users will easily detect the MITM attack, as the host key's public part of the servers in question will suddenly change. There are firefox extensions to check for these signs of a MITM. Even SSL Everywhere has a checker built in (via the SSL Observatory). Or try Certificate Patrol.
> this means that Firefox on Android with HTTPS Everywhere is now by far the most secure browser > against dragnet surveillance attacks like those performed by the NSA, GCHQ, and other intelligence agencies.
While I certainly think it is a good idea to encrypt traffic, this statement is highly misleading or naive: Since the CA system is *flawd by design* and every one of those "authorities" in the long list of built-in CA inside your browser can, by negligence or choice, supply any of these and other agencies with a valid certificate for *any hostname in the world*, initiatives like these protect your privacy only from your local sysadmin/ISP, and also do nothing against traffic analysis.
Should a US person/company trust that "China Internet Network Information Center" isn't going to create a cert for a US bank or company to perform a MITM attach with? Should a Chinese company trust "Wells Fargo" not to? Should the Greeks trust "TÜRKTRUST Bilgi letiim ve Biliim Güvenlii Hizmetleri A.. (c) Aralk 2007", or the Turks "Hellenic Academic and Research Institutions Cert. Authority"? What on earth makes you think ALL of these companies can resists pressures to misbehave? Yet all of them are built-in to your browser and "you" trust them.
[..]
The Cert validation in the browsers leads to a *dangerous false sense of security* at most. This is crypto, a weakest-link business [..]
You suggest that MITM attacks on SSL are as bad as someone sniffing on unencrypted traffic. It is not! MITM attacks are active attacks and are much more invasive to carry out. That's not all: in principle all these MITM attacks can be detected: the host key of the Man In The Middle will differ from the host key of the original server (though your browser will accept the differing host key when it is signed by a rogue CA).
It is pretty dangerous for an adversary to carry out MITM attacks on a large scale, as sooner or later, this is going to be detected. The SSL Everywhere extension for example can (optionally) collect information for and check with the SSL Observatory to detect differing certificates that indicate MITM attacks.
There's also the Certificate Patrol Firefox Extension that persistently remembers certificates and warns when certificates changed for no apparent reason.
Also a lot of houses have remote heating using residual heat from gas or coal power stations. This way these power stations get an efficiency rating of close to 100%, something that wouldn't be possible otherwise (due to the second law of thermodynamics).
Sigh...he is NOT talking about putting it into ROM, that is impossible with that chip. What he is talking about is putting a software "lock" on the chip so you can NOT UPDATE and that somehow magically makes it a "circuit" which just shows how cult like the man is, how he can just manipulate language to his own ends.
This is about putting dedicated hardware on board to load default firmware from a flash-ROM into the Marvell WLAN chip, so you d o not need to load the firmware after every boot. There is plenty of explanation on the project page , and quite clearly it writes
The task is to develop a prototype of a microcontroller that sends an immutable firmware program through an SDIO interface into a Marvell 8686 based WLAN chip independently from the main CPU.
But why bother reading about details when it is so much fun to just complain and whine and repeat your half understood rants on half understood topics, right?
Its like how his FSF sues people for violating the GPL but he says stealing copyrighted code is fine and dandy, even labels it "sharing with a neighbor"...WTF?
I won't even start to tell you how many mis-statements are contained in this sentence, let alone the whole paragraph I'm not bothering to quote. Luckily /. features a Foes list that will save me from ever attempting to argue on any matter with you again.
You know that Emacs does not parse most of its .elc or .el files at startup? These are parsed during Emacs compilation, then an image of the Emacs process' memory is dumped to disk and used for quick startup. Only system config files from /etc or ~/.emacs and dependent files need to be parsed.
Uhhh...its pretty obvious it was just Torvalds being a frustrated programmer and joking about a piece of software that was being a giant PITA, which we've ALL been there.
He was "joking" (?) about *his* piece of software, Git, quite clearly claiming that people complaining about it are just idiots. Using a pretty offensive language (even if just joking), on a public mailing list. If Linus was a little bit more open-minded or tolerant or spending one second of his time thinking about the users of his software (let's better call them victims), I think he might at least acknowledge that the problem might with Git's lack of consistency, lack of documentation and general complexity (when compared to alternate DVCS). There are more Linus-quotes that reflect a (IMO) questionable attitude towards his users, enough that I take everything he boasts about with a grain of salt. But we're getting off-topic.
I mean locking something down makes it "freer" than if you can update it? WTF? that sounds like the RIAA more than it does the FSF but it boils down to his own dogma simply doesn't work so he has to cook up hoops to jump through that defy logic so that he can jam that dogma into situations where it wouldn't otherwise go. I mean look at those two links, Its BETTER if you DO lock it down but WORSE if you can see and manipulate the code UNLESS that code is GNU....okay, how in the FUCK does that make ANY sense? At all? Its like Mad hatter logic!
Yeah, now I get the point you were referring to. It might seem inconsisten, but maybe you didn't think his reasoning to the end: If a WLAN-chip required a closed firmware to operate, than the Linux kernel has to be shipped with a copy of the (binary and non-modifyable!) firmware embedded. Now suddenly your operating system isn't free any more, as it's bound not only by the Linux license, but also by the license of the firmware. What when it stated that export to Cuba was forbidden? Or specific uses were excluded? You generally don't want to teint your GPLed operating system with non-GPLed bits and pieces protected by copyright. Putting the questionable firmware in an on-board ROM at leasts frees people that deal with the Linux-OS images from having to care about the copyrights of the non-free firmware (the board's manufacturer will still have to deal with it, though).
Please don't quote RMS. if you have a quote from Torvalds or Perens or frankly anybody else then great, but RMS tried to claim [..]
I won't consider myself a RMS fan or a free software zealot, just by knowing some of RMS' opinions and quoting them when I think they provide a valid point on some issue. On the other hand, you seem to be a complete anti-RMS zealot. "Please don't quote RMS"? Just because some of his stuff is too extreme for your taste?
You think Torvalds is any better? Hey, I have a quote for you (source)
We will hereby start scouring the net for people who say git is hard to understand and use, and just kill them. They clearly are just polluting the gene pool.
If I were you, I'd rather ask people to not quote Torvalds than to not quote RMS.
As a result they are only produced by one source which is facing some hurdles justifying their copying of IP.
I am the only one who's annoyed by the poster's complete lack of critical reflection on those "IP" claims? Are the IP lawyers and lobbyists now getting their anonymous postings on slashdot, too? I'm close to deleting my /. account.
BTW I'm also annoyed by the fact that people got so used to the somewhat nonsensical oxymoron "Intelectual Property".
What they found in her thesis is that she rightly referenced the authors she quoted word for word, but didn't reference the authors again in following sentences that were in relation to those first quotes in 56 cases.
No, what they found is that she copied other author's text including footnotes. At other places she reformatted in-line references of the original into footnotes of her text. Whether she copied the text literally or not; if you copy references&footnotes, keeping the original order and semantics, it's pretty clear that you didn't think of your own. I don't think reformulating and reformatting skills entitle you to a PhD.
Cryptome has this leaked Digitask presentation, detailing how their "Remote Forensic Software" product works. Among others, the presentation lists HTTPS, IM-Clients, encrypted POP, SMTP, GPG, VPN, Skype and disk-encryption as possible targets for their "LI" (Lawful(!) Interception) systems.
Can it do anything my Blackberry can't?
It runs the software that you write, and you don't even need any SDK for that. Out of the box it runs Lua, Python, Tcl, Octave, Scheme, gForth, Emacs-Lisp, Shell Script and who knows what else. There's even a GCC toolchain package available, if you need it. If you're satisfied with the software that vendors throw at you or allow you to obtain via their managed app-store, than maybe NanoNote is not made for you.
Freescale iMX51 and TI OMAPs are completely proprietary, AFAIR. If at all you'll only get closed-source drivers for their built-in GPUs. That doesn't make them very sexy for such open-source hardware projects. Also I guess you'll soon run into real-time execution problems, if the GPU drivers aren't 100% perfect. Even with my ATI card I have these problems from time to time (something flushing GPU pipelines? no clue.). This FPGA CPU with RTOS kernel and custom-made 2-D acceleration will allow you to get perfect frames, all the time.
[..] To this day, the only thing I find lacking is multimedia players (and I especially miss Winamp).
Did you try the Audacious audio player? It was once forked from XMMS, which was a pretty good Winamp clone (for me anyways, haven't seen any Winamp since the year 2000 :). I still have Audacious configured to start with the XMMS skin, which is pretty close to how Winamp looked in 2000.
With regard to media players, there's quite a lot of stuff around. Mplayer is certainly the best-performing media player on Linux. If you prefer a nicer GUI, there's also VLC. When you need more codecs, install Ubuntu package ubuntu-restricted-extras, and/or add the medibuntu repository to your package sources.
BTW, this mailing-list post contains all the details about how the MMC (SDIO) controller is used here. An earlier version relied on doing bit-banging with the MMC lines programmed as general-purpose I/Os, but didn't even reach QVGA resolution this way.
Ok sure, go ahead and run a 8k x 8k Linpack, tell me how that goes and how non-limited you are.
I guess if 8kx8k Linpack refers to matrix multiplication, I'm pretty sure that the Cell will perform at close to its 200GFLOP/s performance. Matrix multiplication can be really well broken down into block-matrix multiplications that nicely fit in the 256KB of available SRAM. Data transfer cost per block grows O(N^2), while FLOPs grow O(N^3). With 64x64 block matrixes you have to transfer 2*64*64 floats while having to compute 32 times as many multiply&adds. With 8 SPUs sharing the single XDR RAM you'll only have bandwidth to transfer 1/4 float per cycle and core. However, corresponding to that transfer rate, the core has to compute 32*1/4=8 madds per cycle, which happens to be twice the theoretical peak performance of the core. So no bandwidth problem at all. You'll be able to increase block size to 96x96 if you want to reduce bandwidth per FLOP even further. this paper claims close to peak performance for 2304x2304 sized matrices.
Sorry man, the Cell is fine for some things but the idea that it doesn't face the same realistic limits other hardware does is silly. You can talk all you like about high speed stuff on the cache, but that applies only for things that'll fit in there. When you have larger problem sets that have to go back and forth to main memory a lot, I'm afraid it isn't so fast.
You'll have these kind of losses on any architecture, including GPUs. What i'm saying is that the Cell is designed so that you'll almost always be able to reach close to 100% utilization of the available peak FLOP/s. That is something that you won't ever normally achieve on a GPU. On the other hand, GPUs have a much higher peak FLOP/s so loosing half of that due to bandwidth problem seems to be more acceptible.
Regardless my point was simply how unrealistic it is to call the thing a supercomputer. If a couple hundred GFLOPS makes a supercomputer then my GPU is a supercomputer.
Don't downplay what GPUs can do computationally either. They are the kings of Folding, yes ahead of the PS3. So long as your problem meets some requirements (highly parallel, single precision FP, fits in to GPU memory, not a lot of branching and when it branches everything branches the same direction) they scream. Is that all things? No, certainly not, you can find things they drag ass on. However the same happens with the Cell when compared to something like a Core i7. For some things, due to the SPEs the Cell is faster, however for others, due to constraints of the PPE it is slower.
Well it's not the constraints on the PPE that make the Cell slow. The Cell is just as fast as 200GPLOP/s can be. Modern GPUs are much faster than that, even if they cannot utilize all their horsepower. The downside is that GPUs rely on very different programming&compiler paradigms, where Cell was designed to mostly use multi-core, shared memory pradigms and standard C compilers with SIMD extensions, everything nicely managed by a standard MMU-utilizing operating system.
It is an interesting architecture and useful for some things, but it is not particularly impressive compared to other modern processors. Doesn't mean it is worthless, just that it is not "OMG this is so fast!".
It was that fast when it came out. Unfortunately development of the successors was cancelled by IBM, probably due to GPGPU programming eating its lunch.
The best they claim is 25.6 GFLOPS per cell in theoretical performance, so 205 GFLOPS is the best you theoretically get, if there are no bandwidth constraints (which there are on a PS3) for single precision math. Ok well testing my actual Radeon 5870, I get 800 GFLOPS for single precision, 227 for double precision. That is an actual benchmark of the card running on my desktop.
As somebody who programmed Cell CPUs for signal processing (including to, but not limited to PS3s), let me tell you that the PS3's memory bandwidth is so close to unlimited, that you usually don't have to think about it. At least as long as you move data only on the Element Interconnect Bus, between the 256KB local SRAMs of each CELL core, which is sufficient for most of what I did. It moves up to 200 giga bytes per second, maximum 16 bytes per 2 cycles in and out per core. The DMA engines that do those transfer have their own 1024bit (!) read/write port into the SRAM, so they burst 128 bytes per cycle into the SRAM, and don't have to steel many RAM cycles. The wikidedia article has more details.
In my experience, you can usually come pretty close to the 200 GFLOP/s of the Cell-CPU. When relying on C-Compiler with SIMD intrinsics, you usually manage 100 GPFOP/s for algorithms that have as many read/write opcodes as arithmetic opcodes. Smaller problems can mostly be handled on registers only (per CPU we have 128 16-byte registers!) and will run even faster.
Also note that many algorithms nowadays are not bandwidth but memory latency limited. Having the Cell's per-core DMA engines do background transfers to large local S-RAMs, mostly eliminates these latency problems and is much cleaner than relying on CPU caches guessing what parts of RAM to prefetch next. BTW these are user-space DMA engines that undergo page translation and are fully compatible to unix vm concepts. Still programming directly accesses DMA registers and doesn't need any kernel calls.
Try to do that with your GPU!
Darwin, the core of Mac OS X, is open source, for example, as well as Webkit, Apple's browser layout engine used in most browsers today, including Google Chrome and Android. And Grand Central Dispatch. And FaceTime. I could go on.
I won't say that this argument proves much about Apple's attitude towards openness. Webkit is based on KHTML which is LGPL and authorship not residing with Apple, so they absolutely had to open it up to satisfy the license.
The Darwin kernel is based on other free software work (mostly BSD?), BTW. No, the BSD license might not force Apple to open-source it, but it doesn't hurt so much, open-sourcing code that's freely available anyways.
1 picosecond (ps) is 10^(-12) secs. You can run a single instruction in a 1000 GHz CPU (please scale to your favourite multicore system) during 1 ps.
Actually you cannot even run a single instruction during 1ps. Modern CPUs are pipelined and make it look like an instruction takes one cycle. However, between loading of input, processing, and output, ca 20 cycles pass. It's just that with 20 instructions in the pipeline, you might get an effective throughput of 20 instructions per 20 cycles. And this does not even consider cache/memory and i/o access times.
Total I/O latency between signal arriving at PC, and PC answering may well be in the order of many 100 (if not 1000) cycles.
Playing games with ambiguity of the language I used? English grammar "a" is an indefinite article, hinting at a generic statement. Also if you look at the full post you might find sufficient redundancy to resolve any ambiguities.
The more general idea behind this is dynamic programming. If you have an equation of N boolean variables, you can brute force in 2^N. If you have M equations of 2^N variables, where equation share variables only with one or more neighbouring equations, you can determine solutions for every equation on its own in M*2^N steps and save those (partial) solutions. Then to find a solution that satifies all equations you just have to find a "path" through all equations from left to right. That path has M*2^N nodes. The edges of the graph connect solutions that do not collide (i.e. where variables overlapping between solutions take the same value). Since only neighbouring equations overlap in their variables, the number of edges per node is some (not too large) constant. Finding such a path is now straight-forward and polynomial effort. see also here.
So for the riplets in this paper N is 3, so 2^N is a constant, leaving no exponential in the computational cost function. I hoped other people could comment on their impression of the paper, but as this is /. RTFA is not so common I guess :)
This is not a P=NP paper. The paper solves a problem of a related data structure in polynomial time (quartic time), then shows that it can be used to solve some cases of 3SAT. The 3 outputs the algorithm can give are "the formula is not satisfiable", "the formula is satisfiable" (and the solution is given), and "failure of classification" -- it couldn't solve the problem. The important question we wait for on the experts on this paper isn't "is it correct" (it probably is) but "how effective is it".
In fact it does suffice to show that the algorithm determines satisfiability of a 3-SAT instance in polynomial time. Create a derived 3-SAT instance that adds a clause restricting one variable to value '1'. Then see whether it is still satisfiable. It is not? Ok, constrain the variable to '0', and add a constraint for the next variable. Is it now satisfiable? And on and on. You understand the pattern? For n variables it only takes O(n) time to turn the 3-SAT satisfiability testing algorithm into a 3-SAT solver. Or in CS terms: the 3-SAT decision problem is polynomial time reducable to the 3-SAT solving problem.