It is. Together with progressive delays going up to years after failed tries. The designers of this thing are not stupid, the occasional mess-up (antenna-gate, e.g.) non-withstanding.
Then neither side would make this public as these would need to be kept secret at this time. No, this is the FBI trying to call Apples bluff. Thing is, I think it is not a bluff at all. Oh, sure, if you throw, say, 100 Million and 10 really capable people at the problem, they would get the phone open and it may even take less than a year. But the FBI cannot legally order Apple to spend that effort.
In any case, it will be very interesting so see how this unfolds. I predict Apple is going to win and we all will have a better world for it.
Well, the systemd-crowd is the one in the corner, the others have something like 10 alternatives and do believe in choice, unlike you people. I to understand the hyper-aggressive emotional campaign for systemd though: You people have literally burned all bridges and claimed that your tool is the only one that promises eternal life and happiness. Of course, after such a fanatical entry onto the stage, even admitting a tiny bit that things may not be as clear-cut is something you cannot do anymore without looking like complete idiots.
No. This is not on the amateur-level you describe. True, much "security" is on the level you describe, but this is a secure microcontroller. Give it exactly what it expects or fail 10 times and it will nuke its key-storage using power from internal and well-protected capacitors.
Brute forcing BPKDF2 is easy in comparison to what he wants. This is about breaking a secure microcontroller. A few orders of magnitude harder and pure software-attacks will very likely not work.
They would need to image the secure microcontroller holding the key. That is a bit harder. Might take a few years of research by some really bright people and some really expensive equipment.
No. They need to pull the encryption-keys from a secure microcontroller. If you can throw a lot of money and time at the problem, that is doable. To get an idea, I recommend "Hacking the Xbox" by Bunny. One PhD by one very smart guy that invested several years. The iPhone will be much harder. Also, the people that _can_ do it may not want to work for the FBI in the first place.
Not quite. But the people they developed it will certainly not be able to break is, as every thing they could think of they made impossible. Whether others can get in or not is an interesting question, but AFAIK, all jail-breaks require the phone to be unlocked and jail-breaks for the iPhone are getting harder and harder. It is an actual problem for security-testing now and Apple will have to do something about that, like offering a simulator or special devices with intentionally broken security.
If Apple did this right, then they cannot do that. And doing this right is likely not that hard if you have a small number of really capable people doing it.
It will not. Even full fascism is not enough to screen people reliable in larger numbers. It can simply not be done. Trying to can cause an incredible amount of damage though, as the aftermath of 9/11 demonstrates very nicely.
The answer to crimes like these is resilience: Put them in context, see that they are not more tragic than if these people had been run over by cars (just as horrible, but accepted as an everyday risk), mourn them and move on. But do not panic and sacrifice a free society or give lying snake-oil vendors like the FBI or the NSA more power just because they claim they can do something. They cannot. But it is not required to do anything as these events are so exceptionally rare and society is not threatened by them at all.
The perpetrators are contained. Finding out why they did it has time and can be done slowly and the old-fashioned way. The only thing they are doing here is to push (again) stupidly for a thing that makes everybody much less safe: backdoors. They must not be allowed to make the current global computing infrastructure even less secure as it is today, just to cater to their laziness. These people are more of a threat than any criminal could ever be.
Well, I do understand what you are saying (I think) and it has been done before. Problem is, if you have access to main memory only through abstractions (or drivers), then that kills performance for a great many things. The very purpose of a systems programming language is to not have that performance loss. Also, interface definitions are just as subject to error as interface implementations, that path does not work. The "interface generation" idea sounds nice, but in the end, you bring in the same problems not as errors in the code, but as errors in the interface specification. Typically, they end up having even more serious problems, because typically, they are much harder to fix.
I do not advocate to use direct memory (or hardware) access routinely. (Personally, I have currently standardized on Python3 as glue and logic and C modules to do the heavy lifting wherever that brings significant time or space advantages.) But I do not believe that a language can be both made efficient and memory-safe. It has been tried numerous times before and always did run into fundamental problems. And each time, the proponents of the new thing said it would solve all those problems. It never did or only at far too high a price (excluding special cases). At the systems programming level you need the control and the efficiency and you do not get them with memory safety or hardware-access safety for that matter. Not doable, unless we get working true AI at some time. The problem is than in order to know what is safe, it is is required to understand what the software is doing. No compiler can do that.
However, I do not see any fundamental problem with this. I do see the problem that the parts in the systems programming language have to be kept minimal, and that somebody really competent has to do them. Both things are unfortunately often not the case today. The GNU libc, for example, has suffered significantly from the arrogance and incompetence of Ulrich Drepper. (I know him. Very smart, but thinks he is even smarter than he really is and that is the problem.) Fortunately, he is gone now. If done right, the functionality of GNU libc will be kept stable for a long time and at some point there will not be any significant problems left. That is the only way to do it. Writing this thing new, like musl attempts to do, will fix some problems with glibc, but will introduce a host of new and surprising defects instead. That is not a good idea at all.
I do know that there is a school of thought that thinks coding is easy and you just need the right language and everybody can do everything. Having taught coding to a few hundred people academically, I do not believe that is the case at all. It is a specific talent people need and it requires at least a decade to get good at it. I have seen people fail CS after trying for 2 years because they could not hack it, and then go on and do a good Master's in Mathematics, so it is not intelligence or structured thinking what they lack.
The other thing is that a language is always a trade-off between safety and power. It must be in this universe where performance is the limit and not computability. The RUST proponents are just the latest in a long, long string of movements that do not understand that. Their idea has been tried so many times, that the most serious criticism of RUST is that its proponents do not know or do not understand the history of computing. Their arrogance does not help either, but their fundamental failing is that they make claims that are _known_ to not hold up and have been known to not be feasible for a long time. Hence they separate their audience into two classes: The bright-eyed naives that are unaware what has all been tried without success and think this may be the great shiny silver bullet and those a bit more grounded in reality that see that what they claim is actually not achievable, at least not today.
Only if you language knows about all present and future hardware and its exact functionality. Incidentally, even if you could do that (which you cannot), the result would not be a "systems programming language" anymore.
You are clueless and shoot off your mouth and the person pointing it out is an "arrogant dick"? Are you campaigning for equal credibility for idiots and morons or what?
You really do not have the least clue about OS security, do you? Well, if you are a typical systemd proponent, that explains why you like this thing: You do not understand it at all.
It will not get on any of our production servers, ever. Our production servers have to be secure and reliable. So far using Debian without that unmitigated catastrophe was no problem. Calling that thing a "standard" is just dishonest and repulsive propaganda.
They did not have memory-mapped I/O, unlike basically any hardware available today. But hey, why accept facts when you can throw something completely irrelevant into the mix.
You are calling for link-encryption. That is obvious nonsense for email. Proper email encryption is end-to-end and does not trust the transport at all.
Incidentally, this problem has been solved since 1991 with PGP.
Slashdot Mirror
It is. Together with progressive delays going up to years after failed tries. The designers of this thing are not stupid, the occasional mess-up (antenna-gate, e.g.) non-withstanding.
Then neither side would make this public as these would need to be kept secret at this time. No, this is the FBI trying to call Apples bluff. Thing is, I think it is not a bluff at all. Oh, sure, if you throw, say, 100 Million and 10 really capable people at the problem, they would get the phone open and it may even take less than a year. But the FBI cannot legally order Apple to spend that effort.
In any case, it will be very interesting so see how this unfolds. I predict Apple is going to win and we all will have a better world for it.
Well, the systemd-crowd is the one in the corner, the others have something like 10 alternatives and do believe in choice, unlike you people. I to understand the hyper-aggressive emotional campaign for systemd though: You people have literally burned all bridges and claimed that your tool is the only one that promises eternal life and happiness. Of course, after such a fanatical entry onto the stage, even admitting a tiny bit that things may not be as clear-cut is something you cannot do anymore without looking like complete idiots.
And why exactly do you believe that one of the world's most capable tech companies does not use such elementary and well-understood precautions?
No. This is not on the amateur-level you describe. True, much "security" is on the level you describe, but this is a secure microcontroller. Give it exactly what it expects or fail 10 times and it will nuke its key-storage using power from internal and well-protected capacitors.
Brute forcing BPKDF2 is easy in comparison to what he wants. This is about breaking a secure microcontroller. A few orders of magnitude harder and pure software-attacks will very likely not work.
They would need to image the secure microcontroller holding the key. That is a bit harder. Might take a few years of research by some really bright people and some really expensive equipment.
No. They need to pull the encryption-keys from a secure microcontroller. If you can throw a lot of money and time at the problem, that is doable. To get an idea, I recommend "Hacking the Xbox" by Bunny. One PhD by one very smart guy that invested several years. The iPhone will be much harder. Also, the people that _can_ do it may not want to work for the FBI in the first place.
Not quite. But the people they developed it will certainly not be able to break is, as every thing they could think of they made impossible. Whether others can get in or not is an interesting question, but AFAIK, all jail-breaks require the phone to be unlocked and jail-breaks for the iPhone are getting harder and harder. It is an actual problem for security-testing now and Apple will have to do something about that, like offering a simulator or special devices with intentionally broken security.
If Apple did this right, then they cannot do that. And doing this right is likely not that hard if you have a small number of really capable people doing it.
It will not. Even full fascism is not enough to screen people reliable in larger numbers. It can simply not be done. Trying to can cause an incredible amount of damage though, as the aftermath of 9/11 demonstrates very nicely.
The answer to crimes like these is resilience: Put them in context, see that they are not more tragic than if these people had been run over by cars (just as horrible, but accepted as an everyday risk), mourn them and move on. But do not panic and sacrifice a free society or give lying snake-oil vendors like the FBI or the NSA more power just because they claim they can do something. They cannot. But it is not required to do anything as these events are so exceptionally rare and society is not threatened by them at all.
If apple did it right, they cannot supply any of that with reasonable effort (or possibly at all).
The perpetrators are contained. Finding out why they did it has time and can be done slowly and the old-fashioned way. The only thing they are doing here is to push (again) stupidly for a thing that makes everybody much less safe: backdoors. They must not be allowed to make the current global computing infrastructure even less secure as it is today, just to cater to their laziness. These people are more of a threat than any criminal could ever be.
Well, I do understand what you are saying (I think) and it has been done before. Problem is, if you have access to main memory only through abstractions (or drivers), then that kills performance for a great many things. The very purpose of a systems programming language is to not have that performance loss. Also, interface definitions are just as subject to error as interface implementations, that path does not work. The "interface generation" idea sounds nice, but in the end, you bring in the same problems not as errors in the code, but as errors in the interface specification. Typically, they end up having even more serious problems, because typically, they are much harder to fix.
I do not advocate to use direct memory (or hardware) access routinely. (Personally, I have currently standardized on Python3 as glue and logic and C modules to do the heavy lifting wherever that brings significant time or space advantages.) But I do not believe that a language can be both made efficient and memory-safe. It has been tried numerous times before and always did run into fundamental problems. And each time, the proponents of the new thing said it would solve all those problems. It never did or only at far too high a price (excluding special cases). At the systems programming level you need the control and the efficiency and you do not get them with memory safety or hardware-access safety for that matter. Not doable, unless we get working true AI at some time. The problem is than in order to know what is safe, it is is required to understand what the software is doing. No compiler can do that.
However, I do not see any fundamental problem with this. I do see the problem that the parts in the systems programming language have to be kept minimal, and that somebody really competent has to do them. Both things are unfortunately often not the case today. The GNU libc, for example, has suffered significantly from the arrogance and incompetence of Ulrich Drepper. (I know him. Very smart, but thinks he is even smarter than he really is and that is the problem.) Fortunately, he is gone now. If done right, the functionality of GNU libc will be kept stable for a long time and at some point there will not be any significant problems left. That is the only way to do it. Writing this thing new, like musl attempts to do, will fix some problems with glibc, but will introduce a host of new and surprising defects instead. That is not a good idea at all.
I do know that there is a school of thought that thinks coding is easy and you just need the right language and everybody can do everything. Having taught coding to a few hundred people academically, I do not believe that is the case at all. It is a specific talent people need and it requires at least a decade to get good at it. I have seen people fail CS after trying for 2 years because they could not hack it, and then go on and do a good Master's in Mathematics, so it is not intelligence or structured thinking what they lack.
The other thing is that a language is always a trade-off between safety and power. It must be in this universe where performance is the limit and not computability. The RUST proponents are just the latest in a long, long string of movements that do not understand that. Their idea has been tried so many times, that the most serious criticism of RUST is that its proponents do not know or do not understand the history of computing. Their arrogance does not help either, but their fundamental failing is that they make claims that are _known_ to not hold up and have been known to not be feasible for a long time. Hence they separate their audience into two classes: The bright-eyed naives that are unaware what has all been tried without success and think this may be the great shiny silver bullet and those a bit more grounded in reality that see that what they claim is actually not achievable, at least not today.
Only if you language knows about all present and future hardware and its exact functionality. Incidentally, even if you could do that (which you cannot), the result would not be a "systems programming language" anymore.
You are clueless and shoot off your mouth and the person pointing it out is an "arrogant dick"? Are you campaigning for equal credibility for idiots and morons or what?
You really do not have the least clue about OS security, do you? Well, if you are a typical systemd proponent, that explains why you like this thing: You do not understand it at all.
It is not. Get your facts straight.
You forget who the hostile intruder is here...
It will not get on any of our production servers, ever. Our production servers have to be secure and reliable. So far using Debian without that unmitigated catastrophe was no problem. Calling that thing a "standard" is just dishonest and repulsive propaganda.
No, they will not make anything "100 times faster". The limiter today is interconnect and that does not get any faster at all with this material.
They did not have memory-mapped I/O, unlike basically any hardware available today. But hey, why accept facts when you can throw something completely irrelevant into the mix.
That is not possible, despite some big fat liars claiming their pet tool can do it. Either systems programming or memory safety. You cannot get both.
You are calling for link-encryption. That is obvious nonsense for email. Proper email encryption is end-to-end and does not trust the transport at all.
Incidentally, this problem has been solved since 1991 with PGP.
That pattern is well-established by now. If they have a drive and media that are actually available, I may take an interest, but not before.