There are problems with paper voting as well.

oldest trick:
- bad buy gets a blank vote page, somehow.
- bad guys marks the page as he wants, then gives it to voting guy.
- voting guy goes to vote, puts the already marked vote in the box, carries out the new blank vote page.

Loop and repeat.

Or while counting the votes, if a city is expected to have an heavy turnout for the wrong candidate, if you can manage to sneak in a bad guy as the one who parses the ballots, he can have a small piece of pencil under the nails, and use it to erase "wrong" votes or "complete" blank ballots.
It requires more skill, maybe a couple of them working together, but there are lots of money in an election, so finding the skilled people might not be that impossible.

At the end, you only have to decide what to trust, the computer programs or the people.

--

IMHO, we need to harden the paper balloting. It's easier to harden, more expensive to fool and you can't fool it "globally" but only locally.

Either that, or provide proofs of correctness and verifiability to everyone, for all computers involved. Kinda harder, although more awesome for us hackers.

26th Chaos Communication Congress, 2009:
http://media.ccc.de/browse/congress/2009/26c3-3654-en-gsm_srsly.html

It is already well known that you can break A5/1 offline anytime you want, and at the 26th CCC there was the "GSM: SRSLY?" conference which outlined the 2 main problems of GSM and UMTS.
GSM A5/1 can be broken (and the give plenty of details), but it is not used in UMTS. No worries, for UMTS you just need a fake station and you are set. No offline decoding though.

So your solution is?
not using anything 'cause the NSA is over you?

Saying that the CA system and the DNS(SEC) infrastructure are the same is retarded.
The CA system is managed by hundred of companies, and you can not possibly know if some company as an unauthorized certificate.
Want to know if someone is giving false information on DNSSEC? "dig domainname + dnssec" should be enough....

The current (DNSSEC) system has problems, but it is not as rotten as not having anything, so it's better than nothing. Please stop denigrating it to such an extent

I can understand RC4.

I can understand MD5.

But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud...
maybe a less if you have you own supercomputer, but even at $1M it sound a lot...

So why warn away from SHA1 NOW? what are we going to use? md5? md4? remember that while keccak was chosen as the SHA3, they still have to release the complete details on how it must be implemented -- number of rounds and such -- so SHA3 *NOW* is not an option.

I'll start taking microsoft seriously on this once they phase out MD4, RC4, MD5 from their existing standards and products.

The Internet is a tool, subject to the human will and policies.

"eradicating disease" is instead long, constant process that requires multiple tools, innovation and people.
It also already has an objective (saving people's lifes).

So, we are comparing a mere object with no specific objective to a long, evolving process with a specific goals...

Color me unimpressed.
But even "eradicating disease" per se doesn't save the world, first because "the world" is not "the people", and because having the cure doesn't mean that you are willing to distribute it freely or at accessible costs.

So, to sum it up... the right policies will save the world?

I had a quick look at the website, and can't find any low-level detail, just a lot of pictures...

That said, he seems to use HTTPS/SSH and certificate-based access.
It is useless to sign the certificates, since we are in a lan, not on the internet, and I doubt your house devices will have a full dns name...

I'm more interested in the packet structure and to the data format, as it always gives more insight on the protocol that big, colored images...
Its said to use websockets, but I doubt that will be the case in SSH-based access.
There seems to be the option to use UDP multicast for the sensors..

The HTTP traffic is exchanged via websockets and json... This is nice, since the programmers can use all the http server/client and json libraries they want, and it usually is fairly simple.... BUT we are talking about home automation, arduino boards and in general "things" with very little computational power/memory etc...
I really don't understand why we want all on HTTP, the efficiency is very low and now you require an HTTP server and client to communicate with something just to flip a switch...

Maybe if SNMP was done the right way, without OIDs and security from the start we would not need this, but I digress...

I don't like the fact that there seem to be a lot of new definitions... apprentices, stewards, and ... "things"... couldn't dumb it down more even if he tried -.-''

But the nice thing is that it seems to be able to include 3rd-party modules and protocols fairly easily... Which IMHO is not a small thing and can in fact help this protocol a lot.
And whatever he does, he can't do as badly as DPWS. If he manages to make it general enough we might even put an end to the horror that is DPWS and WS-* standards....

But since you have so many people to check, doesn't that mean that they are going to make a massive use of automation to do the checks?

Remember how good the spamfilters are? And they are designed against something extremely frequent

Now remember how infrequent a terrorist attack is? And what about that False positive paradox?

It's not about feeling special or not, it's just the the system is broken by design... and the algorithms are surely perfect...

No worries, X.509 are big and bulky, and the management of the certificates authorities kinda sucks anyway.

Nah, I don't use X.509, but the trust model is granted and secure. And bonus points: its free of charge and already existing :)

Good luck with that, it's not like I'm in the U.S.A., and once the project goes public, I doubt you can really influence it without people noticing. :)

