The problem is, like anti-personnel mines, they give a military advantage of the country using them. Once the AI is down pat, sentry robots that are ran into a battlefield and perforate anything that moves that doesn't give a "I'm a friend" code are the ideal way to grab and hold territory. They work 24/7, don't give bad PR if one of the sentry robots gets destroyed, and many robots can be deployed cheaply. Combine these with a decent power source, and a bunch of these could hold territory for years.
Now, add drones into the equation, be it ones that are solar powered, stay aloft indefinitely and just zoom and fly into the target, or more UACVs.
Even with a treaty, governments will still use these... there are too many advantages.
There might be an algorithm C which is equivilent to (A(B()). However, the chance of that is quite unlikely, especially if a proper implementation of the cipher is used (CBC, for example, or XEX), it makes this almost impossible... likely less than the chance of brute forcing the key.
As for reusing keys, if one has three different algorithms (AES, Twofish, and Serpent), three different keys should be used. This ensures that if one of the algorithms coughs up a key somehow, the other two are still working.
The more it is used, the more often it can be leaked. There is also a priority of how useful a backdoor is. Being able to covertly compromise the head of an enemy state or terror organization's phone for high value intel is one thing. Being able to take phones from protestors arrested en masse to slurp off the goodies in mass quantities is another.
Even the suspicion of a backdoor will get people working on steps to mitigate it, be it having apps that require a passcode before they run and doing the encryption themselves with their own encryption libraries, to people simply turning off their devices when they are not in use and slipping them into a grounded metal box when on trips.
In theory, Apple and Samsung have a lot more to lose. Apple especially, since their reputation as a phone provider rides on how secure their devices are, and if something is discovered, there are many rivals who will be happy to take the loss. Samsung, similar.
Huawei? Not as much, as they are in a different market segment.
Having two algorithms result in an unxpected third transformation is called a "group". Realistically, with TrueCrypt/VeraCrypt's cascades, you are not getting 3*256, or 768 bits, but somewhere between 258 bits and 768 bits. There is a lot of advanced crypto study on this, especially if one algorithm when used may weaken the second algorithm used after that. However, 99.99999% of the cryptographic breaks tend to be along the lines of weak key management and storage, or failure to implement existing algorithms in a secure fashion.
The zero expectation of data privacy has come at us from many fronts, be it the "free" services where the subscriber is the product, not the customer, the fact that data is valuable, where VCs only will give money to businesses which sling ads and suck analytics.
With the fact that who knows what people/entities have access to remotely stored data, coupled with the concern about some storage providers actively looking for "pirated" stuff, encryption isn't a luxury to "hide from the cops". It is a necessity for the basic functioning of business. Especially how easy it winds up being for an attacker to compromise accounts.
How can a screen or digitizer communicate to the outside world? It likely isn't on a bus where it can ask the radio or NIC to packetize stuff it feels like. At best, it can record taps on a screen, but getting those out would be a different story. Perhaps for physical snooping where the device is captured later on (say to glean someone's PIN), but for a remote attacker, it isn't that feasible.
Is TrustZone like a hypervisor, or is it like a LXC, managing containers/worlds? It would be nice if ARM supported VMs on the chip level with a standardized hypervisior.
I have some people try to do "AES 512" by chaining AES, or even doing triple AES (encrypt-decrypt-encrypt) like how triple DES was done. This is brain dead, and shows the person who wrote this doesn't have a clue about crypto.
Want more bits? Cascade different encryption algorithms, similar to how TrueCrypt/VeraCrypt does it. It is wise to use a multi-algorithm cascade anyway, because if one gets broken, there are two others. For asymmetric algorithms, same thing. Cascade RSA, some elliptic encryption, and maybe a lattice algorithm, and have each of them have a chunk of the key.
Writing security programs and doing the job right isn't trivial. Computing is littered with many, many broken and worthless crypto programs because of people trying to reinvent the wheel, making their own worthless algorithms, or implementing existing algorithms in a brain-dead manner (ECB, for example.)
Same here. I have things to do in life, and waiting outside a restaurant is not something I care to do. The ironic thing is that the places with long lines (Franklin's barbecue) are usually very overrated. Austin has a lot of eateries, and if needed, I can always drive to a surrounding town. If a place has a line outside, but is empty inside, I definitely will go somewhere else, because either the place just opened for the day or they are not bothering to serve customers... either way, there is an eatery just as good, if not better, somewhere else.
Then, there are Chinese and EU data privacy laws that may conflict with each other. One might want VPN data to be kept for later perusal by the government, the other demands the data be destroyed. With that conflict, coupled to it being a cost center, it is no wonder why Opera tossed that service.
A lock is a relatively simple device, where the states are obviously known. Devices like this should ship and not need firmware upgrades from the factory. There are many embedded subsystems that cannot or will not be upgraded, so the people who made them did it right the first time, and didn't follow the philosophy of "it builds, ship it."
A lock isn't rocket science. It also is the last thing you need fetching OTA updates. Instead, updates should be delivered via some physical means, if only to ensure someone is on site to test and verify functionality.
Making sure a device doesn't brick itself is not impossible. I have an older Nook tablet that, if it doesn't boot after eight times, it automatically reloads itself from its original firmware, just so the device is usable in some degree. With a deadbolt, you might want a more secure way of failing, so having multiple areas where ROMs are stored, so if it fails to boot, it goes back to a previous ROM. That way, it might grab some bad code and brick a few times, but once the failed update is off the servers, it would fetch a correct one and be fine.
Lesson learned from this... find a lock maker that treats their offerings as a security item, and not some throwaway IoT device.
I did a basic genetic algorithm project on this for a CS class. 100 cities, and it took about 90 seconds to chug out a working answer. Is it _the_ answer? Perhaps not. But it is good enough.
Dynamic libraries have been one way to save space for programs. Have a standard library that is tossed into a special shared area of the filesystem, hard link it so the apps can see it in their jail, and call it done. Obviously, the library would be signed.
Now comes the tough part. DLL hell. A WinSxS mechanism would be useful so apps that use different versions of a library would not conflict with each other.
Of course, the best solution would be filesystem level deduplication. If apps are stored encrypted on the device, then move to a dynamic library system and deduplicate the.so files.
This isn't the best solution, but it should significantly save space.
Easy fix... some type of transponder on the sign that is cryptographically signed and is GPS locked to a small area, so if the sign is moved beyond a few feet, it gets ignored by the vehicle. That way, a 30 changed to an 80 will be ignored. Not 100% secure, as someone can hack the private key, but it will stop mischief like this.
Before Eternal September, USENET didn't suffer fools/trolls gladly, and back then, all it took was a couple E-mails to abuse@troll-s.isp.com, and the admins got rid of them quickly, because having one's connections to other NNTP sites pulled was a very useful tool.
To boot, USENET posts will follow you forever. Last year, during a job interview, I actually had an interviewer pull up posts from the early 1990s I had in sci.crypt and alt.sex.cthulhu...
The niche for MP3 players has shrunk, pretty much because of this. For at home, one can buy a NAS with Plex for storing the terabytes of media (music, movies, etc.) For on the go, a smartphone can handle most music collections.
Right now, there are a few niches for MP3 players:
1: Inexpensive items for when one doesn't want to bring their smartphone along (jogging, gym, zombie hunting). 2: Something for the kids (where an iPod Touch is ideal, because it does everything a smartphone does, except make cell calls.) 3: A novelty item. There are some small cube shaped MP3 players which are worth having. 4: Something to have plugged into the stereo, so a copy of one's music is always there. 5: A backup authentication device (the iPod Touch I have saved my bacon when Authy decided to erase all 2FA info.) Having a device which is not connected to the Internet, except for brief periods allowed me to keep access to all my stuff.
However, the few niches are not a mass market anymore. Creative is completely out of the MP3 player market and has moved to speakers and other things.
The one niche that could possibly be useful is a market for "personal recovery devices". Things like an iPod Touch which store 2FA and password recovery info, and are kept offline, so if one loses their phone, they still have access to their Duo or Google Authenticator stuff.
My first "MP3" player was a Sony VAIO Music Clip, my second a Sony NW-MS7 Memory Stick Walkman which used MagicGate cards. At the time, they were nice and compact, easily taken places. Even today, the form factor is decent.
Of course, they were DRM-ed to Hell and gone. The Music Clip could take MP3 files, that were "wrapped" with Sony's ATRAC-whatever encryption. The other device had to have everything fully transcoded by the OpenMG software, which only ran under Windows 98. There was no copying files with this software. In fact, only three copies of each track were allowed, so one had to check in and check out music. Backing up your music collection? Good luck. Later OpenMG editions might allow backups... provided you called Sony for some restore key.
I went and bought a Creative Nomad 2. It came with a docking stand and was rechargable, even with an inline remote. No real DRM, although it was a bit clunky compared to the sleekness of the Sony players.
After that, my first HDD based MP3 player was a Creative Nomad Jukebox. Huge thing, six GB 2.5" HDD, would run for a few seconds off a set of four AA batteries, so it was more of a "plop by your computer to listen to stuff" than something portable. One could upgrade the HDD inside by using dd to copy off the first chunk of the drive which stored the player's OS... but one did run into a hard file count limit, so anything bigger than 12-20 gigs was pointless.
iPod-wise, my favorite iPod, just for unique value, would be the 6th generation iPod Nano. It was as close to a smartwatch as people had at the time.
It is a gamble. For a lot of users, having randomly generated passwords that are stuffed in a PW database is more secure than having them have "hunter2" for their bank, "swordfish" for their Facebook account, etc. The chance of a mass compromise of a Lastpass is definitely less than having one's password revealed to the world the next time some company's list of hashed PWs gets snarfed.
Even with the potential hazard, if combined with 2FA, the hazard of a compromised password is reduced significantly.
To boot, longer, hairier PWs can be used as well, as the user doesn't have to remember them.
There is also the fact that an EV uses zero energy (well, except for the climate control system, radio, and electronics) when stopped. An IC vehicle still burns fuel. This in itself is a major fuel saver.
At least with EVs, we can figure out what to use for electricity. If there is a new fusion development, it can be used and immediately change the CO2 profile across large areas. Similar if thorium reactors, or even Gen IV reactors become the norm. With IC engines, we have to replace them individually.
The trick is that we can keep improving. There is no single magic bullet, but if we replace a coal base plant with solar + energy storage, it helps things a little bit. Similar with adding wind capacity, instead of having to add a biomass plant.
I can name a number of file sharing services, both paid and free, which offer this functionality. It is nice to have a temporary file service that is part of a web browser and that (hopefully) doesn't require a ton of signing up and such. However, I wouldn't mind Mozilla focus on core things as well. Firefox, Servo, and Rust are useful, but SeaMonkey and Thunderbird are still important, as Thunderbird is a major real cross platform MUA next to mutt.
The trick is to start yanking root certs out of the phone that shouldn't be there. For example, China's bank (which is part of the government) has no place as a root cert. By disabling those, you reduce the change of a MITM against your VPN provider. iOS... different story, if Apple wants to trust Lower Elbonia, then all their devices and all their users trust Lower Elbonia, and there is not a damn thing they can do about it.
Slashdot Mirror
The problem is, like anti-personnel mines, they give a military advantage of the country using them. Once the AI is down pat, sentry robots that are ran into a battlefield and perforate anything that moves that doesn't give a "I'm a friend" code are the ideal way to grab and hold territory. They work 24/7, don't give bad PR if one of the sentry robots gets destroyed, and many robots can be deployed cheaply. Combine these with a decent power source, and a bunch of these could hold territory for years.
Now, add drones into the equation, be it ones that are solar powered, stay aloft indefinitely and just zoom and fly into the target, or more UACVs.
Even with a treaty, governments will still use these... there are too many advantages.
There might be an algorithm C which is equivilent to (A(B()). However, the chance of that is quite unlikely, especially if a proper implementation of the cipher is used (CBC, for example, or XEX), it makes this almost impossible... likely less than the chance of brute forcing the key.
As for reusing keys, if one has three different algorithms (AES, Twofish, and Serpent), three different keys should be used. This ensures that if one of the algorithms coughs up a key somehow, the other two are still working.
The more it is used, the more often it can be leaked. There is also a priority of how useful a backdoor is. Being able to covertly compromise the head of an enemy state or terror organization's phone for high value intel is one thing. Being able to take phones from protestors arrested en masse to slurp off the goodies in mass quantities is another.
Even the suspicion of a backdoor will get people working on steps to mitigate it, be it having apps that require a passcode before they run and doing the encryption themselves with their own encryption libraries, to people simply turning off their devices when they are not in use and slipping them into a grounded metal box when on trips.
In theory, Apple and Samsung have a lot more to lose. Apple especially, since their reputation as a phone provider rides on how secure their devices are, and if something is discovered, there are many rivals who will be happy to take the loss. Samsung, similar.
Huawei? Not as much, as they are in a different market segment.
Having two algorithms result in an unxpected third transformation is called a "group". Realistically, with TrueCrypt/VeraCrypt's cascades, you are not getting 3*256, or 768 bits, but somewhere between 258 bits and 768 bits. There is a lot of advanced crypto study on this, especially if one algorithm when used may weaken the second algorithm used after that. However, 99.99999% of the cryptographic breaks tend to be along the lines of weak key management and storage, or failure to implement existing algorithms in a secure fashion.
Governments tend to not like backdoors, when they are found and used against their own interests...
The zero expectation of data privacy has come at us from many fronts, be it the "free" services where the subscriber is the product, not the customer, the fact that data is valuable, where VCs only will give money to businesses which sling ads and suck analytics.
With the fact that who knows what people/entities have access to remotely stored data, coupled with the concern about some storage providers actively looking for "pirated" stuff, encryption isn't a luxury to "hide from the cops". It is a necessity for the basic functioning of business. Especially how easy it winds up being for an attacker to compromise accounts.
How can a screen or digitizer communicate to the outside world? It likely isn't on a bus where it can ask the radio or NIC to packetize stuff it feels like. At best, it can record taps on a screen, but getting those out would be a different story. Perhaps for physical snooping where the device is captured later on (say to glean someone's PIN), but for a remote attacker, it isn't that feasible.
Is TrustZone like a hypervisor, or is it like a LXC, managing containers/worlds? It would be nice if ARM supported VMs on the chip level with a standardized hypervisior.
I have some people try to do "AES 512" by chaining AES, or even doing triple AES (encrypt-decrypt-encrypt) like how triple DES was done. This is brain dead, and shows the person who wrote this doesn't have a clue about crypto.
Want more bits? Cascade different encryption algorithms, similar to how TrueCrypt/VeraCrypt does it. It is wise to use a multi-algorithm cascade anyway, because if one gets broken, there are two others. For asymmetric algorithms, same thing. Cascade RSA, some elliptic encryption, and maybe a lattice algorithm, and have each of them have a chunk of the key.
Writing security programs and doing the job right isn't trivial. Computing is littered with many, many broken and worthless crypto programs because of people trying to reinvent the wheel, making their own worthless algorithms, or implementing existing algorithms in a brain-dead manner (ECB, for example.)
Same here. I have things to do in life, and waiting outside a restaurant is not something I care to do. The ironic thing is that the places with long lines (Franklin's barbecue) are usually very overrated. Austin has a lot of eateries, and if needed, I can always drive to a surrounding town. If a place has a line outside, but is empty inside, I definitely will go somewhere else, because either the place just opened for the day or they are not bothering to serve customers... either way, there is an eatery just as good, if not better, somewhere else.
Then, there are Chinese and EU data privacy laws that may conflict with each other. One might want VPN data to be kept for later perusal by the government, the other demands the data be destroyed. With that conflict, coupled to it being a cost center, it is no wonder why Opera tossed that service.
I remember, ages ago, you could NFS mount wuarchive. Of course, do it soft, unless you loved reboots... but that ability was nice.
A lock is a relatively simple device, where the states are obviously known. Devices like this should ship and not need firmware upgrades from the factory. There are many embedded subsystems that cannot or will not be upgraded, so the people who made them did it right the first time, and didn't follow the philosophy of "it builds, ship it."
A lock isn't rocket science. It also is the last thing you need fetching OTA updates. Instead, updates should be delivered via some physical means, if only to ensure someone is on site to test and verify functionality.
Making sure a device doesn't brick itself is not impossible. I have an older Nook tablet that, if it doesn't boot after eight times, it automatically reloads itself from its original firmware, just so the device is usable in some degree. With a deadbolt, you might want a more secure way of failing, so having multiple areas where ROMs are stored, so if it fails to boot, it goes back to a previous ROM. That way, it might grab some bad code and brick a few times, but once the failed update is off the servers, it would fetch a correct one and be fine.
Lesson learned from this... find a lock maker that treats their offerings as a security item, and not some throwaway IoT device.
I did a basic genetic algorithm project on this for a CS class. 100 cities, and it took about 90 seconds to chug out a working answer. Is it _the_ answer? Perhaps not. But it is good enough.
Dynamic libraries have been one way to save space for programs. Have a standard library that is tossed into a special shared area of the filesystem, hard link it so the apps can see it in their jail, and call it done. Obviously, the library would be signed.
Now comes the tough part. DLL hell. A WinSxS mechanism would be useful so apps that use different versions of a library would not conflict with each other.
Of course, the best solution would be filesystem level deduplication. If apps are stored encrypted on the device, then move to a dynamic library system and deduplicate the .so files.
This isn't the best solution, but it should significantly save space.
Easy fix... some type of transponder on the sign that is cryptographically signed and is GPS locked to a small area, so if the sign is moved beyond a few feet, it gets ignored by the vehicle. That way, a 30 changed to an 80 will be ignored. Not 100% secure, as someone can hack the private key, but it will stop mischief like this.
Before Eternal September, USENET didn't suffer fools/trolls gladly, and back then, all it took was a couple E-mails to abuse@troll-s.isp.com, and the admins got rid of them quickly, because having one's connections to other NNTP sites pulled was a very useful tool.
To boot, USENET posts will follow you forever. Last year, during a job interview, I actually had an interviewer pull up posts from the early 1990s I had in sci.crypt and alt.sex.cthulhu...
The niche for MP3 players has shrunk, pretty much because of this. For at home, one can buy a NAS with Plex for storing the terabytes of media (music, movies, etc.) For on the go, a smartphone can handle most music collections.
Right now, there are a few niches for MP3 players:
1: Inexpensive items for when one doesn't want to bring their smartphone along (jogging, gym, zombie hunting).
2: Something for the kids (where an iPod Touch is ideal, because it does everything a smartphone does, except make cell calls.)
3: A novelty item. There are some small cube shaped MP3 players which are worth having.
4: Something to have plugged into the stereo, so a copy of one's music is always there.
5: A backup authentication device (the iPod Touch I have saved my bacon when Authy decided to erase all 2FA info.) Having a device which is not connected to the Internet, except for brief periods allowed me to keep access to all my stuff.
However, the few niches are not a mass market anymore. Creative is completely out of the MP3 player market and has moved to speakers and other things.
The one niche that could possibly be useful is a market for "personal recovery devices". Things like an iPod Touch which store 2FA and password recovery info, and are kept offline, so if one loses their phone, they still have access to their Duo or Google Authenticator stuff.
My first "MP3" player was a Sony VAIO Music Clip, my second a Sony NW-MS7 Memory Stick Walkman which used MagicGate cards. At the time, they were nice and compact, easily taken places. Even today, the form factor is decent.
Of course, they were DRM-ed to Hell and gone. The Music Clip could take MP3 files, that were "wrapped" with Sony's ATRAC-whatever encryption. The other device had to have everything fully transcoded by the OpenMG software, which only ran under Windows 98. There was no copying files with this software. In fact, only three copies of each track were allowed, so one had to check in and check out music. Backing up your music collection? Good luck. Later OpenMG editions might allow backups... provided you called Sony for some restore key.
I went and bought a Creative Nomad 2. It came with a docking stand and was rechargable, even with an inline remote. No real DRM, although it was a bit clunky compared to the sleekness of the Sony players.
After that, my first HDD based MP3 player was a Creative Nomad Jukebox. Huge thing, six GB 2.5" HDD, would run for a few seconds off a set of four AA batteries, so it was more of a "plop by your computer to listen to stuff" than something portable. One could upgrade the HDD inside by using dd to copy off the first chunk of the drive which stored the player's OS... but one did run into a hard file count limit, so anything bigger than 12-20 gigs was pointless.
iPod-wise, my favorite iPod, just for unique value, would be the 6th generation iPod Nano. It was as close to a smartwatch as people had at the time.
It is a gamble. For a lot of users, having randomly generated passwords that are stuffed in a PW database is more secure than having them have "hunter2" for their bank, "swordfish" for their Facebook account, etc. The chance of a mass compromise of a Lastpass is definitely less than having one's password revealed to the world the next time some company's list of hashed PWs gets snarfed.
Even with the potential hazard, if combined with 2FA, the hazard of a compromised password is reduced significantly.
To boot, longer, hairier PWs can be used as well, as the user doesn't have to remember them.
There is also the fact that an EV uses zero energy (well, except for the climate control system, radio, and electronics) when stopped. An IC vehicle still burns fuel. This in itself is a major fuel saver.
At least with EVs, we can figure out what to use for electricity. If there is a new fusion development, it can be used and immediately change the CO2 profile across large areas. Similar if thorium reactors, or even Gen IV reactors become the norm. With IC engines, we have to replace them individually.
The trick is that we can keep improving. There is no single magic bullet, but if we replace a coal base plant with solar + energy storage, it helps things a little bit. Similar with adding wind capacity, instead of having to add a biomass plant.
I can name a number of file sharing services, both paid and free, which offer this functionality. It is nice to have a temporary file service that is part of a web browser and that (hopefully) doesn't require a ton of signing up and such. However, I wouldn't mind Mozilla focus on core things as well. Firefox, Servo, and Rust are useful, but SeaMonkey and Thunderbird are still important, as Thunderbird is a major real cross platform MUA next to mutt.
The trick is to start yanking root certs out of the phone that shouldn't be there. For example, China's bank (which is part of the government) has no place as a root cert. By disabling those, you reduce the change of a MITM against your VPN provider. iOS... different story, if Apple wants to trust Lower Elbonia, then all their devices and all their users trust Lower Elbonia, and there is not a damn thing they can do about it.