I think it's also probably an issue of trust. If someone isn't in front of you banging on their keyboard you have no assurance that they're actually doing work.
The solution is really to use communication tools like Slack and also put the focus on deliverables instead of "work units".
I sit corrected. Instead, the current typical approach is to use cross-breeding to produce seeds that grow well the first generation and don't produce reliable seeds themselves.
That is misleading, as the goal of that cross-breeding is not to produce unreliable seeds, but in order to produce better results. Look up "hybrid vigor" for details on this. Nothing about the cross-breeding is done in order to hinder re-use of the seeds, it's just that naturally non-hybrid seeds are less effective.
As I understand it, the idea is to have two parent lines that when produce the desired traits in heterozygous offspring but not in second-generation offspring. Sort of a Mendelian DRM.
This is incorrect. As I already stated: the cross-breeding is to take advantage of hybrid vigor[1], it is not an effort to intentionally hamper successive generations. This same practice occurs in non-GMO, non-patented plant breeding, and has been done for over a hundred years[2]
Password managers usually have a way to add serial numbers or secure notes, that's where I store mine. And you should be using a password manager anyway, if you aren't already.
The only way to bypass the brute forcing delay would be to increase computing power, since it's a function of the encryption method used. It basically goes through a number of iterations chosen to make it take about 80 ms per attempt.
Nope, because everything is ultimately dependent on the hardware key in the Secure Enclave and the user's passcode, neither of which Apple has knowledge of. The FBI would be able to create the OS, but they wouldn't be able to load it on the device without erasing it. It's really a brilliant system.
>Nope, because everything is ultimately dependent on the hardware key in the Secure Enclave
The phone in question is an iPhone 5C which does not have a Secure Enclave, only a burned-in hardware ID.
It's also worth pointing out that there's no clear evidence that the Secure Enclave must clear all keys as part of a SE firmware update (just speculation that this would be reasonable).
It doesn't quite work that way. The files on the device are ultimately encrypted with a dependency on both the hardware key in the Secure Enclave and the user's passcode. It's impossible to update the firmware without both pieces of information or erasing the device, and on A7 or later processors the unlock attempt delay is a direct result of the method of encryption used and tied to the hardware so it must be performed on the device itself.
Do we have any documentation that indicates it's impossible to do firmware updates without the user's passcode? That's what the government seems to believe that it could (at present) do, given Apple's cooperation. The iOS Security Guide doesn't seem to address that particular point.
It's possible to reflash the firmware in DFU mode, but it requires erasing the data on the phone. Or more technically, there's an encryption key in storage that needs to be regenerated to give access to the filesystem, but that encryption key (in conjunction with the hardware key in the Secure Enclave and the user's passcode, if set) is also necessary to read any user data on the phone.
Are you saying the article is wrong or did you not read it?
"As many jailbreakers are familiar, firmware can be loaded via Device Firmware Upgrade (DFU) Mode. Once an iPhone enters DFU mode, it will accept a new firmware image over a USB cable. Before any firmware image is loaded by an iPhone, the device first checks whether the firmware has a valid signature from Apple. This signature check is why the FBI cannot load new software onto an iPhone on their own — the FBI does not have the secret keys that Apple uses to sign firmware."
<spoon feed>
At this point it is very important to mention that the recovered iPhone is a 5C. The 5C model iPhone lacks TouchID and, therefore, lacks the single most important security feature produced by Apple: the Secure Enclave.
In these older devices, there are still caveats and a customized version of iOS will not immediately yield access to the phone passcode. Devices with A6 processors, such as the iPhone 5C, also contain a hardware key that cannot ever be read and also “tangle” this hardware key with the phone passcode. However, there is nothing stopping iOS from querying this hardware key as fast as it can. Without the Secure Enclave to play gatekeeper, this means iOS can guess one passcode every 80ms.
</spoon feed>
And even if it did have a Secure Enclave, from page 5 of your link:
When an iOS device is turned on, its application processor immediately executes code
from read-only memory known as the Boot ROM. This immutable code, known as the
hardware root of trust, is laid down during chip fabrication, and is implicitly trusted.
The Boot ROM code contains the Apple Root CA public key, which is used to verify that
the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load. This is
the first step in the chain of trust where each step ensures that the next is signed by
Apple. When the LLB finishes its tasks, it verifies and runs the next-stage bootloader,
iBoot, which in turn verifies and runs the iOS kernel.
So the LLB is run first, and could be used to contact the Secure Enclave and guess passwords.
And from the article:
At this point you might ask, “Why not simply update the firmware of the Secure Enclave too? That way, Apple could disable the protections in iOS and the Secure Enclave at the same time.” (crossed out)Although it is not described in Apple iOS Security Guide, it is believed that updates to the Secure Enclave wipe all existing keys stored within it. An update to the Secure Enclave is therefore equivalent to erasing the device.(/crossed out) I initially speculated that the private data stored within the SE was erased on update but I now believe this is not true. After all, Apple has updated the SE with increased delays between passcode attempts and no phones were wiped. In all honestly, only Apple knows the exact details.
So, it may be that Apple does have a backdoor to upgrade the SE. Only Apple (and maybe other state actors) really know this. So, it certainly isn't as cut and dried as you imply, if the device did have a Secure Enclave.
But, in this case, the device does not have a SE, so it is clear that with Apple's keys the device could be, with a practical amount of effort, be hacked.
It would mean that there are a lot more black holes in our local group, which could be a little concerning.
But yeah that's actually an application of LIGO once it's sensitive enough, because gravitational waves travel through just about anything including those annoying dust clouds :)
From what I understand, it doesn't really matter because the laser light acts as a coherent wave, so it doesn't really bounce off of individual atoms, per se. As long as the mirrors are flat, all that matters is the relative distance between the mirrors.
The solution is really to use communication tools like Slack and also put the focus on deliverables instead of "work units".