Forgot your password?
typodupeerror

Comment: Reason to use end-to-end encryption (Score 3, Informative) 21

Add this as reason #2'175 on the long list of why one should definitely use end-to-end encryption.

If you use a well designed end-to-end encryption, that has been validated by cryptologist (think OTR for chat, ZRTP for voice), I doesn't matter what the quality of the underlying link is or if telcos are helping breaking the link.

Best part? These technology can work over your already existing systems (though ZRTP can't work over Skype's voice and video. It only works over SIP or XMPP/Jingle - i.e.: the standards that the whole rest of the internet is using).
So you can OTR encrypt your chats over your Google Talk's XMPP session.

And there are clients supporting them either out-of-the-box (jitsi, adium) or with a plugin (pidgin), over your existing accounts (XMPP like Google Talk, or any random SIP provider).

Comment: comprehension fault (Score 1) 374

by DrYak (#46830959) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

Okay perhaps I've misinterpreted the initial state.

I've understood it as "Heartbleed is an exemple of bug provoked by their malloc replacement"
(which is wrong. heartbleed is caused by a buffer overrun in an unchecked pointer manipulation. malloc isn't the cause).

Not as "the investigation of the heartbleed bug has showed that their malloc replacement is bad"
(which is indeed correct: their malloc replacement prevents using secure feature that would be able to detect problems like heartbleed. In "openssl valhalla rampage"'s own terms they have "exploit mitigiation"-mitigiations.)

Comment: Boundchecking (Score 1) 374

by DrYak (#46830937) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

Yup, that is indeed what's missing inside something like openssl.
Throw in a secure compare in way that doesn't cause confusion (i.e.: avoid's openssl's CRYPTO_memcmp vs OPENSSL_memcmp. If you really need the later, call it something unambiguous like "leaky_memcmp"), and bound checked substring copy, and you have basically covered all needs of a crypto library.

Comment: Correct tool for the job (Score 1) 285

by DrYak (#46801663) Attached to: Apache OpenOffice Reaches 100 Million Downloads. Now What?

Switching from MS Office to OpenOffice / LibreOffice is not easy at all for power users. To put into geek terms: imagine switching from Apache to Lighttpd. For most things, it will be great. But, if you have some serious .htaccess magic going on or are relying on mods which exist only for Apache - well, you are out of luck and you are probably not going anywhere.

If you rely on that much complicated Excel Spreadsheet, you'll have to wonder if you're using the correct tool for the job.
I'm not dismissing that fact that LibreOffice would need better import/export capabilities with more compatibile exchange with Microsoft Excel. (that needs to be done anyway).

But if you push Excel to its edge, maybe instead you should consider switching your workflow to a package/software suite which is more geared to your data analysis and plotting needs. (things like statistical software, for example)

Comment: Auditing (Score 1) 374

by DrYak (#46801001) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

What annoys me is that - with all due respect - the companies which embed openssl in their products could have done a review of the code for quality.

According to TFA (or even the summary), that's actually the whole point of this:
OpenSSL is currently an over complicated tangled ball of mess (though in small part this is due to the contrived SSL standard itself).
Doing code reviews on this kind of monster would be really difficult, even for a wiling company.

The point of this mass commits is to make openssl much simplier, by stripping out useless/corner case/deprecated code, and produce something whose code review could finally be within the reach of non cybernetically-augmented human being.

these 250 commits are only phase 1 of the project. phase 2 is actually doing the code review itself.

Comment: Heartbleed != malloc (Score 2) 374

by DrYak (#46800911) Attached to: OpenSSL Cleanup: Hundreds of Commits In a Week

hearbeats just exposed their faulty malloc replacement.

Heartbleed had nothing to do with their malloc replacement (at least not directly [*] ).
Heartbleed is just a very basic case of missing nested bound checking. (They check bounds for the heartbeat request it self, but fail to check is the super structure containing the hearthbeet - i.e.: the packet - passes the bound checks too. XKCD's explanation is actually spot-on: it's more or less equivalent to forgetting to check if the requested number of caracter doesn't exceed the size of the speachbubble).

This is not caused, by memory allocation system. This is caused by several factor, among which the fact that heartbeat are a very stupid design to begin with.
(Reasons:
- there are already other better way to keep a connection alive
- totally free payload and payload-size are a bad idea (why not simply use a fixed size 32 or 64 bits ID) ?
- specifying the payload's size is stupid, because there's already a size limit: the packet itself. Now instead there are 2 sizes to check and such redundant work often leads to errors as it happened with heartbleed)
But TLS/SSL are very convoluted, to the point that someone might ask if these standards aren't designed on purpose so someone could fuck them up. It's almost a long series of "exploit-bait" engineered into standards.

---

[*] : instead of concentrating on replacing malloc, they could concentrate on replacing another part, namely designing buffer-types that contain buffer-size and are automatically bound-checked.
So heartbleed has something to do with their in-house memory management, in that they lost the opportunity to bake automatic bound checking into their custom memory manager.

Comment: Founding Father and Direct Democracy (Score 1) 816

by DrYak (#46777691) Attached to: Study Finds US Is an Oligarchy, Not a Democracy

There are reasons why the Founding Fathers rejected direct democracy.

First, they wouldn't see how a direct democracy (i.e.: where everybody decides and vote about everything) could scale on a larger scale than classical Greek city-states and small communities. (Where the dozen, maybe hunderd of decision-making citizen simply gather and discuss together).
Their solution back then was instead to keep the Greek city-state model (have a small bunch of people gather together) except that each one of the gathering people is representative of whole regions/populations/etc. (instead of managing to gather every single person of the huge population in a town's central plazza).
Thus was birthed representative democracy.
It might have sounded good back then, but you see the effect now: the representatives tend to prefer representing whomever pays them the best. Power is back in the hand of the elite and big corporation, only with a thick political layer inbetween.

Well technology marshes on, since founding father, communication technologies have simply been on a constant growth. A rather explosive growth.
Thus later on, you can see whole countries like Switzerland that function on a direct democracy. They have moved on from "Landsgemeinde" (the Hlevetic equivalent of greek city-state gathering in the central place) to direct voting accross the whole country, both in election booth and with voting-by-post.
So even if switzerland is bigger than a greek city-state (currently more than 7m people), thanks to the modernization that existed back then (post & phone & railroad) it has since then been able to coordinate country-wide votation and election very regularily (every few months).
The process is completely open and any one can watch and check.

Now Switzerland is still smaller than other European country or even huge continent-sized countris (like USA, Russia or China, for exemple). But, guess what, technology is STILL marching on and has come up with things like internet and cryptology.
(These are already put into production in some parts of Switzerland. Mainly for expatriate and in a few small commune).
And with these technologies, direct democracy can even scale up to larger populations.

The fear of your founding father about democracy being not practical on anything but smaller greek city-state is simply deprecated by technology.

Other fears against direct democracy usually include that people are stupid and might react stupidly due to mass panic, or because they are selfish and only think about quick personnal profit. Imagine if one would vote about a law for definitely supressing any tax however. People will never vote for tax! The state will go bankrupt!
Politicans know better, let's have them take the actual decision, and have only people voting for politician based on approximate general tendency of them.

Well you've seen the result in TFA's study: Politicians do know better, they specially know better how to earn more money by abiding to the highest paying oligarch.

Meanwhile, direct democracies like Switzerland DO VOTE about taxes, and guess what, big surprise: THEY HAVE VOTED FOR TAX INCREASES, SEVERAL TIME.

Thinking that "sheple don't know, politicians know better" is a horribly condescending paternalistic approach.
Yes, voting blunder can sometime happen (see votation about Minarets, about life-sentences or, more recently, the problems between EU and Switzerland regarding migration freedoms). But they can be mitigiated. At the heart, the main problem is information, if "people don't know" perhaps, instead of deciding for them, you might try to inform them so they make an enlightened decision? Modern communication mean can do help a lot here. Mass media like Press, Radio, TV have been around for decades. Internet is newer and offers even more possibilities for communication (including for minorities which might lack the budget to do it on Mass Media).
Also, patience and time help. People new to Swiss politics might wonder that everything is so slow. Well, it helps staying calm and thinking a bit, and nut rush some policies in a hurry. All the various checks and controls help to diminish the risk that some law is enacted due to mass panic (see you Patriot Act). In Switzerland, it has often happened that a people's motion has been submitted regarding a pressing problem, and by the time it goes through the pipeline, politics had time to adjust and propose a better, "less stupid beause I react" proposition to submit during the same vote. It has often happened that the people committee asking for the vote retract their own proposition because they find the new one better and people only end up voting for/against the one by the state.
And there are also internal checks, Switzerland is a signatory of the human rights convention and other similar international treaties. If any new law is deemed to contradict such international law, the new law can't be enacted (see Switzerland's voting blunder about life-sentences).
Meanwhile, USA has such wonders as Patriot Act, DMCA, etc. law that clearly only profit the corporations or organisation which paid the representative for.

Comment: Two rounds mandatory (Score 1) 816

by DrYak (#46777471) Attached to: Study Finds US Is an Oligarchy, Not a Democracy

With the advent of the internet, voting could be done online, and most people could do it at home (and those who cannot afford or do not own a computer could use public computers set up at their local town hall where they vote now).

Voting IS done online. Currently not enabled everywhere. But's that already a possibility for swiss people abroad, and some comune start to enable it locally too.

The president can be the candidate with the purely majority vote.

Due to Duverger's Law, when there's a single voting round for a single key position (or for a single exclusive composition of a group), system will inevitably degenerate into a bi-partisan mess (see USA), because voting for a less popular 3rd party ends up being "throwing your vote away". And that sucks because usually the two finalist end up being always opposing each other while not doing much useful actually (again see USA).

One solution is to introduce 2-rounds voting (as in France): this dissociates the "trying to support an interesting 3rd party" and "voting against the bigger evil candidate" into 2 separate rounds. You don't "waste a vote" by casting for a 3rd party, you'll have plenty of opportunity to vote for the lesser evil on the next round.

Meanwhile, here in switzerland, the top of the executive is held by a *group of 7 persons* (with "president" being a simply honorific title for protocol purpose passed around in a circle each year). It's a group of person of mixed partisanship.
Currently, that's the only indirect voting system in switzerland (citizen vote for parliament, which is of proprotionnal composition, and the parliament functions as a "electoral college" by electing a similarily proportionned group of 7). But there's no major problems into introducing direct election. (People directly vote for parties and presidential candidate. Group proportion is based on party votes, and then places are populated by candidates based on popularity within party).

Comment: No monoculture (Score 1) 582

by DrYak (#46765895) Attached to: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?

OpenSSL has no competition at its core competency, so the team really has no motivation to deliver an iteratively better product, apart from their need to scratch an itch. FLOSS software projects tend not to operate in a competitive environment, where multiple OSS products are useful for the same thing and vie for placement. This is probably bad.

I definitely don't agree.
Take any rant against FLOSS, the first thing you'll hear is complaints about "too much choices to pick from".
Sorry, but you can both complain that there's too much choice (hard on the user) and at the same time not enough choice (hard on security).

In the case of encryption, OpenSSL is far from the only present library. Its IS indeed very popular, but it's not the only used library.

GnuTLS is another popular library, which wasn't affected by Heartbleed (not specifically by this bug. It's not without problems, but still).

Mozilla's NSS seem popular with browsers (Firefox and Chrome use it, probably others too -and not only browsers: Pidgin uses it too). Again a different library, popular too

And that's just he major libraries. Then there are ton of others to chose from.

Some written in higher level language (Botan is in C++) and some (I hope, I haven't tested them all) probably using some facilities to abstract away a few pitfall like buffer lengths.

Comment: Reaction (Score 1) 180

I would also say that everyone has limits. Backing individuals into impossible situations passive aggressively is something that modern society has become very good at.

...and then, there's the different ways that an individual will react and cope once the limits are broken.

To take the current subject: Video games.

Some will react violently to furstration, and angrily throw their controler accros the room.
Other will simply go "meh", consider the "unwinnable game" uninteresting and move onto something and not even mind.

Same could apply to lots of other situations in life.
Some people will just go mad. Other will just chose to ignore and move to something else.

Comment: Or... use better tools (Score 1) 446

by DrYak (#46752409) Attached to: Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

The process of dissolving a big problem into low-level steps as is required by C programming is mentally brutal. You can't just go "I want to save the text that was deleted and restore it when they hit the undo key." You have to translate that into variables, pointers, structs, mallocs, and glue logic.

Or you could use some tools which abstract away this problems.
- you could use a high level language where some of this porblems don't exist (e.g.: no pointers, and automatic garbage collection).
- or you could stay within the C/C++ world and write wrappers that take care to check everything (for example, almost any moderne tool-kit [Qt, Boost, or even default C++'s std++] will define type that are bound checked automatically [QByteArray or std::string] and smart pointers.
- some of these could even by implemented in plain C.
(But full implementation might require some Macro-ugliness. GTK+-level of ugliness)

Done correctly, such tool can automate the taking care of corner cases that can break the system.

But instead some programmer still decide to use as a simpler syntax for assembler and do everything bare-metal.

In case of OpenSSL, I'm a bit surprised. It has so many helper functions, but nobody has bothered yet to implement buffers with buffer-size checking safetey.

Comment: Niche case hardware (Score 1) 641

by DrYak (#46700871) Attached to: Meet the Diehards Who Refuse To Move On From Windows XP

I might surprise you, but such kind of legacy hardware is so common, that there are hardware manufacturer specialising into making motherboards for such niche case.

You can even find motherboard that can use modern processors (Intel Core 2 and/or more recent) but still have ISA slots.

You can even manage to install MS-DOS or old Win9x on them.

So you can be sure that, 10 year from now, you'll still be able to buy brand-new hardware able to run WinXP so you can still use your legacy hardware. It will be expensive, and will come from some specialist brands, but it will still be possible.

(As an anecdote, we had to install Win98 on a ISA-slot-sporting modern motherboard because of a lab measuring equipment - a calorimeter - that relied on a pair of ISA DAC cards with MS-DOS TSR-drivers. The original computer got fried, but given the extreme price of the equipement, it was cheaper to build such a new custom computer than buying newer equipment)

Comment: Yes and no (Score 1) 75

by DrYak (#46629445) Attached to: DVRs Used To Attack Synology Disk Stations and Mine Bitcoin

Is there a mechanism built into the bitcoin structure that allows for this and voids the coins?

Is there a mechanism built into hard cash that allows to void the silvercoins/bank bills to be remotely voided? No.
And basically any cryptocurrency works the same. There's by definition NO SINGLE ENTITY in control of the bitcoin protocol (that's the whole point of it).
so nobody could remotely void any coin. (but at least that means that legally earned crypto-mony won't suddenly vanish neither... no fraudulous chargebacks on the bitcoin network)

On the other hand, cryptocurrencies aren't anonymous. At all. In fact they are (again by definition) the exact opposite: every signle transaction is broadcasted to the whole network. That really helps the security (thus every single node on the network can check and verify all transaction) without needs for a central authority (see previous point). But that also means that anyone can follow transaction a follow money jumping from one public key to another.

As the blackhats aren't probably mining actual bitcoins, but some minor alt-coins which is much more mine-able on CPUs, at some point, they'll need to exchange it for something more easily spendable. So they need to send them to one of the (few) exchanges accepting less known coins (Probably cryptsy).
Law forces could collaborate with exchanges and try to catch transaction whose coins can all be traced back to the initial mining by this botnet.
Then it's a matter of matching transaction with profiles registered at the exchange or further following the money trail.

Comment: Probably *NOT* bitcoins (Score 1) 75

by DrYak (#46629369) Attached to: DVRs Used To Attack Synology Disk Stations and Mine Bitcoin

As I've mentionned above, it's probably NOT bitcoins being mined.
The last few article on /. mentioning mining malware, all said "bitcoin mining" when careful reading showed up that in fact the malware didn't mine bitcoins but another cryptocurrency better suited for CPU (one of the latest I remember was PTShares).
Reporter just say "bitcoin mining" because that's the only thing they know and they vaguely remember that creating bitcoins was something CPU intensive.

If the black-hats are smart enough to think this contrived way to infect the synology (infect first the "always on internet" DVR and only then, once you're on the other side of the firewall, start scanning the home intra-net for NAS hidden behind the firewall), perhaps they are also able to pick a CpU worthy (ie.: not SHA-256^2 based) cryptocurrency coin.

Even free-as-in-stolen, you're telling me that the best use somebody can think of for a botnet of network attached storage devices is generating maybe as many hashes as one of those cheapo USB-stick ASICs, rather than, say, basking in juicy private data and massive stolen storage space?

While you're at it, it's best to take as much opportunity as possible.
- you can "safely" mine on a nas, because the clueless user won't notice a heavily degraded performance (unlike on their desktop).
- you can pick-up a coin which won't be beaten by cheapo USB ASICs: math based coins (like PrimeCoin, RieCoin, etc.) are still mined on CPUs. SHA3 based coins (CopperLark, QuarkCoin, etc) don't have an efficient GPU implementation yet. SCrypt-based coins are some memory-intensive, that the jump between hardware generations doesn't yield such a strong difference in hash rate: even if the current mining is mostly done on GPU and some early experimental FPGA, high-end server CPU can still give Litecoin for their run. (so even if the ARM inside NAS isn't that powerful, a whole botnet mining Litecoin could still earn some money back).

And last but not least:
- that the worm download a payload for mining bitcoins, doesn't prevent the the worm to also download a payload for scanning credit-cards numbers, SSN, naked photos, etc.
So don't despair, the massive stolen storage space will also be juiced for all it's worth.

The coin-mining at least is low bandwidth, and it's possible for the blackhats to check if their plan is working just by looking at the income on the cryptocurrency address used for mining. Scanning the stolen storage space would be much more bandwidth intensive (the victim would notice that "their internet has become slow").

On the other hand, getting that money out of the botnet and into the black-hat's pockets is going to be tough:
cryptocurrency aren't anonymous. in fact they work based on the exact opposite: every single transaction is boardcaster to the whole network. While this provide good security against counterfeit wiithout needing a central authority (the whole point of the bitcoin protocole), that also means that anyone can follow the transaction following this mining.
If the hackers indeed used a rare CPU-based coin, that means that they can't do much except exchange it on one of the few major exchange which accepts even very minor coins (like cryptsy). That means it's rather easy for law forces to collaborate with cryptsy to try and catch any transaction with coins coming from this mining- then it's just a question of matching this transaction with user profiles and/or follow the money trail further.

Comment: "Bitcoin": Error in reporting? (Score 3, Informative) 75

by DrYak (#46629167) Attached to: DVRs Used To Attack Synology Disk Stations and Mine Bitcoin

That might also be an error in reporting: TFA's Author might have written "bitcoin mining" (for lack of understanding the whole alt-coin ecosystem) when it would be best described as "cryptocurrency miner".
The last few article on /. mentioning mining malware, all said "bitcoin mining" when careful reading showed up that in fact the malware didn't mine bitcoins but another cryptocurrency better suited for CPU (one of the latest I remember was PTShares).
Reporter just say "bitcoin mining" because that's the only thing they know and they vaguely remember that creating bitcoins was something CPU intensive.

The black-hats creating sophisticated malware (a worm, infecting vulnerable connected DVR, so they in turn can attack Synology NAS and launch mining software) aren't probably stupid enough to mine bitcoin, they probably know better, and the miner is for whatever is the current most CPU-worthy (i.e.: non SHA-256^2 baesd) cryptocurrency-coin.

"If that makes any sense to you, you have a big problem." -- C. Durance, Computer Science 234

Working...