Lets just be clear what this and the increasing discouragement of cash is really about. It's about preventing capital flight in Liberal Nations whose demographics are collapsing and whose social programs are expanding beyond maintainable scopes.
The FX-8350's have four instruction pipelines and integer units and eight floating point units on the theory most really intensive stuff on the consumer side involves a lot of floating point math. (Video playback and processing, and 3-D dispatch.)
Presumptions in law can be challenged by the introduction of facts to the contrary. Additionally a jury cannot be compelled to accept such a presumption (juries being the last defence of the common sense in the courtroom.) And speaking of law there is additionally case law. "A violation of this section is one offense, which may be proven in different ways. A person's breath alcohol concentration may be probative of impairment under subsection (1), as well as proof of a violation of this section based solely on breath alcohol concentration pursuant to subsection (3). State v. Kubik, 235 Neb. 612, 456 N.W.2d 487 (1990)" The text of the first section of the local DUI law reads "(a) While under the influence of alcoholic liquor or of any drug;" Gives good reason to believe the true meaning of the statute relates only to the influence of external substances.
Assuming the woman really has the condition she claims to have, driving on a flat may still be considered negligent or careless driving, and the condition itself may be grounds to revoke her drivers licences.
Zero is obviously not correct in this case. Null semantics vary by language. Even if writing this in C, you'd want some semantic that would let a database query answer "I don't know that" rather than zero.
"The consequences of an error are too great and modern operating systems are too complex to be made reliable enough."
No, that's not true. Linux, Windows NT, and Darwin/OS X are not reliable enough, but neither is DOS for current standards. You'd be looking at RTOS, QNX, L4 or similar embedded real-rime operating systems that were designed from the ground up for reliability. You could absolutely re-implement these control system and make them better than they were before. The issue is why spend the money to fix what ain't broken?
I think the COBOL stuff that is out there is pretty well nailed down, being in maintenance more for 30 years or so will do that. I would also imagine the mainframe archetecture mitigates some of the vulnerabilities.
Either that or nobody is masochist enough to profile and categorize COBOL bugs.
Low-level software or standard-bearer software like this is a good canidate for MIT, you actually want to able to include it in Windows*, *BSD, and Mac OSX. At one point AMD was considering porting MESA to embedded windows to significantly reduce memory overhead. Why not? there's not a whole lot of incentive to create secret sauce or introduce incompatibilities
How do you even know your software encryption program is actually unmodified and not modified or spied upon by parts of the OS modified to be malicious? Unless you air-gap the computer (and even that sometimes isn't enough (high-frequency listening implanted in the firmware) and keep it in a tamper-evident pouch when you aren't using it? Otherwise you need at minimum you need a verified boot chain and a cryptographically signed file-system. Yes the keys should be owner accessible or replicable, but unfortunately such systems rarely pass the grandma test.
People have extracted key from "secure processors" via hardware probes, but it is very difficult especially on the newest-gen lithography
And the apple model provides more guarantees than that. It layers a pin-derived key and a generated on-chip key at different levels of the file system.
The Secure Boot protocol does not guarantee secure key storage and does not require a specialized chip to implement. It's strongly recommended you rely on hardware mechanisms to verify the firmware, but such mechanisms are distinct feature and the nature of secure boot is that it can't actually verify the firmware on its own. Apple's security coprocessor is similar to a TPM but uses it's own unique API's.
Considering Apple includes a security co-processor it's not actually that easy. Touch ID wrapped keys are discarded after reboot, 48 hrs, or 5 failed attempts. This authentication method can also be disabled or never activated by the user.
Additionaly the root keys are only held in the co-prossesor and co-mingled with a UID (which even apple doesn't know) as well as the password. You can't begin a dictionary or pin attack without pulling out that UID (and cosidering the co-proccessor is running L4, the only way I know to do it is use nano-meter scale probes to spy on the hardware as it operates. The root of the file-system is encrypted by a key held only in the security co-processor, and the comingled password is used in a sort of chain of trust with the hardware key to secure file-metadata and per-file encyprion keys.
The firmware is designed to resist brute force, and apple fixes every known vulnerability to brute-force it discovers. The update mechanism requires the user password and cannot be rolled back to a prior vulnerable version, So apple can't provide a targeted device update to enable brute-forceing. At best the forensic team will have to sit on the device and hope a new vulnerability is discovered, and hope the data erase after 10 failed attempts was not enabled by the user.
The flaws in the WD drives were in the implementation, particularly around key security and key generation. The researchers didn't bother to even try to attack the AES cipher. Why knock in the wall in when the key is laying under the welcome mate?
Hmm, I think Allow?/Deny? isn't suffecient for security. You should be able to Allow?/Deny?/Fake? where fake redirects the API's to fake or random data. The webcam or mike when faked might just be able to access the Rick Roll or Trr La La music or music videos. Contacts might redirect for a list of Congressmen etc.
Even if you can "prove" the software, how do you prove your hardware?
And I think this sort of thing is very hard in a desktop system. Just take private namespaces. Within a single program you can be fairly sure as to what needs access to that data structure, on the desktop it's less sure what a user could want to have access to a particular file. There are server techs with isolate namespaces between services and processes, and there are techs which can fine-tune access of arbitrary executables to files and vice versa, It's just on an open platform that can be configured in an exponential combination what exactly is proper access ex ante.
Slashdot Mirror
I for only welcome our the new hallucinogenic flu season.
There's and 11 month Filibuster coming to a senate near you.
Lets just be clear what this and the increasing discouragement of cash is really about. It's about preventing capital flight in Liberal Nations whose demographics are collapsing and whose social programs are expanding beyond maintainable scopes.
And that's why I have an "R" tattooed on my left hand...
The FX-8350's have four instruction pipelines and integer units and eight floating point units on the theory most really intensive stuff on the consumer side involves a lot of floating point math. (Video playback and processing, and 3-D dispatch.)
There's also Daala in the pipline, which uses entirely new compression techniques that are not patent encumbered.
Client side hashing as a preventative measure?
Presumptions in law can be challenged by the introduction of facts to the contrary. Additionally a jury cannot be compelled to accept such a presumption (juries being the last defence of the common sense in the courtroom.) And speaking of law there is additionally case law. "A violation of this section is one offense, which may be proven in different ways. A person's breath alcohol concentration may be probative of impairment under subsection (1), as well as proof of a violation of this section based solely on breath alcohol concentration pursuant to subsection (3). State v. Kubik, 235 Neb. 612, 456 N.W.2d 487 (1990)" The text of the first section of the local DUI law reads "(a) While under the influence of alcoholic liquor or of any drug;" Gives good reason to believe the true meaning of the statute relates only to the influence of external substances.
Assuming the woman really has the condition she claims to have, driving on a flat may still be considered negligent or careless driving, and the condition itself may be grounds to revoke her drivers licences.
Zero is obviously not correct in this case. Null semantics vary by language. Even if writing this in C, you'd want some semantic that would let a database query answer "I don't know that" rather than zero.
Or strenthen your type system. If you mean false, don't write a zero literal into your code.
There are two kinds of hacker. Those that know Lisp and those that a doomed to re-implement most of it poorly in some other language.
"The consequences of an error are too great and modern operating systems are too complex to be made reliable enough." No, that's not true. Linux, Windows NT, and Darwin/OS X are not reliable enough, but neither is DOS for current standards. You'd be looking at RTOS, QNX, L4 or similar embedded real-rime operating systems that were designed from the ground up for reliability. You could absolutely re-implement these control system and make them better than they were before. The issue is why spend the money to fix what ain't broken?
Ya, when I was digging holes by hand to plant street trees, a recent law school graduate was right there beside me.
I think the COBOL stuff that is out there is pretty well nailed down, being in maintenance more for 30 years or so will do that. I would also imagine the mainframe archetecture mitigates some of the vulnerabilities. Either that or nobody is masochist enough to profile and categorize COBOL bugs.
Because Coffee has too much caffeine :-)
Low-level software or standard-bearer software like this is a good canidate for MIT, you actually want to able to include it in Windows*, *BSD, and Mac OSX. At one point AMD was considering porting MESA to embedded windows to significantly reduce memory overhead. Why not? there's not a whole lot of incentive to create secret sauce or introduce incompatibilities
Couldn't buffers be shared via DMA and PRIME?
How many 128-bit keys can you memorize?
How do you even know your software encryption program is actually unmodified and not modified or spied upon by parts of the OS modified to be malicious? Unless you air-gap the computer (and even that sometimes isn't enough (high-frequency listening implanted in the firmware) and keep it in a tamper-evident pouch when you aren't using it? Otherwise you need at minimum you need a verified boot chain and a cryptographically signed file-system. Yes the keys should be owner accessible or replicable, but unfortunately such systems rarely pass the grandma test.
A few points.
People have extracted key from "secure processors" via hardware probes, but it is very difficult especially on the newest-gen lithography
And the apple model provides more guarantees than that. It layers a pin-derived key and a generated on-chip key at different levels of the file system.
The Secure Boot protocol does not guarantee secure key storage and does not require a specialized chip to implement. It's strongly recommended you rely on hardware mechanisms to verify the firmware, but such mechanisms are distinct feature and the nature of secure boot is that it can't actually verify the firmware on its own. Apple's security coprocessor is similar to a TPM but uses it's own unique API's.
Considering Apple includes a security co-processor it's not actually that easy. Touch ID wrapped keys are discarded after reboot, 48 hrs, or 5 failed attempts. This authentication method can also be disabled or never activated by the user.
Additionaly the root keys are only held in the co-prossesor and co-mingled with a UID (which even apple doesn't know) as well as the password. You can't begin a dictionary or pin attack without pulling out that UID (and cosidering the co-proccessor is running L4, the only way I know to do it is use nano-meter scale probes to spy on the hardware as it operates. The root of the file-system is encrypted by a key held only in the security co-processor, and the comingled password is used in a sort of chain of trust with the hardware key to secure file-metadata and per-file encyprion keys.
The firmware is designed to resist brute force, and apple fixes every known vulnerability to brute-force it discovers. The update mechanism requires the user password and cannot be rolled back to a prior vulnerable version, So apple can't provide a targeted device update to enable brute-forceing. At best the forensic team will have to sit on the device and hope a new vulnerability is discovered, and hope the data erase after 10 failed attempts was not enabled by the user.
https://www.apple.com/business...
The flaws in the WD drives were in the implementation, particularly around key security and key generation. The researchers didn't bother to even try to attack the AES cipher. Why knock in the wall in when the key is laying under the welcome mate?
Hmm, I think Allow?/Deny? isn't suffecient for security. You should be able to Allow?/Deny?/Fake? where fake redirects the API's to fake or random data. The webcam or mike when faked might just be able to access the Rick Roll or Trr La La music or music videos. Contacts might redirect for a list of Congressmen etc.
Even if you can "prove" the software, how do you prove your hardware? And I think this sort of thing is very hard in a desktop system. Just take private namespaces. Within a single program you can be fairly sure as to what needs access to that data structure, on the desktop it's less sure what a user could want to have access to a particular file. There are server techs with isolate namespaces between services and processes, and there are techs which can fine-tune access of arbitrary executables to files and vice versa, It's just on an open platform that can be configured in an exponential combination what exactly is proper access ex ante.
The existing hardware virtualization and security extensions actually let you do this. See L4 as an example.