You can build a sophisticated cypher that does not require polynomials, massive primes or any of the stuff that RSA uses
That stuff is for secure key exchange over an untrusted channel. The actual ciphers that are used to process the bulk of the data is not much more complicated than what you describe. You can look up the algorithms for RC4, AES, and blowfish.
Create a two dimensional array each dimension being 64K in size of 64 bit integers (...) If you exhaust the length of the key simply wrap it around.
Several big problems with that:
1. You'll need to calculate 2^32 (4 billion) 64-bit entries, i.e. 32 GiB, which is a lot of CPU time and memory if you just wanted to encrypt 10 kB of plaintext. (I'm not completely sure how you want to implement it; maybe you "only" need to calculate 64 k random values for each word of plaintext).
2. You need a really good (cryptographic-grade) random generator. If you have one, you could just as well use it directly - it's called "stream cipher".
3. If you wrap around your 32 GiB "two-time" pad over a low-entropy plaintext source, it is broken, since you can xor the plaintext at offset 0 with itself at offset 32 GiB to cancel out the pad. If you know that the message is plain English language, that may be enough reconstruct the two plaintext messages. [English has about 1 bit of entropy per character; xoring two texts with itself wlil result in about 2 bits of entropy per byte (8 bits) of message.]
4. If you encrypt two plaintext messages with the same key, your encryption is broken, for the same reason as under #3.
RC4 is simple, it's fast, (...) and it is *broken*.
It's only provably broken if you don't use the straightforward workaround for its weakness, i.e., discarding the first few hundred bytes (2 KiB to be on the safe side) of cipher stream. This was a problem in WEP encryption and may be a problem in the SSL implementation (not sure about today's status) and it kind of negates the speed advantage if RC4 is used for transmitting short messages. But run ssh with RC4 (it will drop the first 2 kB of the key stream) for large file transfers and you're safe and fast.
TL;DW: if the pilots are incapacitated, the cabin crew can punch a code to save the day; the door will unlock after 30 seconds unless the pilot pushes the button to deny access. (the pilots are alerted by a beeping signal.) Actually, a pretty sensible way to do it.
"like that will collect dust in megaton quantities. And you can't hard-seal the device away to avoid moisture because it'll overheat in short order."
Dust and moisture are being mentioned again and again here. I don't get that. Most dust is generated in places where humans shed skin flakes, rub clothes, and walk over carpets. Where does all that dust come from in a crawlspace? From that tiny amount of airflow? Spores of massive fungal growth? (then you have another problem to deal with first).
As for humidity: a running server will always be slightly higher in temperature than the environment. I don't see how water vapor that has been flowing along lots of cooler surfaces can condense on the server. It would only be a problem if you put the server very close to a ventilation opening, if warm humid air enters from there. Or if condensation is actually dripping from the crawlspace ceiling, onto the server.
"That would reduce the fans work (and their own heat!)"
Years ago, I bought a Shuttle barebones Pentium 4 with a heat pipe, hoping that it would be as quiet as the Mac Minis of the time. It was disappointing. It saved having separate CPU and PSU fans and it was a bit less noisy than the average beige box pc, but still very noticeable.
A problem with heat pipes is that they are not flexible, so the motherboard, case-mounted fan, and heat pipe must match exactly. Not so suitable for do-it-yourself pc building. And in order to reduce noise, you still need to spread the heat over a large surface, i.e. attach a lot of lamellas to the heat pipe, that you could just as well have attached directly onto the cpu cooler.
ClockworkMod (if that's what you mean by "Stock CM" bootloader) on my older Android-2.3 device has an option "Backup", which will write a backup of/data on the removable SD card; I don't even need to connect over adb (but if I try, it doesn't complain). Maybe this has changed with more recent CWM releases, but for me this was a major reason to encrypt/data on all my Android 4.x devices that run CM.
I'm using TWRP because CWM cannot handle an encrypted data partition, so it has nowhere to store the new ROM image on devices without a physical unencrypted SD card. TWRP will happily accept an ADB connection from an unknown device. (Just to make sure: I just revoked all ADB authentications, rebooted into Fastboot (Power+Volume), selected Recovery, and connected over adb.) Anyway, because the device is encrypted with a long passphrase, I don't care that much.
If a watch is watertight for 50 m static water pressure, then it is also watertight for 45 m static water pressure in combination with an enormous amount of dynamic pressure. So that cannot be the reason why usually the depth ratings are translated as "splash proof" (30 m), "you can swim" (50 m), and "you can dive to the bottom of the swimming pool" (100 m).
You also need to take into account peak water pressures; the rating is measured as a static object in water, doing something like diving into a swimming pool subjects the watch to significantly more water pressure
That's a common misconception. The dynamic pressure is additive (not multiplicative) and amounts to about 0.5 rho v^2, where rho=1000 kg/m3 is the densitiy and v the velocity. For example, at v = 10 m/s, the added dynamic pressure is 50 kPa, equivalent to only 5 m extra depth under water.
The rotation speed of a wind turbine is not proportional to wind speed. It typically increases a bit with wind velocity, but not so much. A large turbine with 70 m rotor blades that make one turn per 5 seconds already reaches such tip velocities.
"50m or 100m, which are adequate for any practical purpose. Above that you're paying for fantasy value. Watches rated at 200m and above might as well claim a gazillion meters; you'll never be the wiser."
I thought that these ratings have more to do with the reliability/longevity. At least, I've owned two 300 euro "100m" Seiko watches that lost their water-tightness over the course of a few years, because the seals of the crown degraded from exposure to sweat, soap, and the occasional sea water. Repairs were quoted as 150 euros, so I didn't bother.
With a rainbow table you can brute-force a password if you know the password hash. You need only one login attempt -- and you need the hash, for which you normally need root access to start with, at least for the last 20 years. Unix/Linux passwords have always been stored as salted hashes, which makes rainbow tables not practical. The practical way to brute-force a password is therefore a dictionary attack.
If we ever do invent time travel, I figure it's going to be routine for people to show up from the future for important historical events and discover they're an hour off.
And image that you have the right location, and you discover upon arrival that you missed Planet Earth some 100,000 km in its orbit around the sun and you see it around the size of a fist at an arm's length as you suffocate...
Locking the bootloader only prevents replacing the bootloader. For both the TWRP and the ClockworkMod boot loaders: locking does not prevent going into the bootloader (on devices that let you do this by pressing the volume button on power on, such as the Nexus 5 and Nexus 7 (2012)) and making a backup of the data partition, e.g. onto an SD card. Moreover, ClockworkMod cannot handle encrypted data partitions, which seems to make it impossible to do upgrades on a device without SD card. TWRP does support encryption, but it does not do adb authentication.
I don't see your point about killing recovery options. With an encrypted device, it's still possible to do a factory reset. With an encrypted device + TWRP, you can even make a backup of the data partition. (My N7-2012 with stock Android corrupted the encrypted data partition on upgrade to Lollipop; only way out was a factory reset. Grrr. I flashed CyanogenMod+TWRP+encryted data, but the bug in the flash memory controller hit me and made the whole tablet unbearably slow. Grrrr!)
if it happens on every mail sync, podcast download
In that case, the bottleneck is the data transfer over Wifi or 3G. At least, I'm pretty sure that I never reach 27 MiB/s (270 Mbit/s) data transfer rates. The wake time will not be affected in such cases. I think it's only activities such as app startup and media indexing that are affected by slow storage bandwidth.
And otherwise, encryption is really a must for me. With a custom ROM and bootloader (and no encryption), it's too easy for someone else to extract all personal data from the device, including credentials for my Gmail account and my banking app, both of which can have actual financial consequences.
Whether in hardware or software, it's still a fair amount of computation, which means battery usage and latency.
I wouldn't be so sure about that. Android will only encrypt the/data partition, not/system. That's why you can still do a factory reset on an encrypted device. I'd guess that a lot of the I/O is in/system.
Anyway, here is a 100 MiB write test (Nexus 5, Cyanogenmod 11, Android 4.4, rooted), to the/data ("sdcard") partition and to/cache (not encrypted):
sync; sync time sh -c 'dd if=/dev/zero of=/sdcard/foo.bin bs=1048576 count=100; sync; sync' 3.67 seconds sync; sync time sh -c 'dd if=/dev/zero of=/cache/foo.bin bs=1048576 count=100; sync; sync' 2.13 seconds
At 27 MiB/s versus 47 MiB/s it seems to be fast enough for me. Most apps are below 15 MB (apk size).
On a low-end, but fairly recent, LG L40/D165 phone, it's 11.2 seconds for a 100 MB encrypted write. (No root here, so I can't write to/cache for comparison). Still fast enough for me.
Cyanogenmod 11 (Android 4.4.4) indeed has an option to set the encryption password separately. With stock Android this only possible on a rooted device (vdc cryptfs changepw [secretpassword1]), but the encryption password will be reset if you change the screen unlock code.
But with your point about the coating, I'm only off by a factor of ten...
1000 times smaller beam diameter means 10^6 times higher irradiance. With 1% absorbance it's still a factor 10^4 off.
how much power do we really need on target to make it overheat given that it's designed to cycle between daylight and night
The solar panels are designed to receive 1500 W/m2 irradiance from the sun, of which maybe 500 W/m2 comes out as electricity and the other 1 kW/m2 is heat load. A black-body radiator against 4 K background temperature on one side and earth (279 K) on the other side will reach an equilibrium temperature of 330 K (57 C). To heat the solar panel to a damaging 150 C (just a guess), you'd need about 2.5 kW/m2 extra (on top of the solar irradiance).
It wouldn't surprise me if the back side of the solar panels is used as a radiative heat exchanger to get rid of the heat generated inside the body of the satellite. The gold-coated foil around the satellite body acts as a kind of thermos bottle to insulate the electronics inside from extreme temperature swings, but still the electronics need to get rid of its own dissipation, so you would not only destroy the solar panels but indirectly also the electronics.
I doubt that it's practical to aim specifically for the solar panels for an object that's travelling at 7 km/s, with a mechanism that can do that within 1 microrad. It might be more practical to have a 10 m diameter spot size, which would require 250 kW, which might be doable with a CO2 laser at 10.6 micrometer wavelength (the atmosphere seems to be fairly transparent at that wavelength).
If the solar panels have a mass of 15 kg/m2 (just a guess), then you would need to maintain this 2.5 kW/m2 for about 10 minutes, over which time the satellite will be travelling 4200 km. This doesn't sound easy...
"A 1um laser fired out of a 1m aperture spreads to an 800m circle at an altitude of 800km"
You're off by a factor 1000. The divergence is about 1e-6 rad, which makes 0.8 m diameter at 800 km.
Now another issue is that satellites tend to be wrapped in gold-coated foil, which will reflect 99% of the light at 1 micrometer. It would be difficult to overheat the body of the satellite, although the solar panels might be damaged more easily.
Having a conflict of interest is understandable; hiding a conflict of interest is problematic.
The strange thing is that his management (Alcock and Kress) is claiming that they were unaware of his funding. The research grants pass through the accounting department of the institute, right? Large sums of money deposited onto or withdrawn from the institute's bank account need to have proper paperwork in place and be signed off by the management? His management must have been actively looking the other way.
It has been possible for decades to recover serial numbers by chemical etching, which is sensitive to changes in the crystal structure. All you need is a polishing implement and a bottle of etching gel. What is the added value of this EBSD technique? I can see a big disadvantage: you need equipment (a scanning electron microscope) worth a few hundred kEUR and the object with the erased serial number needs to fit into the vacuum chamber of said equipment.
The article mentions that etching techniques don't always work, but they don't state that their technique does work on samples for which the etching method doesn't work...
Slashdot Mirror
Like these or this one?
What's the difference between "mobile CPU" and "laptop CPU"? In any case, most 4th generation i3 mobile/laptop CPUs don't support AES-NI, nor do the current Intel Celeron CPUs. Many of those have been released as recently as 2014, so I would count them as "modern".
That stuff is for secure key exchange over an untrusted channel. The actual ciphers that are used to process the bulk of the data is not much more complicated than what you describe. You can look up the algorithms for RC4, AES, and blowfish.
Several big problems with that: 1. You'll need to calculate 2^32 (4 billion) 64-bit entries, i.e. 32 GiB, which is a lot of CPU time and memory if you just wanted to encrypt 10 kB of plaintext. (I'm not completely sure how you want to implement it; maybe you "only" need to calculate 64 k random values for each word of plaintext). 2. You need a really good (cryptographic-grade) random generator. If you have one, you could just as well use it directly - it's called "stream cipher". 3. If you wrap around your 32 GiB "two-time" pad over a low-entropy plaintext source, it is broken, since you can xor the plaintext at offset 0 with itself at offset 32 GiB to cancel out the pad. If you know that the message is plain English language, that may be enough reconstruct the two plaintext messages. [English has about 1 bit of entropy per character; xoring two texts with itself wlil result in about 2 bits of entropy per byte (8 bits) of message.] 4. If you encrypt two plaintext messages with the same key, your encryption is broken, for the same reason as under #3.
It's only provably broken if you don't use the straightforward workaround for its weakness, i.e., discarding the first few hundred bytes (2 KiB to be on the safe side) of cipher stream. This was a problem in WEP encryption and may be a problem in the SSL implementation (not sure about today's status) and it kind of negates the speed advantage if RC4 is used for transmitting short messages. But run ssh with RC4 (it will drop the first 2 kB of the key stream) for large file transfers and you're safe and fast.
"Why would the cabin crew have the code? The code is for the pilots."
Here is airbus's own explanation: http://m.youtube.com/watch?v=R...
TL;DW: if the pilots are incapacitated, the cabin crew can punch a code to save the day; the door will unlock after 30 seconds unless the pilot pushes the button to deny access. (the pilots are alerted by a beeping signal.) Actually, a pretty sensible way to do it.
"like that will collect dust in megaton quantities. And you can't hard-seal the device away to avoid moisture because it'll overheat in short order."
Dust and moisture are being mentioned again and again here. I don't get that. Most dust is generated in places where humans shed skin flakes, rub clothes, and walk over carpets. Where does all that dust come from in a crawlspace? From that tiny amount of airflow? Spores of massive fungal growth? (then you have another problem to deal with first).
As for humidity: a running server will always be slightly higher in temperature than the environment. I don't see how water vapor that has been flowing along lots of cooler surfaces can condense on the server. It would only be a problem if you put the server very close to a ventilation opening, if warm humid air enters from there. Or if condensation is actually dripping from the crawlspace ceiling, onto the server.
"That would reduce the fans work (and their own heat!)"
Years ago, I bought a Shuttle barebones Pentium 4 with a heat pipe, hoping that it would be as quiet as the Mac Minis of the time. It was disappointing. It saved having separate CPU and PSU fans and it was a bit less noisy than the average beige box pc, but still very noticeable.
A problem with heat pipes is that they are not flexible, so the motherboard, case-mounted fan, and heat pipe must match exactly. Not so suitable for do-it-yourself pc building. And in order to reduce noise, you still need to spread the heat over a large surface, i.e. attach a lot of lamellas to the heat pipe, that you could just as well have attached directly onto the cpu cooler.
ClockworkMod (if that's what you mean by "Stock CM" bootloader) on my older Android-2.3 device has an option "Backup", which will write a backup of /data on the removable SD card; I don't even need to connect over adb (but if I try, it doesn't complain). Maybe this has changed with more recent CWM releases, but for me this was a major reason to encrypt /data on all my Android 4.x devices that run CM.
I'm using TWRP because CWM cannot handle an encrypted data partition, so it has nowhere to store the new ROM image on devices without a physical unencrypted SD card. TWRP will happily accept an ADB connection from an unknown device. (Just to make sure: I just revoked all ADB authentications, rebooted into Fastboot (Power+Volume), selected Recovery, and connected over adb.) Anyway, because the device is encrypted with a long passphrase, I don't care that much.
If a watch is watertight for 50 m static water pressure, then it is also watertight for 45 m static water pressure in combination with an enormous amount of dynamic pressure. So that cannot be the reason why usually the depth ratings are translated as "splash proof" (30 m), "you can swim" (50 m), and "you can dive to the bottom of the swimming pool" (100 m).
That's a common misconception. The dynamic pressure is additive (not multiplicative) and amounts to about 0.5 rho v^2, where rho=1000 kg/m3 is the densitiy and v the velocity. For example, at v = 10 m/s, the added dynamic pressure is 50 kPa, equivalent to only 5 m extra depth under water.
The rotation speed of a wind turbine is not proportional to wind speed. It typically increases a bit with wind velocity, but not so much. A large turbine with 70 m rotor blades that make one turn per 5 seconds already reaches such tip velocities.
"Also, if a bird is so stupid to get killed by a relatively slow moving wind turbine, I would consider: Darwin at work."
It only appears to be slow if you're watching from a distance. The tip speed can reach 320 km/h (200 mph).
"50m or 100m, which are adequate for any practical purpose. Above that you're paying for fantasy value. Watches rated at 200m and above might as well claim a gazillion meters; you'll never be the wiser."
I thought that these ratings have more to do with the reliability/longevity. At least, I've owned two 300 euro "100m" Seiko watches that lost their water-tightness over the course of a few years, because the seals of the crown degraded from exposure to sweat, soap, and the occasional sea water. Repairs were quoted as 150 euros, so I didn't bother.
Now I have a a Pebble.
With a rainbow table you can brute-force a password if you know the password hash. You need only one login attempt -- and you need the hash, for which you normally need root access to start with, at least for the last 20 years. Unix/Linux passwords have always been stored as salted hashes, which makes rainbow tables not practical. The practical way to brute-force a password is therefore a dictionary attack.
And image that you have the right location, and you discover upon arrival that you missed Planet Earth some 100,000 km in its orbit around the sun and you see it around the size of a fist at an arm's length as you suffocate...
Locking the bootloader only prevents replacing the bootloader. For both the TWRP and the ClockworkMod boot loaders: locking does not prevent going into the bootloader (on devices that let you do this by pressing the volume button on power on, such as the Nexus 5 and Nexus 7 (2012)) and making a backup of the data partition, e.g. onto an SD card. Moreover, ClockworkMod cannot handle encrypted data partitions, which seems to make it impossible to do upgrades on a device without SD card. TWRP does support encryption, but it does not do adb authentication.
I don't see your point about killing recovery options. With an encrypted device, it's still possible to do a factory reset. With an encrypted device + TWRP, you can even make a backup of the data partition. (My N7-2012 with stock Android corrupted the encrypted data partition on upgrade to Lollipop; only way out was a factory reset. Grrr. I flashed CyanogenMod+TWRP+encryted data, but the bug in the flash memory controller hit me and made the whole tablet unbearably slow. Grrrr!)
In that case, the bottleneck is the data transfer over Wifi or 3G. At least, I'm pretty sure that I never reach 27 MiB/s (270 Mbit/s) data transfer rates. The wake time will not be affected in such cases. I think it's only activities such as app startup and media indexing that are affected by slow storage bandwidth.
And otherwise, encryption is really a must for me. With a custom ROM and bootloader (and no encryption), it's too easy for someone else to extract all personal data from the device, including credentials for my Gmail account and my banking app, both of which can have actual financial consequences.
I wouldn't be so sure about that. Android will only encrypt the /data partition, not /system. That's why you can still do a factory reset on an encrypted device. I'd guess that a lot of the I/O is in /system.
Anyway, here is a 100 MiB write test (Nexus 5, Cyanogenmod 11, Android 4.4, rooted), to the /data ("sdcard") partition and to /cache (not encrypted):
At 27 MiB/s versus 47 MiB/s it seems to be fast enough for me. Most apps are below 15 MB (apk size).
On a low-end, but fairly recent, LG L40/D165 phone, it's 11.2 seconds for a 100 MB encrypted write. (No root here, so I can't write to /cache for comparison). Still fast enough for me.
Cyanogenmod 11 (Android 4.4.4) indeed has an option to set the encryption password separately. With stock Android this only possible on a rooted device (vdc cryptfs changepw [secretpassword1]), but the encryption password will be reset if you change the screen unlock code.
"Our average ting bill is So with proper management"
Looks like slashcode ate the less-than sign and the rest of the paragraph...
1000 times smaller beam diameter means 10^6 times higher irradiance. With 1% absorbance it's still a factor 10^4 off.
The solar panels are designed to receive 1500 W/m2 irradiance from the sun, of which maybe 500 W/m2 comes out as electricity and the other 1 kW/m2 is heat load. A black-body radiator against 4 K background temperature on one side and earth (279 K) on the other side will reach an equilibrium temperature of 330 K (57 C). To heat the solar panel to a damaging 150 C (just a guess), you'd need about 2.5 kW/m2 extra (on top of the solar irradiance).
It wouldn't surprise me if the back side of the solar panels is used as a radiative heat exchanger to get rid of the heat generated inside the body of the satellite. The gold-coated foil around the satellite body acts as a kind of thermos bottle to insulate the electronics inside from extreme temperature swings, but still the electronics need to get rid of its own dissipation, so you would not only destroy the solar panels but indirectly also the electronics.
I doubt that it's practical to aim specifically for the solar panels for an object that's travelling at 7 km/s, with a mechanism that can do that within 1 microrad. It might be more practical to have a 10 m diameter spot size, which would require 250 kW, which might be doable with a CO2 laser at 10.6 micrometer wavelength (the atmosphere seems to be fairly transparent at that wavelength).
If the solar panels have a mass of 15 kg/m2 (just a guess), then you would need to maintain this 2.5 kW/m2 for about 10 minutes, over which time the satellite will be travelling 4200 km. This doesn't sound easy...
"A 1um laser fired out of a 1m aperture spreads to an 800m circle at an altitude of 800km"
You're off by a factor 1000. The divergence is about 1e-6 rad, which makes 0.8 m diameter at 800 km.
Now another issue is that satellites tend to be wrapped in gold-coated foil, which will reflect 99% of the light at 1 micrometer. It would be difficult to overheat the body of the satellite, although the solar panels might be damaged more easily.
Is there enough minable indium on earth to allow mass production of InGaAs-based devices? The world production is just a few 100 tonnes per year.
The strange thing is that his management (Alcock and Kress) is claiming that they were unaware of his funding. The research grants pass through the accounting department of the institute, right? Large sums of money deposited onto or withdrawn from the institute's bank account need to have proper paperwork in place and be signed off by the management? His management must have been actively looking the other way.
It has been possible for decades to recover serial numbers by chemical etching, which is sensitive to changes in the crystal structure. All you need is a polishing implement and a bottle of etching gel. What is the added value of this EBSD technique? I can see a big disadvantage: you need equipment (a scanning electron microscope) worth a few hundred kEUR and the object with the erased serial number needs to fit into the vacuum chamber of said equipment.
The article mentions that etching techniques don't always work, but they don't state that their technique does work on samples for which the etching method doesn't work...