Nitrous Oxide isn't a bad idea, followed by CO2 or N2 displacing all the O2, or simply lowering the pressure.
If you don't want to include euphoria, just use straight N2 or He. The feeling of suffocation is triggered by CO2 buildup, not O2 deficiency, so a person able to freely respire a low CO2 gas mixture without any O2 feels nothing at all, positive or negative, but simply falls asleep. No needles, no poisons, no discomfort... they just fall asleep and then die. Technically they suffocate, but with no feeling of suffocation.
You don't need any sort of special chamber for this. Just a typical hospital oxygen mask and a cylinder of compressed inert gas. It doesn't even matter if the person being executed gets a little bit of ambient O2, as long as the percentage of O2 in the breathing mixture is down around 2% or lower. You probably need to strap the person down so they don't try to remove the mask, but if you play it right they'll never realize when their death has begun... start with a continuous flow of air into from a compressed cylinder into the mask, then without changing pressure or temperature or otherwise notifying the person that the time has arrived, switch it over to the inert gas.
umm, the income tax is actually found in the constitution, not any "social contract"
Better yet. where is this social contract so i can have my lawyer take a look at it and see if it stands up
A big chunk of it is written down in the constitutions.
I'm not dissing what these guys are doing; it's good to demonstrate the increasing capabilities of self-driving cars. But I don't think it's very accurate to call this the "most ambitious" test, because long-distance driving, especially on highways like the US interstate system, is about the easiest form of driving there is to automate. I'm much more impressed with the ability of Google's self-driving cars to negotiate crowded city streets safely.
One more point. If your criticism of NHST is more nuanced and informed than I'm assuming, please excuse me. There certainly are significant problems with the way it's generally done, including widespread misinterpretation of the meaning of p values, overemphasis on particular thresholds, and much more.
However, what came before NHST wasn't better statistical analysis of scientific data. Current methods do often leave statisticians shaking their heads, but it is still a significant improvement over the non-statistical methods of much scientific work of the past.
(I should also note that I'm not a statistician. My education is in mathematics, and I've invested a fair amount of time into furthering my statistical knowledge, but I'm not an expert.)
The problem is that if you understand what a null hypothesis is, and why the first step in demonstrating that results are potentially meaningful requires demonstrating that it can be rejected, then there's nothing to explain. And if you don't understand those things you need more education on the topic than I can provide in a slashdot post.
I wasn't being dismissive, I told you precisely (if concisely) what you need to do to understand why this change in scientific methodology was important and valuable. If you care about the issue, I suggest that you do the work to learn the material. If you don't care to do that, the best thing I can do is to point out the lack so others who also lack the requisite background are less likely to accept your misunderstanding as a fact.
Really, I'm not being elitist or dismissive. I'm completely certain that you're capable of understanding the material -- and it's not material that I would expect everyone to know. But it is sufficiently subtle and complex that I'd be doing you a disservice if I tried to explain it in a few paragraphs of non-mathematical exposition, particularly since your earlier comment about disproving chance demonstrates that you've already gotten such an explanation, and it wasn't sufficient.
Starting in the a 1940s people starting disproving a "null hypothesis" rather than "your hypothesis" or "my hypothesis".
And that change was a huge leap forward. It didn't get us to perfection, but the shift indicated a significant (yet still insufficient) increase in statistical literacy in the sciences.
Prey does THE SAME THING as the Google utility. The only significant difference is that it doesn't survive a factory reset.
That difference is ALL the difference. Without that, Prey is irrelevant because the second thing the thief will do is to reset your phone, at which point they can sell it. Prey does nothing to remove the financial motive for phone theft.
Selfie pictures of the thief, real-time tracking of its whereabouts, screenshots, etc.
Nope, because the first thing the thief will do is put the phone in airplane mode.
My Nexus 7 is quite a bit worse after the 5 upgrade.
2012 Nexus 7? If so, 5.1 probably won't make you very happy either. You should probably go back to KitKat. The 2012 N7 doesn't have enough RAM to run Lollipop well. M may be slimmer.
Yeah, you don't want to run Lollipop on a 2012 Nexus 7. 5.0 grew a little and it's too much for the 2012 N7's hardware. A goal of 5.1 was to slim it back down, but that wasn't really achieved. Perhaps M will run well on the 2012 N7.
(Disclaimer: I'm a Google engineer on the Android team, but speaking for myself, not in an official capacity.)
AFAIK, you can turn off the Device Administrator function, and that functionality will be removed.
I have used Prey for years. It is a known quantity, it works well, and doesn't come with the inherent problems of a Google app.
Would it work after a factory reset? No. But that difference isn't enough to get me to switch.
Prey solves a slightly different problem. The purpose of device protection isn't to help you recover your device, it's to prevent thieves from benefiting from stealing your device. As such, it will only work if broadly deployed, because we need to build a "herd immunity" effect. There may be some devices that can be stolen usefully, but if most can't thieves will stop targeting Android devices. This is why it's not an app but part of the base operating system.
If I were a vendor, even one who really wanted to be cooperative, I'd balk at that, because the chances of something like a backdoor being discovered are too high. It would be actively sabotaging my customers, and not just to the NSA.
That did not stop RSA from including NSA's compromised random number generator and making it the default selection. Maybe their alternatives included a secret court order, NSL, or being paid 10 million dollars.
Indeed it didn't. Idiots. $10M appeared to do the trick. Though they did apparently take the money and adopt the PRNG before it was realized that it was likely backdoored, and before we realized that the NSA had abandoned their mission to improve US COMSEC.
If someone gains root, they can swap out the on-disk boot image that contains the kernel, and wait for someone else to reboot it as part of normal maintenance.
Assuming there isn't something that prevents the boot image from being replaced. See my other, more extensive, comment in this thread.
But what you're saying is that rebooting is somehow a magic cure-all that guarantees the system isn't infected somehow
Don't be condescending. I'm not saying rebooting is a magic anything.
Whether or not this matters depends on the threat model and why the attacker is interested in patching the kernel. For example, one purpose would be to disable other kernel security features, such as SELinux, or dm-verity. Most SELinux rules are configured and the configuration can be altered by root, but some are compiled into the kernel and can only be modified by modifying the kernel. Altering the persistent kernel image may not be possible for a variety of reasons (read-only media, SecureBoot, etc.). In addition, in security-sensitive and mission-critical contexts an unexpected reboot may well be noticed.
I don't understand your assertion about SecureBoot. Are you referring to some known vulnerability of some particular secure boot system? Given a decent implementation of secure/verified boot, an attacker should not be able to convince the system to boot a modified kernel image, which means that run-time modification of the kernel is the only option if the attacker needs to bypass some kernel security enforcement.
In general, the security model of a high-security Linux system assumes that the kernel is more trustworthy than root. The ability for root to modify the running kernel invalidates this assumption, which most definitely is a security issue.
In the context of a system without mandatory access controls there may not be any reason to care, since once an attacker has obtained root there probably isn't any limit to what he can do.
It's no more a risk than current patching that requires a reboot, except that you don't have the downtime of a reboot.
Sure, if your concern is error, rather than malice. An attacker who gains root could use this to dynamically patch a backdoor into the running kernel. Rebooting the machine would potentially enable someone to notice.
As another poster noted, though, you can already dynamically patch the kernel for malicious purposes by loading a malicious module, assuming that hasn't been disabled. In contexts where security is crucial, I would disable both dynamic module loading and run-time patching.
I assume the communication companies were handing over a lot more than the NSLs can demand in the spirit of cooperation and that is why the retroactive immunity was necessary
The GP wasn't suggesting that excessive data was handed over, he said that an NSL could be used to demand installation of a backdoor. If I were a vendor, even one who really wanted to be cooperative, I'd balk at that, because the chances of something like a backdoor being discovered are too high. It would be actively sabotaging my customers, and not just to the NSA... a backdoor can't distinguish between users, it lets in anyone who figures it out. And, of course, if the existence of the backdoor were published it would do serious damage to my business.
Even companies who want to cooperate are going to be reluctant to do potentially business-destroying favors for the government. There would be a great deal of incentive to fall back on the law and refuse on the grounds that the law doesn't authorize such requests.
I'm skeptical that an Android device would survive running flat out for two years to crack a PIN. The heat and battery life issues I experienced when I tested it demonstrate clearly that mobile devices simply aren't designed to run full-speed 24x7.
Also, it should be pointed out that the attack I described is far from easy to carry out. Among other things, it requires dumping the contents of flash, which basically requires removing the flash chips from the mainboard without damaging it, then either putting the flash chips back or installing new flash, then the device must be unlocked, a custom, hostile OS flashed, and finally the attacker can start the multi-year process.
Note that the 630-day figure I cited is on average. It would take twice that long for a guaranteed break.
Finally, if you add one more character to your passcode (7-character alphanumeric), the crack time jumps from 630 days on average to 124 years.
I agree that Lollipop FDE still needs some improvement, but it's already quite good.
Civil disobedience has ALWAYS carried the potential for punishment and if you break the law to make your point that the law is unjust you should stand ready to be arrested, imprisoned and tried in court for what you choose to do.
Your argument would carry more weight if the government who'd be trying Snowden weren't the same one he outed for violating its own laws, with the active collaboration of its judicial branch. Not to mention all of the recent fully-public sidestepping of due process for hundreds of other enemy combatants. Oh, and the torture, including of US citizens. And... do I really need to go on?
Snowden has extremely good reason to be skeptical of the fairness of a trial... or if he'd even get a real trial.
Snowden may be using what leverage he has left. He has not yet disclosed all the information he obtained so the US government might cut a deal to avoid further disclosures.
I see no evidence that Snowden didn't hand everything over to the Guardian et al, all at once, as he said he did. On what do you base your claim that he's still got something left?
Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.
1) Good but not as good as C.
In most cases these days it's a distinction without a difference.
2) But it's an unnecessary third layer. Obj-C has the objects. C has the speed and compatibility. What do you need a third layer for?
I see this differently. Obj-C has the objects I need to interact with the framework. C++ has the speed, compatibility and expressive power I want. C has speed and compatibility, but lacks expressive power, which creates a lot of tedium and loses a lot of safety.
3) Indeed.
We agree on something:-)
So virtually no one uses it in this scenario.
Only time I see it used is when it's a library that was written in C++ on another platform and is simply being used on a Mac.
I haven't really done much on Macs, but I did a lot of work on NeXTstep back in the day, and C++ was quite common in scientific computing there. Actually, what I saw a lot of was "Objective-C++"... they may have grown further apart, to the degree that this no longer works, but in the early 90s gcc allowed you to mix Objective-C and C++ constructs freely in the same code. So a common approach was to build everything in an OO fashion, but to choose between Objective-C and C++-style classes based on performance and flexibility tradeoffs. The result required you to be fluent in both, but that really just means being fluent in C++ because a C++ programmer can learn Objective-C in a day (which is something I respect about the language).
You're dropping out of Obj-C for cross platform compatibility, because you're dealing with a low level Apple API, or because you want maximum speed for some part of the code. All these things are usually best served by C.
Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.
Unless you're concerned that you may need to target a platform not supported by a decent C++ compiler (which is really rare, given that gcc is basically everywhere), the only reason to choose C over C++ is personal preference or concern that some of the users of the code may not know C++.
The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock.
No, it doesn't. At least in Lollipop FDE-password is separate and you enter it at boot.
It's not separate. In stock Lollipop there is only one password, and it's used both for FDE and for screen unlock. Some customized ROMs (e.g. CM) have separated it, which allows you to choose a strong boot password and a more convenient unlock password. Stock Android didn't go that direction because too many users would set a strong boot password which they only use once every few weeks and therefore forget, losing all of their data.
Had I jumped to the Nexus 6 at the same time, however, that may not have been an issue.
As a recent Nexus 6 owner, I can confirm that encryption is enabled by default. I have not noticed any performance lag and the battery life has been really good.
I will admit, I'm coming from an 'ancient' phone, so maybe that's why I think it's fast enough; way faster than my old phone.
As mentioned by Gaygirlie, a big factor is the AES-NI instruction in the ARMv8 instruction set supported by your Nexus 6. It dramatically reduces the performance and power hit of AES operations.
Slashdot Mirror
Nitrous Oxide isn't a bad idea, followed by CO2 or N2 displacing all the O2, or simply lowering the pressure.
If you don't want to include euphoria, just use straight N2 or He. The feeling of suffocation is triggered by CO2 buildup, not O2 deficiency, so a person able to freely respire a low CO2 gas mixture without any O2 feels nothing at all, positive or negative, but simply falls asleep. No needles, no poisons, no discomfort... they just fall asleep and then die. Technically they suffocate, but with no feeling of suffocation.
You don't need any sort of special chamber for this. Just a typical hospital oxygen mask and a cylinder of compressed inert gas. It doesn't even matter if the person being executed gets a little bit of ambient O2, as long as the percentage of O2 in the breathing mixture is down around 2% or lower. You probably need to strap the person down so they don't try to remove the mask, but if you play it right they'll never realize when their death has begun... start with a continuous flow of air into from a compressed cylinder into the mask, then without changing pressure or temperature or otherwise notifying the person that the time has arrived, switch it over to the inert gas.
umm, the income tax is actually found in the constitution, not any "social contract" Better yet. where is this social contract so i can have my lawyer take a look at it and see if it stands up
A big chunk of it is written down in the constitutions.
I'm not dissing what these guys are doing; it's good to demonstrate the increasing capabilities of self-driving cars. But I don't think it's very accurate to call this the "most ambitious" test, because long-distance driving, especially on highways like the US interstate system, is about the easiest form of driving there is to automate. I'm much more impressed with the ability of Google's self-driving cars to negotiate crowded city streets safely.
One more point. If your criticism of NHST is more nuanced and informed than I'm assuming, please excuse me. There certainly are significant problems with the way it's generally done, including widespread misinterpretation of the meaning of p values, overemphasis on particular thresholds, and much more.
However, what came before NHST wasn't better statistical analysis of scientific data. Current methods do often leave statisticians shaking their heads, but it is still a significant improvement over the non-statistical methods of much scientific work of the past.
(I should also note that I'm not a statistician. My education is in mathematics, and I've invested a fair amount of time into furthering my statistical knowledge, but I'm not an expert.)
The problem is that if you understand what a null hypothesis is, and why the first step in demonstrating that results are potentially meaningful requires demonstrating that it can be rejected, then there's nothing to explain. And if you don't understand those things you need more education on the topic than I can provide in a slashdot post.
I wasn't being dismissive, I told you precisely (if concisely) what you need to do to understand why this change in scientific methodology was important and valuable. If you care about the issue, I suggest that you do the work to learn the material. If you don't care to do that, the best thing I can do is to point out the lack so others who also lack the requisite background are less likely to accept your misunderstanding as a fact.
Really, I'm not being elitist or dismissive. I'm completely certain that you're capable of understanding the material -- and it's not material that I would expect everyone to know. But it is sufficiently subtle and complex that I'd be doing you a disservice if I tried to explain it in a few paragraphs of non-mathematical exposition, particularly since your earlier comment about disproving chance demonstrates that you've already gotten such an explanation, and it wasn't sufficient.
I disagree. Disproving chance is redundant
You need to learn some statistics.
Starting in the a 1940s people starting disproving a "null hypothesis" rather than "your hypothesis" or "my hypothesis".
And that change was a huge leap forward. It didn't get us to perfection, but the shift indicated a significant (yet still insufficient) increase in statistical literacy in the sciences.
2013 N7. It's plenty fast, it's just not stable.
Really? My 2013 N7 is running just fine. I wonder if it's related to apps.
Prey does THE SAME THING as the Google utility. The only significant difference is that it doesn't survive a factory reset.
That difference is ALL the difference. Without that, Prey is irrelevant because the second thing the thief will do is to reset your phone, at which point they can sell it. Prey does nothing to remove the financial motive for phone theft.
Selfie pictures of the thief, real-time tracking of its whereabouts, screenshots, etc.
Nope, because the first thing the thief will do is put the phone in airplane mode.
My Nexus 7 is quite a bit worse after the 5 upgrade.
2012 Nexus 7? If so, 5.1 probably won't make you very happy either. You should probably go back to KitKat. The 2012 N7 doesn't have enough RAM to run Lollipop well. M may be slimmer.
Yeah, you don't want to run Lollipop on a 2012 Nexus 7. 5.0 grew a little and it's too much for the 2012 N7's hardware. A goal of 5.1 was to slim it back down, but that wasn't really achieved. Perhaps M will run well on the 2012 N7.
(Disclaimer: I'm a Google engineer on the Android team, but speaking for myself, not in an official capacity.)
AFAIK, you can turn off the Device Administrator function, and that functionality will be removed.
I have used Prey for years. It is a known quantity, it works well, and doesn't come with the inherent problems of a Google app. Would it work after a factory reset? No. But that difference isn't enough to get me to switch.
Prey solves a slightly different problem. The purpose of device protection isn't to help you recover your device, it's to prevent thieves from benefiting from stealing your device. As such, it will only work if broadly deployed, because we need to build a "herd immunity" effect. There may be some devices that can be stolen usefully, but if most can't thieves will stop targeting Android devices. This is why it's not an app but part of the base operating system.
if samsung did something to mess with how that works (i'd be surprised if they did, but if you say so)
I'm pretty certain disabling app-disabling would cause the device to fail the compliance test suite. There's a test that's supposed to check that.
That did not stop RSA from including NSA's compromised random number generator and making it the default selection. Maybe their alternatives included a secret court order, NSL, or being paid 10 million dollars.
Indeed it didn't. Idiots. $10M appeared to do the trick. Though they did apparently take the money and adopt the PRNG before it was realized that it was likely backdoored, and before we realized that the NSA had abandoned their mission to improve US COMSEC.
If someone gains root, they can swap out the on-disk boot image that contains the kernel, and wait for someone else to reboot it as part of normal maintenance.
Assuming there isn't something that prevents the boot image from being replaced. See my other, more extensive, comment in this thread.
But what you're saying is that rebooting is somehow a magic cure-all that guarantees the system isn't infected somehow
Don't be condescending. I'm not saying rebooting is a magic anything.
Whether or not this matters depends on the threat model and why the attacker is interested in patching the kernel. For example, one purpose would be to disable other kernel security features, such as SELinux, or dm-verity. Most SELinux rules are configured and the configuration can be altered by root, but some are compiled into the kernel and can only be modified by modifying the kernel. Altering the persistent kernel image may not be possible for a variety of reasons (read-only media, SecureBoot, etc.). In addition, in security-sensitive and mission-critical contexts an unexpected reboot may well be noticed.
I don't understand your assertion about SecureBoot. Are you referring to some known vulnerability of some particular secure boot system? Given a decent implementation of secure/verified boot, an attacker should not be able to convince the system to boot a modified kernel image, which means that run-time modification of the kernel is the only option if the attacker needs to bypass some kernel security enforcement.
In general, the security model of a high-security Linux system assumes that the kernel is more trustworthy than root. The ability for root to modify the running kernel invalidates this assumption, which most definitely is a security issue.
In the context of a system without mandatory access controls there may not be any reason to care, since once an attacker has obtained root there probably isn't any limit to what he can do.
It's no more a risk than current patching that requires a reboot, except that you don't have the downtime of a reboot.
Sure, if your concern is error, rather than malice. An attacker who gains root could use this to dynamically patch a backdoor into the running kernel. Rebooting the machine would potentially enable someone to notice.
As another poster noted, though, you can already dynamically patch the kernel for malicious purposes by loading a malicious module, assuming that hasn't been disabled. In contexts where security is crucial, I would disable both dynamic module loading and run-time patching.
I assume the communication companies were handing over a lot more than the NSLs can demand in the spirit of cooperation and that is why the retroactive immunity was necessary
The GP wasn't suggesting that excessive data was handed over, he said that an NSL could be used to demand installation of a backdoor. If I were a vendor, even one who really wanted to be cooperative, I'd balk at that, because the chances of something like a backdoor being discovered are too high. It would be actively sabotaging my customers, and not just to the NSA... a backdoor can't distinguish between users, it lets in anyone who figures it out. And, of course, if the existence of the backdoor were published it would do serious damage to my business.
Even companies who want to cooperate are going to be reluctant to do potentially business-destroying favors for the government. There would be a great deal of incentive to fall back on the law and refuse on the grounds that the law doesn't authorize such requests.
I'm skeptical that an Android device would survive running flat out for two years to crack a PIN. The heat and battery life issues I experienced when I tested it demonstrate clearly that mobile devices simply aren't designed to run full-speed 24x7.
Also, it should be pointed out that the attack I described is far from easy to carry out. Among other things, it requires dumping the contents of flash, which basically requires removing the flash chips from the mainboard without damaging it, then either putting the flash chips back or installing new flash, then the device must be unlocked, a custom, hostile OS flashed, and finally the attacker can start the multi-year process.
Note that the 630-day figure I cited is on average. It would take twice that long for a guaranteed break.
Finally, if you add one more character to your passcode (7-character alphanumeric), the crack time jumps from 630 days on average to 124 years.
I agree that Lollipop FDE still needs some improvement, but it's already quite good.
Civil disobedience has ALWAYS carried the potential for punishment and if you break the law to make your point that the law is unjust you should stand ready to be arrested, imprisoned and tried in court for what you choose to do.
Your argument would carry more weight if the government who'd be trying Snowden weren't the same one he outed for violating its own laws, with the active collaboration of its judicial branch. Not to mention all of the recent fully-public sidestepping of due process for hundreds of other enemy combatants. Oh, and the torture, including of US citizens. And... do I really need to go on?
Snowden has extremely good reason to be skeptical of the fairness of a trial... or if he'd even get a real trial.
Snowden may be using what leverage he has left. He has not yet disclosed all the information he obtained so the US government might cut a deal to avoid further disclosures.
I see no evidence that Snowden didn't hand everything over to the Guardian et al, all at once, as he said he did. On what do you base your claim that he's still got something left?
Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.
1) Good but not as good as C.
In most cases these days it's a distinction without a difference.
2) But it's an unnecessary third layer. Obj-C has the objects. C has the speed and compatibility. What do you need a third layer for?
I see this differently. Obj-C has the objects I need to interact with the framework. C++ has the speed, compatibility and expressive power I want. C has speed and compatibility, but lacks expressive power, which creates a lot of tedium and loses a lot of safety.
3) Indeed.
We agree on something :-)
So virtually no one uses it in this scenario.
Only time I see it used is when it's a library that was written in C++ on another platform and is simply being used on a Mac.
I haven't really done much on Macs, but I did a lot of work on NeXTstep back in the day, and C++ was quite common in scientific computing there. Actually, what I saw a lot of was "Objective-C++"... they may have grown further apart, to the degree that this no longer works, but in the early 90s gcc allowed you to mix Objective-C and C++ constructs freely in the same code. So a common approach was to build everything in an OO fashion, but to choose between Objective-C and C++-style classes based on performance and flexibility tradeoffs. The result required you to be fluent in both, but that really just means being fluent in C++ because a C++ programmer can learn Objective-C in a day (which is something I respect about the language).
You're dropping out of Obj-C for cross platform compatibility, because you're dealing with a low level Apple API, or because you want maximum speed for some part of the code. All these things are usually best served by C.
Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.
Unless you're concerned that you may need to target a platform not supported by a decent C++ compiler (which is really rare, given that gcc is basically everywhere), the only reason to choose C over C++ is personal preference or concern that some of the users of the code may not know C++.
The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock.
No, it doesn't. At least in Lollipop FDE-password is separate and you enter it at boot.
It's not separate. In stock Lollipop there is only one password, and it's used both for FDE and for screen unlock. Some customized ROMs (e.g. CM) have separated it, which allows you to choose a strong boot password and a more convenient unlock password. Stock Android didn't go that direction because too many users would set a strong boot password which they only use once every few weeks and therefore forget, losing all of their data.
Had I jumped to the Nexus 6 at the same time, however, that may not have been an issue.
As a recent Nexus 6 owner, I can confirm that encryption is enabled by default. I have not noticed any performance lag and the battery life has been really good. I will admit, I'm coming from an 'ancient' phone, so maybe that's why I think it's fast enough; way faster than my old phone.
As mentioned by Gaygirlie, a big factor is the AES-NI instruction in the ARMv8 instruction set supported by your Nexus 6. It dramatically reduces the performance and power hit of AES operations.