Also, as with everything working with encryption, you need a way to distribute keys, a "trust model". And the trust model will not be too different from todays X.509 certificates, so the NSA might still be able to compromise the trust of this protocol (assuming that the NSA has compromised the trust model in X.509 certificate handling).

Still, with my new protocol you should be able to know if someone is compromising the basic trust model, so some protection might be applied...

Cheers,
Lk

Working on it for my master thesis ;)
Just a "Schneier Suite" would be limiting, though. We need more than just the basic algorithms, and not only from Schneier.

Anyway, I'm developing a new transport/encryption/authentication/federated protocol, which combines ideas from SSL, Kerberos and a lot more, plus some new...
I already have written all the specification, I'm starting to code it now.

Keep your ears open for the "Fenrir" project, I'll probably release something in 3-4 months... Although the stable release will probably wait until I finish my master, around July-October '14... 'sorry for the wait, but I have other things to study, too :(

And yeah, all opensource, a mix of apache2 for the main library and GPL for the auth daemon...

Lk

has anyone bothered looking at the benchmarks? The overall system power consumption when games were run was 20watts for AMD and 35watts for the Core i3.
To my calculation, that's a 75% more power consumption then AMD. Intel hardly "matches" anything...

AMD was still at least 3 watts less power hungry in any other benchmark, too...

Just tried it, *very* easy to use....maybe a little slow...

now, if only I could save my changes... they seem to have a couple of problems with OAuth (if you already have an account and use it for the first time)

fscking OAuth... worst protocol ever...

Just do like the LHC does. filter things at multiple levels, and this is doable for telephones.

You don't really need *all* the data.
Data coming from public terminals might be important, data coming from common houses might be less important as people are afraid of being found out..

Or watch for call-loops. A circle of calls where A calls B, then B calls C and C calls A might be suspicious. bonus points for watched numbers.
Or a series of quick calls from someone, or a chain of quick calls...
filter out calls between families, or between companies... depends on what you're searching..

Or just keep all the data for a week, and if no one collects it, and the algorithms do not signal anything, then discard the old one to make space..

There are a lot of possible ways to analyze all our voice/text data..

If we talk about Internet traffic, then you could optimize thing a little, for example discard content from youtube, BBC, as they already log everything, keep 4chan... there's a lot more data, but profiling helps a lot.
It's not the same as "everything", but if you ask me, it's damn close... and doable....

just my 0.02$

I tried btrfs as my main laptop filesystem:

nice features, speed ok, but i happened to unplug by mistake the power supply, without a battery. bad crash... I tried using btrfsck, and other debug tools, even in the "dangerdon'teveruse" git branch, they just segfaulted. at the end my filesystem was unrecoverable, I used btrfs-restore, only to find out that 90% of my files had been truncated to 0... even files i didn't use for months....

now, maybe it was the compress=lzo option, or maybe I played a little too much with the repair tools (possible), but untill btrfs can sustain power drops without problems, and the repair tools at least do not segfault, I won't use it for my main filesystem...

btrfs is supposed to save a consistent state every 30 seconds, so I don't understand how I messed up that bad.... maybe the superblock was gone and the btrfsck --repair borked everything, I don't know.... luckily for me: backups :)

we had a similar problem in Italy. basically the new electricity meters were infrared-accessibile. password protected, of course. no need to hack anything trough, just use '0000', '1234' or '3635' ("enel as written with a cellphone, it's the company name). ta-da! full access. so what did we do? nothing. but we're in italy after all...