Security quotes of the week
To address this type of attacker, we present Oblivious DNS (ODNS), which is
a new design of the DNS ecosystem that allows current DNS servers to remain
unchanged and increases privacy for data in motion and at rest. In the ODNS
system, both the client is modified with a local resolver, and there is a
new authoritative name server for .odns. To prevent an eavesdropper from
learning information, the DNS query must be encrypted; the client generates
a request for www.foo.com, generates a session key k, encrypts the
requested domain, and appends the TLD domain .odns, resulting in
{www.foo.com}k.odns. The client forwards this, with the session key
encrypted under the .odns authoritative server’s public key ({k}PK) in the
“Additional Information” record of the DNS query to the recursive resolver,
which then forwards it to the authoritative name server for .odns. The
authoritative server decrypts the session key with his private key, and
then subsequently decrypts the requested domain with the session key. The
authoritative server then forwards the DNS request to the appropriate name
server, acting as a recursive resolver. While the name servers see incoming
DNS requests, they do not know which clients they are coming from;
additionally, an eavesdropper cannot connect a client with her
corresponding DNS queries.
— Oblivious DNS project at Princeton
Up till now, writers of crypto and security software not only have to fight
the bad guys. We also have to deal with compiler writers, who every so
often dream up some new optimisation routine which spots the padding
instructions that we put in to make our crypto algorithms run in constant
time, or the tricks that we use to ensure that sensitive data will be
zeroised when a function returns. All of a sudden some critical code is
optimised away, your code is insecure, and you scramble to figure out how
to outwit the compiler once more.
— Ross
Anderson
So while you’re fighting the enemy in front, the compiler writer is a subversive fifth column in your rear.
Last year, the Defcon hackers' conference sponsored
[PDF] a Voting
Village. Organizers collected 25 pieces of voting equipment, including
voting machines and electronic poll books. By the end of the weekend,
conference attendees had found ways to compromise every piece of test
equipment: to load malicious software, compromise vote tallies and audit
logs, or cause equipment to fail.
— Bruce
SchneierIt's important to understand that these were not well-funded nation-state attackers. These were not even academics who had been studying the problem for weeks. These were bored hackers, with no experience with voting machines, playing around between parties one weekend.
