If I pre-arrange a key with someone. Say Page 10 of the New York times as published on friday. Then I buy a paper, they buy a paper and I can send them a message they can decode. Only use the paper once, it is an OTP. Actually, it is how a lot of OTP's were done in the past
As the other poster pointed out, that's not a one-time pad, that's a book cypher. That is, indeed, how a lot of crypto was done in the past and, as a result, there are well-known techniques for attacking it. They are far more feasible in the modern age, because it's easy to put all books that both parties are likely to have and all recent newspapers in a database and then do statistical analysis on the result. As soon as I know that it's a book cypher using a recent newspaper, I have a good chance of being able to crack it if you write anything other than very short messages, and if you're only going to share very small messages then you may as well arrange a one-time pad with a symbol space optimised for your messages (e.g. encode a byte where the low three bits are a number of days, the next 5 are a set of possible targets, with all 1s being cancel attack. Now you need an 8-bit one-time pad to be able to securely send your message).
The IRA used a lot of book cyphers and GCHQ was able to crack most of them quite easily.
Could be, though SQL is also fairly declarative and programmers with a strong imperative background tend to try to force it to behave like an imperative language in ways that make life harder for the query optimiser.
Language without structure were replaced for production code for a reason. Hierarchy is not the only structure. Dataflow languages don't impose a hierarchical structure, yet are often both easier to teach and a more natural match for the problem. Erlang has some hierarchy, but far less than most languages and is probably the modern language that maps most naturally to modern hardware, as well as making it easy to write very complex programs that scale to large clusters.
Please will you point out anything that I've said that is incorrect and why? Also, who on earth do you think would pay someone to point out the limitations of one-time pads?
It has named parameters, like Objective-C, and it sometimes has the Objective-C object model (and sometimes doesn't, because consistency is a bad thing now).
Now if they write the whole app in Swift it will be easier to get it running on iOS
Apple keeps asserting that, and in comparison to Objective-C Swift does have some improvements in code density. In comparison to Objective-C++, it's feels horribly verbose and full of redundancy. Swift also has really crappy C++ interop, so if you're using any C++ libraries then you can either use Objective-C++ and get the interop for free or Swift and be forced to jump through hoops.
We WANT the geeks who will try to make their code as efficient as possible
We do, but we also want people who will spend 10 minutes throwing together a simple program that will automate something in their workflow and save them half an hour a week for the rest of the year. We don't really care if it takes 30 seconds of CPU time to run, when a good programmer could optimise it to run in under a millisecond, because it's still far cheaper to spend 30 seconds of CPU time than 30 minutes of human time each day.
We WANT them to know the limits and pitfalls of their chosen language forwards and backwards so that they make better more secure code
If they're writing reusable code, or code that's taking untrusted data and doing dangerous things with it, sure. But if they're just doing some small automation tasks? I just want them to get their job done faster.
Stop thinking of programming as something that only people who work as full-time programmers do. Most jobs have huge inefficiencies in their workflow because people who know exactly what steps are simple and repetitive don't have the skills to apply some trivial automation.
Back when I was a PhD student, I came across a study showing that about 10% of the population naturally uses hierarchies in their mental model of structure. This came up in the context of HCI research, where you find things like filesystem hierarchies that make complete sense to some people and are largely incomprehensible to others. This was one of the reasons for iTunes' early success (before version 5, when they completely screwed up the UI): music was in a flat library, with arbitrary filters. You could filter by album, artist, or genre independently, there was no hierarchical structure. Geeks said 'why would I need this, I already have my music in a music/{genre}/{artist}/{album}/ hierarchy, people too stupid to understand that shouldn't use computers'.
Why am I talking about this? Because almost all mainstream programming languages implicitly adopt hierarchical structures. We have namespaces containing classes containing instance variables and methods. We have nested scopes. We have call stacks of subroutines (though coroutines are starting to come back into fashion).
So what makes Swift different? Absolutely nothing. It has a load of marketing behind it, but structurally it is no different from any other Algol family language with some Smalltalk influence. It requires thinking in precisely the same way as Objective-C or Java, it just spells some of the things differently. And it is both more verbose slower than Objective-C++ for pretty much every task.
One-time pads are not really feasible. An earlier Slashdot post suggested not thinking of one-time pads as encryption, but as a way of time shifting use of a secure channel. If you have a secure channel now over which you can distribute n bits of data, then you can distribute an n-bit one-time pad and then later you can use an insecure channel to send an n-bit message securely. Having to distribute a key as long as a message is not very easy, and the requirement that the pad be generated with a cryptographically secure random number generator makes it a bit harder.
That said, algorithms like RSA and AES are pretty simple to implement. Most of the attacks on implementations of these have been timing vulnerabilities (requiring an attacker either on the same machine or very close on the network), or attacks on incorrect use of the crypto primitives in more complex cryptosystems. You can take the code examples from Applied Cryptography, change the #defines to give you longer key lengths (many of the examples use insecure key lengths to avoid export restrictions), and you've got an implementation of a secure algorithm. If you're encrypting offline and exchanging messages via some channel where an attacker has no control over or visibility of your timing, it's probably secure.
Apple's ARM cores are not designed by ARM, they're designed by Apple. Apple has an architecture license, allowing them to create completely independent implementations of the ARM ISA. Quite a few of ARM's high-end designs come from Austin (I think the A72 was from that team, for example).
You can never be 100% sure, but if this report is inaccurate then their liability under the GDPR is going to be huge. Someone in Redmond is no doubt calculating the size of the fine versus the value of the data, and my guess is that the value of any data that they're not willing to admit collecting is far lower than the possible fine (I forget the exact amount, but I think it's something like 10% of annual turnover).
They probably don't care if you disable it. They probably don't care if 5% of their users disable it. They do care if all corporate users disable it, because those are the customers most likely to complain loudly if the system crashes or performs poorly in their use cases.
Yes it does. When MS did some initial pilots of this, they found that around 80% of Windows crashes were caused by a small number of device drivers not sanity checking the data coming from the device. Apparently it was really common to see code that would read an error code from a device register and then use that to index into a table of error messages and return that higher up the stack. This works fine in most cases, but transient errors on the bus can cause that value to be out of the expected range, so the error message pointer ends up being to a random bit of kernel memory. Attempting to copy it out to userspace then doesn't find a null byte and gives you an invalid access in kernel mode, which triggers a crash. They now have a static analysis tool that checks for this.
The crashes you see in Windows, macOS, Linux, or FreeBSD are the ones that don't happen on the developers' systems. On systems with a mostly technical userbase, you can rely on helpful bug reports. On systems with a mostly non-technical userbase, you need some mechanism for identifying the causes of common issues for users.
It depends on what the data are. There's a bunch of stuff that I wouldn't mind an OS vendor knowing, because it makes it easier for them to fix bugs that affect me. There's also data that I don't want them seeing because it includes confidential or personal information (and, in some cases, where an NDA means that I may have legal penalties if I do let them see it). Core dumps of applications, for example, will contain state regarding my documents and should never be sent without my express permission, but a stack trace of a crash is fine. I'm also fine with some aggregate data regarding CPU usage of different applications (if they know that application X is responsible for flattening my battery, maybe they'll prioritise optimising it), but I'm not okay with their knowing exactly which applications are running when.
The US had a huge advantage at the end of the second world war, because they were basically the only industrialised nation that hadn't been fighting on their own soil and had fairly limited engagement. The US lost 0.32% of its population in WWII. The UK lost 0.94%, France lost 1.44%, the USSR lost 13.7%. A lot of infrastructure in Europe was destroyed by bombing, whereas the US only lost overseas assets.
This then had a knock on effect that working in the US was very attractive to displaced researchers and engineers. Would you rather work in Poland, which had just been rolled over by the Nazi and Soviet armies who, between them, had killed around 17% of the total population and destroyed most of the infrastructure, or in the US? If you had useful skills, US universities and research labs would fly you out and relocate the surviving parts of your family. Remember that rationing didn't end in the UK until 1954 - there were shortages of a lot of staples right up until then, and if you can't even guarantee food then getting access to the latest scientific equipment is not very likely. If you were good, then the offer of tenure at a US university and comparatively unlimited funds without any problems getting equipment was very attractive.
For the next couple of decades, the US benefitted hugely from having recruited all of these people and concentrated them in places with far better support systems than anywhere else. This continued for a while, because going to the university that had the top 5 people in the world in a subject area was a big draw, but it gradually faded as the standard living elsewhere recovered and surpassed the US.
Do you think engineer in the US actually put together blueprints for A10 processor?
Yup. Most of Apple's CPU design team is based in the US. Qualcomm also has a large team in San Diego and most CPU vendors do a lot of design work in Austin.
The browser-based game Kingdom of Loathing requires that you pass a very simple grammar / punctuation test before you are allowed to use their chat system. It works surprisingly well...
The problem is apps that maintain a lot of state outside of the SD card and don't have good export / import functionality. It's slightly annoying having to reenter login credentials.
I don't really like it, but given that the alternative is to allow two apps with different signing certificates to access the same data (even with a 'train the user to click yes to security questions' box), I'm willing to put up with it. Almost all of the apps I have on my phone now are from F-Droid.
It's not just that it's theory, it's theory presented in a pretty unapproachable way. People read TAOCP for the same reason that they join Mensa: so that they can look down on people that didn't. If you actually want to learn the theory, then you can pick up pretty much any undergraduate computer science textbook and see a far more approachable presentation.
Remember, this is the same Knuth whose TeX system started with a Turing machine and thought 'that's a really approachable programming model. Scoping and constraining side effects are for n00bs'.
If you feel the need to read something written by one of the computer science greats, then read pretty much anything Dijkstra wrote (even his review of the IBM 1620).
How big is a box of 300 iPhones? They come in pretty small boxes, and 300 is only a 10x10x3 cuboid. I wouldn't be surprised if you could easily pick up a box of 300 iPhones and walk off with it. It's just as likely to be an underpaid UPS employee wandering off with a package or leaving the back of their van open during a delivery so someone else walks off with it. Walking off with a box that's small enough to carry sounds much more like opportunist theft than organised crime.
Why do you think using an FPGA would help? All of the commercial FPGAs use proprietary place-and-route tools, have proprietary macroblocks, and have no public documentation for anything other than 'verilog goes in here'. There's as little guarantee that an FPGA-based implementation has not been tampered with as there is for an ASIC.
Not even slightly true. The DoD has a policy of trying to avoid being responsible for their supply chain. DARPA regards technology transfer as one of their key metrics for success in a project like this: they want companies (ideally US companies, and especially companies that provide critical bits of national infrastructure) to adopt the results of these projects. They are also well aware of both how much open source they depend on and of how good open source is as a route for technology transfer: even if they're not going to use the open source version, they've very happy to have things published under BSD-like licenses so that everyone can look at them and build things based on them.
Chip dies are literally the kind of thing where once it's printed, it's impossible (not hard, impossible) to verify that your design made it into silicon untampered
It's worth noting that this exact problem is currently the focus of a large DARPA-funded research project. The DoD is understandably nervous that even if they have complete RTL and formal verification that the RTL corresponds to the ISA (which is not currently feasible for nontrivial designs, but is probably less than a decade away), they have no idea if what they get back from the fab is really the same thing and they'd like to know.
Yup. Krste has some interesting slides on this. The take-home summary is that the ROI for newer processes is not currently worth it. It used to be that one generation old was cheap, two was basically free, because the newer processes were so much better than the old and still won on price/performance ratios. Now, the sweet spot is closer to 4-5 generations old. You can spend a lot more on the newer processes, but you don't get very much return and it probably isn't worth it.
Slashdot Mirror
If I pre-arrange a key with someone. Say Page 10 of the New York times as published on friday. Then I buy a paper, they buy a paper and I can send them a message they can decode. Only use the paper once, it is an OTP. Actually, it is how a lot of OTP's were done in the past
As the other poster pointed out, that's not a one-time pad, that's a book cypher. That is, indeed, how a lot of crypto was done in the past and, as a result, there are well-known techniques for attacking it. They are far more feasible in the modern age, because it's easy to put all books that both parties are likely to have and all recent newspapers in a database and then do statistical analysis on the result. As soon as I know that it's a book cypher using a recent newspaper, I have a good chance of being able to crack it if you write anything other than very short messages, and if you're only going to share very small messages then you may as well arrange a one-time pad with a symbol space optimised for your messages (e.g. encode a byte where the low three bits are a number of days, the next 5 are a set of possible targets, with all 1s being cancel attack. Now you need an 8-bit one-time pad to be able to securely send your message).
The IRA used a lot of book cyphers and GCHQ was able to crack most of them quite easily.
Could be, though SQL is also fairly declarative and programmers with a strong imperative background tend to try to force it to behave like an imperative language in ways that make life harder for the query optimiser.
Language without structure were replaced for production code for a reason. Hierarchy is not the only structure. Dataflow languages don't impose a hierarchical structure, yet are often both easier to teach and a more natural match for the problem. Erlang has some hierarchy, but far less than most languages and is probably the modern language that maps most naturally to modern hardware, as well as making it easy to write very complex programs that scale to large clusters.
Please will you point out anything that I've said that is incorrect and why? Also, who on earth do you think would pay someone to point out the limitations of one-time pads?
It has named parameters, like Objective-C, and it sometimes has the Objective-C object model (and sometimes doesn't, because consistency is a bad thing now).
Now if they write the whole app in Swift it will be easier to get it running on iOS
Apple keeps asserting that, and in comparison to Objective-C Swift does have some improvements in code density. In comparison to Objective-C++, it's feels horribly verbose and full of redundancy. Swift also has really crappy C++ interop, so if you're using any C++ libraries then you can either use Objective-C++ and get the interop for free or Swift and be forced to jump through hoops.
We WANT the geeks who will try to make their code as efficient as possible
We do, but we also want people who will spend 10 minutes throwing together a simple program that will automate something in their workflow and save them half an hour a week for the rest of the year. We don't really care if it takes 30 seconds of CPU time to run, when a good programmer could optimise it to run in under a millisecond, because it's still far cheaper to spend 30 seconds of CPU time than 30 minutes of human time each day.
We WANT them to know the limits and pitfalls of their chosen language forwards and backwards so that they make better more secure code
If they're writing reusable code, or code that's taking untrusted data and doing dangerous things with it, sure. But if they're just doing some small automation tasks? I just want them to get their job done faster.
Stop thinking of programming as something that only people who work as full-time programmers do. Most jobs have huge inefficiencies in their workflow because people who know exactly what steps are simple and repetitive don't have the skills to apply some trivial automation.
Back when I was a PhD student, I came across a study showing that about 10% of the population naturally uses hierarchies in their mental model of structure. This came up in the context of HCI research, where you find things like filesystem hierarchies that make complete sense to some people and are largely incomprehensible to others. This was one of the reasons for iTunes' early success (before version 5, when they completely screwed up the UI): music was in a flat library, with arbitrary filters. You could filter by album, artist, or genre independently, there was no hierarchical structure. Geeks said 'why would I need this, I already have my music in a music/{genre}/{artist}/{album}/ hierarchy, people too stupid to understand that shouldn't use computers'.
Why am I talking about this? Because almost all mainstream programming languages implicitly adopt hierarchical structures. We have namespaces containing classes containing instance variables and methods. We have nested scopes. We have call stacks of subroutines (though coroutines are starting to come back into fashion).
So what makes Swift different? Absolutely nothing. It has a load of marketing behind it, but structurally it is no different from any other Algol family language with some Smalltalk influence. It requires thinking in precisely the same way as Objective-C or Java, it just spells some of the things differently. And it is both more verbose slower than Objective-C++ for pretty much every task.
One-time pads are not really feasible. An earlier Slashdot post suggested not thinking of one-time pads as encryption, but as a way of time shifting use of a secure channel. If you have a secure channel now over which you can distribute n bits of data, then you can distribute an n-bit one-time pad and then later you can use an insecure channel to send an n-bit message securely. Having to distribute a key as long as a message is not very easy, and the requirement that the pad be generated with a cryptographically secure random number generator makes it a bit harder.
That said, algorithms like RSA and AES are pretty simple to implement. Most of the attacks on implementations of these have been timing vulnerabilities (requiring an attacker either on the same machine or very close on the network), or attacks on incorrect use of the crypto primitives in more complex cryptosystems. You can take the code examples from Applied Cryptography, change the #defines to give you longer key lengths (many of the examples use insecure key lengths to avoid export restrictions), and you've got an implementation of a secure algorithm. If you're encrypting offline and exchanging messages via some channel where an attacker has no control over or visibility of your timing, it's probably secure.
Apple's ARM cores are not designed by ARM, they're designed by Apple. Apple has an architecture license, allowing them to create completely independent implementations of the ARM ISA. Quite a few of ARM's high-end designs come from Austin (I think the A72 was from that team, for example).
Who says that's ALL they really collect?
You can never be 100% sure, but if this report is inaccurate then their liability under the GDPR is going to be huge. Someone in Redmond is no doubt calculating the size of the fine versus the value of the data, and my guess is that the value of any data that they're not willing to admit collecting is far lower than the possible fine (I forget the exact amount, but I think it's something like 10% of annual turnover).
They probably don't care if you disable it. They probably don't care if 5% of their users disable it. They do care if all corporate users disable it, because those are the customers most likely to complain loudly if the system crashes or performs poorly in their use cases.
Yes it does. When MS did some initial pilots of this, they found that around 80% of Windows crashes were caused by a small number of device drivers not sanity checking the data coming from the device. Apparently it was really common to see code that would read an error code from a device register and then use that to index into a table of error messages and return that higher up the stack. This works fine in most cases, but transient errors on the bus can cause that value to be out of the expected range, so the error message pointer ends up being to a random bit of kernel memory. Attempting to copy it out to userspace then doesn't find a null byte and gives you an invalid access in kernel mode, which triggers a crash. They now have a static analysis tool that checks for this.
The crashes you see in Windows, macOS, Linux, or FreeBSD are the ones that don't happen on the developers' systems. On systems with a mostly technical userbase, you can rely on helpful bug reports. On systems with a mostly non-technical userbase, you need some mechanism for identifying the causes of common issues for users.
It depends on what the data are. There's a bunch of stuff that I wouldn't mind an OS vendor knowing, because it makes it easier for them to fix bugs that affect me. There's also data that I don't want them seeing because it includes confidential or personal information (and, in some cases, where an NDA means that I may have legal penalties if I do let them see it). Core dumps of applications, for example, will contain state regarding my documents and should never be sent without my express permission, but a stack trace of a crash is fine. I'm also fine with some aggregate data regarding CPU usage of different applications (if they know that application X is responsible for flattening my battery, maybe they'll prioritise optimising it), but I'm not okay with their knowing exactly which applications are running when.
The US had a huge advantage at the end of the second world war, because they were basically the only industrialised nation that hadn't been fighting on their own soil and had fairly limited engagement. The US lost 0.32% of its population in WWII. The UK lost 0.94%, France lost 1.44%, the USSR lost 13.7%. A lot of infrastructure in Europe was destroyed by bombing, whereas the US only lost overseas assets.
This then had a knock on effect that working in the US was very attractive to displaced researchers and engineers. Would you rather work in Poland, which had just been rolled over by the Nazi and Soviet armies who, between them, had killed around 17% of the total population and destroyed most of the infrastructure, or in the US? If you had useful skills, US universities and research labs would fly you out and relocate the surviving parts of your family. Remember that rationing didn't end in the UK until 1954 - there were shortages of a lot of staples right up until then, and if you can't even guarantee food then getting access to the latest scientific equipment is not very likely. If you were good, then the offer of tenure at a US university and comparatively unlimited funds without any problems getting equipment was very attractive.
For the next couple of decades, the US benefitted hugely from having recruited all of these people and concentrated them in places with far better support systems than anywhere else. This continued for a while, because going to the university that had the top 5 people in the world in a subject area was a big draw, but it gradually faded as the standard living elsewhere recovered and surpassed the US.
Do you think engineer in the US actually put together blueprints for A10 processor?
Yup. Most of Apple's CPU design team is based in the US. Qualcomm also has a large team in San Diego and most CPU vendors do a lot of design work in Austin.
The browser-based game Kingdom of Loathing requires that you pass a very simple grammar / punctuation test before you are allowed to use their chat system. It works surprisingly well...
The problem is apps that maintain a lot of state outside of the SD card and don't have good export / import functionality. It's slightly annoying having to reenter login credentials.
I don't really like it, but given that the alternative is to allow two apps with different signing certificates to access the same data (even with a 'train the user to click yes to security questions' box), I'm willing to put up with it. Almost all of the apps I have on my phone now are from F-Droid.
they already had the tsar bomba
Which, contrary to what TFS says, was this powerful. The test detonation was at half yield.
It's not just that it's theory, it's theory presented in a pretty unapproachable way. People read TAOCP for the same reason that they join Mensa: so that they can look down on people that didn't. If you actually want to learn the theory, then you can pick up pretty much any undergraduate computer science textbook and see a far more approachable presentation.
Remember, this is the same Knuth whose TeX system started with a Turing machine and thought 'that's a really approachable programming model. Scoping and constraining side effects are for n00bs'.
If you feel the need to read something written by one of the computer science greats, then read pretty much anything Dijkstra wrote (even his review of the IBM 1620).
How big is a box of 300 iPhones? They come in pretty small boxes, and 300 is only a 10x10x3 cuboid. I wouldn't be surprised if you could easily pick up a box of 300 iPhones and walk off with it. It's just as likely to be an underpaid UPS employee wandering off with a package or leaving the back of their van open during a delivery so someone else walks off with it. Walking off with a box that's small enough to carry sounds much more like opportunist theft than organised crime.
Why do you think using an FPGA would help? All of the commercial FPGAs use proprietary place-and-route tools, have proprietary macroblocks, and have no public documentation for anything other than 'verilog goes in here'. There's as little guarantee that an FPGA-based implementation has not been tampered with as there is for an ASIC.
Not even slightly true. The DoD has a policy of trying to avoid being responsible for their supply chain. DARPA regards technology transfer as one of their key metrics for success in a project like this: they want companies (ideally US companies, and especially companies that provide critical bits of national infrastructure) to adopt the results of these projects. They are also well aware of both how much open source they depend on and of how good open source is as a route for technology transfer: even if they're not going to use the open source version, they've very happy to have things published under BSD-like licenses so that everyone can look at them and build things based on them.
Chip dies are literally the kind of thing where once it's printed, it's impossible (not hard, impossible) to verify that your design made it into silicon untampered
It's worth noting that this exact problem is currently the focus of a large DARPA-funded research project. The DoD is understandably nervous that even if they have complete RTL and formal verification that the RTL corresponds to the ISA (which is not currently feasible for nontrivial designs, but is probably less than a decade away), they have no idea if what they get back from the fab is really the same thing and they'd like to know.
Has it gotten that expensive?
Yup. Krste has some interesting slides on this. The take-home summary is that the ROI for newer processes is not currently worth it. It used to be that one generation old was cheap, two was basically free, because the newer processes were so much better than the old and still won on price/performance ratios. Now, the sweet spot is closer to 4-5 generations old. You can spend a lot more on the newer processes, but you don't get very much return and it probably isn't worth it.