Some of us build hardware and need to write device drivers. Cutting through the cruft is exceedingly useful to those of us that want to get the device to work.
>QUIC QUIC. Thank you. I had forgotten the name and was too lazy to look it up.
>But an SSL extension where the client indicates what name it seeks should do. It would function for web servers, but there's a more general problem and this falls under it. We use TLS for everything. To protect privacy, credit card transactions, instruction authenticity "sell all my stocks!" and any number of other things that are presumed to be secure because they are over TLS. I want to see a transition to lots of little, simple, easy to implement security protocols, one for each purpose. A web page security protocol. A payment security protocol. A timed assertion protocol etc. So we don't have to trust in the one true PKI for everything. We can shrink the trust boundary to just the interacting entities.
Something of a pipe dream, but the "Nuke TLS from Orbit" crowd is getting some traction these days.
>My own opinion HTTP 2.0 is only a marginal improvement with no particular pressing need... I think they should think hard and add something cool to it.. make me want to care...as is I'm not impressed.
Alright, lets propose some stuff
(1) HTTP runs over TCP, This is stupid. An unbracketed stream protocol for serving blobs of data and protocol messages is wrong and has promoted abhorrent things like REST. Lets go use a reliable datagram transport with a persistent session that can be bound 1:1 with the security session. Then both ends can keep per-session state and the life of programmers gets easier. (2) HTTP over TLS is stupid. TLS is a machine to machine protocol, not a web client to web server protocol. Lets use a security protocol that is designed to secure the datagram-HTTP mentioned in (1). Then perhaps, the server would know which cert to cough up for which web site, which today it does not, because TLS only authenticates the server not the (virtual) web site. (3) MITM is a primary problem. Authenticate both ends. If x509+PKI+TLS isn't working (it isn't) lets do something else. How about everything defaults to self signed and we build an certification/attestation layer on top to declare which of the self signed certs correspond to which entities. You could even do it web-of-trust style to limit the single-point-of-failure issues with conventional PKI.
Microcontrollers come in many shapes and sizes. There's a whole spectrum of devices between MPS430s and ARM7TMDIs.
I personally like the Siemens 80C166 or one of the many 68k derivatives. Simple, lots of IO and robust. Young whippersnappers might choose AVRs 68HC16s or similar things for the same reasons.
But an x86 micro that can run DoS has the obvious advantage that it can run DoS. That addresses a number of issues,
I think the legitimate issue with floppy disks is the reliability of the medium and the long term availability of replacements.
Writing a floppy driver for hardware that has a floppy disk controller chip is easy. Writing one that has to bit bang the interface is anything but simple.
A USB driver is a lot more complex than a 3.5" floppy disk driver.
PCMCIA/CF is pretty simple. If I was doing custom hardware, I would use that. Off the shelf cards. Simple bus operations. Many microcontrollers can drive the bus directly.
DOS is still a reasonable choice. It works, isn't complex and there's lots of off the shelf hardware that runs it.
>The fault appeared in the system despite the fact that the application was especially developed for these elections, was "tested thousands of times" and was certified by PriceWaterhouseCoopers, he said.
Slashdot Mirror
It blocks ROP. So it is an effective way of preventing an primary attack vector.
It's not a defense against resident malware.
Trojans are already doing live randomization. But ROP attacks like predictable software so the attack can be developed offline.
He doesn't have the pointy hair necessary to manage the project
Personally I welcome all our robot overlords who buggered off to mars. Oh wait.
Take it a badge of honour.
Some of us build hardware and need to write device drivers.
Cutting through the cruft is exceedingly useful to those of us that want to get the device to work.
>QUIC
QUIC. Thank you. I had forgotten the name and was too lazy to look it up.
>But an SSL extension where the client indicates what name it seeks should do.
It would function for web servers, but there's a more general problem and this falls under it. We use TLS for everything. To protect privacy, credit card transactions, instruction authenticity "sell all my stocks!" and any number of other things that are presumed to be secure because they are over TLS.
I want to see a transition to lots of little, simple, easy to implement security protocols, one for each purpose. A web page security protocol. A payment security protocol. A timed assertion protocol etc. So we don't have to trust in the one true PKI for everything. We can shrink the trust boundary to just the interacting entities.
Something of a pipe dream, but the "Nuke TLS from Orbit" crowd is getting some traction these days.
(3) I'll get coding :)
Yes. Discredit the voting machines. Go back to paper and pencil.
>My own opinion HTTP 2.0 is only a marginal improvement with no particular pressing need... I think they should think hard and add something cool to it.. make me want to care...as is I'm not impressed.
Alright, lets propose some stuff
(1) HTTP runs over TCP, This is stupid. An unbracketed stream protocol for serving blobs of data and protocol messages is wrong and has promoted abhorrent things like REST. Lets go use a reliable datagram transport with a persistent session that can be bound 1:1 with the security session. Then both ends can keep per-session state and the life of programmers gets easier.
(2) HTTP over TLS is stupid. TLS is a machine to machine protocol, not a web client to web server protocol. Lets use a security protocol that is designed to secure the datagram-HTTP mentioned in (1). Then perhaps, the server would know which cert to cough up for which web site, which today it does not, because TLS only authenticates the server not the (virtual) web site.
(3) MITM is a primary problem. Authenticate both ends. If x509+PKI+TLS isn't working (it isn't) lets do something else. How about everything defaults to self signed and we build an certification/attestation layer on top to declare which of the self signed certs correspond to which entities. You could even do it web-of-trust style to limit the single-point-of-failure issues with conventional PKI.
>To get the "secure" behavior you need to use https, which has mandatory authentication.
You are wrong on many levels. Please understand cryptography and secure protocol design before you post.
Microcontrollers come in many shapes and sizes. There's a whole spectrum of devices between MPS430s and ARM7TMDIs.
I personally like the Siemens 80C166 or one of the many 68k derivatives. Simple, lots of IO and robust. Young whippersnappers might choose AVRs 68HC16s or similar things for the same reasons.
But an x86 micro that can run DoS has the obvious advantage that it can run DoS. That addresses a number of issues,
Where did 4K of code come from?
I would expect to use a micro that can address enough memory for the job to be done right.
Who mentioned Arduinos? It wasn't me.
Citation please. This is the first I've heard of such a thing.
> So you can read and write to an SD card, you just can't run code off it.
That seems like a good thing for a voting machine.
I think the legitimate issue with floppy disks is the reliability of the medium and the long term availability of replacements.
Writing a floppy driver for hardware that has a floppy disk controller chip is easy. Writing one that has to bit bang the interface is anything but simple.
A USB driver is a lot more complex than a 3.5" floppy disk driver.
PCMCIA/CF is pretty simple. If I was doing custom hardware, I would use that. Off the shelf cards. Simple bus operations. Many microcontrollers can drive the bus directly.
DOS is still a reasonable choice. It works, isn't complex and there's lots of off the shelf hardware that runs it.
Because writing the 3.5" floppy driver would suck.
>The fault appeared in the system despite the fact that the application was especially developed for these elections, was "tested thousands of times" and was certified by PriceWaterhouseCoopers, he said.
There's your problem
>Unfortunately, in the case of a lot of point of sale systems, the acronym does double duty. At least they are surprisingly expensive.
I wrote a POS for my wife's yarn store. I named it the "POSPOS".
dipshits
Waiter! Can I get this without the bing?
>I've been using computers for over 30 years and have never once used this keystroke.
Indeed. I've typed :w several times today.
So where are all the atheist terrorists?
There are plenty of religious terrorists and plenty of wars that wouldn't have happened if it wasn't for religion.
Here you go:
http://godandwar.wikispaces.co...
Do you have data to back that up?
You are being part of the problem.