Father, Hacker (Information Security Professional), Open Source Software Developer, Inventor, and 3D printing enthusiast

  • 4 Posts
  • 133 Comments
Joined 1 year ago
cake
Cake day: June 23rd, 2023

help-circle
  • This is a, “it’s turtles all the way down!” problem. An application has to be able to store its encryption keys somewhere. You can encrypt your encryption keys but then where do you store that key? Ultimately any application will need access to the plaintext key in order to function.

    On servers the best practice is to store the encryption keys somewhere that isn’t on the server itself. Such as a networked Hardware Security Module (HSM) but literally any location that isn’t physically on/in the server itself is good enough. Some Raspberry Pi attached to the network in the corner of the data center would be nearly as good because the attack you’re protecting against with this kind of encryption is someone walking out of the data center with your server (and then decrypting the data).

    With a device like a phone you can’t use a networked HSM since your phone will be carried around with you everywhere. You could store your encryption keys out on the Internet somewhere but that actually increases the attack surface. As such, the encryption keys get stored on the phone itself.

    Phone OSes include tools like encrypted storage locations for things like encryption keys but realistically they’re no more secure than storing the keys as plaintext in the application’s app-specific store (which is encrypted on Android by default; not sure about iOS). Only that app and the OS itself have access to that storage location so it’s basically exactly the same as the special “secure” storage features… Except easier to use and less likely to be targeted, exploited, and ultimately compromised because again, it’s a smaller attack surface.

    If an attacker gets physical access to your device you must assume they’ll have access to everything on it unless the data is encrypted and the key for that isn’t on the phone itself (e.g. it uses a hash generated from your thumbprint or your PIN). In that case your effective encryption key is your thumb(s) and/or PIN. Because the Signal app’s encryption keys are already encrypted on the filesystem.

    Going full circle: You can always further encrypt something or add an extra step to accessing encrypted data but that just adds inconvenience and doesn’t really buy you any more security (realistically). It’s turtles all the way down.






  • You say that because you don’t realize the benefits:

    • Better support for Linux with any new PC hardware on day 1. This includes things like USB devices, monitors, KVMs, UPS, everything.
    • Better support for all commercial software in general. More software will become available and it’ll be higher quality.
    • Vendors will be forced to test all their stuff on Linux which means it’ll all become more reliable and less glitchy.
    • There will be more diversity in software and distros which means widespread attacks (aka hacking, worms, viruses, etc) will have less success and smaller impacts.
    • The more Linux users there are the more Linux developers will result. It’s also much easier to start learning how to code on a Linux desktop than it is in Windows.
    • Better security for the entire world. Linux has a vastly superior security architecture than Windows and a vastly superior track record. The more Linux users there are, the harder it will be for malicious entities to break into their PCs which translates into a more secure world.
    • It’s much easier (for experienced users) to troubleshoot and fix problems in Linux than in Windows. This will lead to support teams everywhere getting frustrated whenever they have to deal with Windows users (this is already the case for many software vendors, haha). Therefore, it makes support people happy and easy going. Who doesn’t want to reach a happy, helpful person for technical support instead of the usual defiant/adversarial support tech? 😁
    • The worst sorts of hardware vendors won’t be able to get away with their usual bullshit. For example, if there were enough Linux users HP wouldn’t be offering extremely invasive 2GB printer “drivers” because their Windows customers would know enough Linux users that they’d be rightfully pissed and not depressively submissive like they are now.
    • When you do have a problem it will be easier to find a solution because the likelihood that someone else already had it and posted a solution will be higher (though admittedly this factor doesn’t seem to do much for Windows currently because of how obtuse and obfuscated everything is in that OS).

    There’s actually a lot more reasons but that’s probably enough for now 😁


  • I’d love to see more adoption of… I2C!

    Bazillions of motherboards and SBCs support I2C and many have the ability to use it via GPIO pins or even have connectors just for I2C devices (e.g. QWIIC). Yet there’s very little in the way of things you can buy and plug in. It feels like such a waste!

    There’s all sorts of neat and useful things we could plug in and make use of if only there were software to use it. For example, cheap color sensors, nifty gesture sensors, time-of-flight sensors, light sensors, and more.

    There’s lmsensors which knows I2C and can magically understand zillions of temperature sensors and PWM things (e.g. fan control). We need something like that for all those cool devices and chips that speak I2C.









  • This is caused by your root controller’s limited bandwidth and it’s inability to handle that many 3.0 devices at the same time. Some of the newer motherboards with USB C PD have controllers in them that can do a lot more.

    It’s basically a hack on part of the company that made the root controller IC. They know they only have enough internal bandwidth to support 16 USB 3.0 devices so they intentionally bork things when you plug in more than that since their Transaction Translator (TT) can’t handle more and they were too lazy to bother implementing the ability to share 2.0 and 3.0 properly.

    I’m guessing the decision went something like this…

    “We have enough bandwidth for 16 3.0 devices… What do we do if someone plugs in more than that?” “Only a few people will ever have that many! We don’t have the budget to handle every tiny little use case! Just ship it.”

    So it’s not Linux fault in this case. Or at least, if it is (a problem with the driver) it’s because of some proprietary bullshit that the driver requires to function properly 🤷


  • This is a great idea! Lock picking is fun and super impressive to laymen (haha).

    Just don’t tell anyone but your closest, most trusted friends (haha). Also, tell them to keep it a secret! Why? So your neighbor doesn’t knock on your door at 2AM because they locked themselves out of their apartment.

    Also, you don’t need cutaway locks! They’re neat toys but nothing more. What you really need is a variety of locks to play with.

    Head to your local hardware store and pick up a bunch of cheap locks. Or just ask friends if they have any old padlocks they’re not using (most people will have one or two).


  • Riskable@programming.devtoSelfhosted@lemmy.worldWhat's the deal with Docker?
    link
    fedilink
    English
    arrow-up
    81
    arrow-down
    1
    ·
    4 months ago

    Docker containers aren’t running in a virtual machine. They’re running what amounts to a fancy chroot jail… It’s just an isolated environment that takes advantage of several kernel security features to make software running inside the environment think everything is normal despite being locked down.

    This is a very important distinction because it means that docker containers are very light weight compared to a VM. They use but a fraction of the resources a VM would and can be brought up and down in milliseconds since there’s no hardware to emulate.




  • Linux never ran on the Commodore 64 (1984). That was way before Linux was released by Linus Torvalds (1991).

    I’d also like to point out that we do all rely on non-proprietary protocols. Examples you used today: TCP and HTTP.

    If we didn’t have free and open source protocols we’d all still be using Prodigy and AOL. “Smart” devices couldn’t talk to each other, and the world of software would be 100-10,000x more expensive and we’d probably have about 1/1,000,000th of what we have available today.

    Every little thing we rely on every day from computers to the Internet to cars to planes only works because they’re not relying on exclusive, proprietary protocols. Weird shit like HDMI is the exception, not the rule.

    History demonstrates that proprietary protocols and connectors like HDMI only stick around as long as they’re convenient, easy, and cheap. As soon as they lose one of those properties a competitor will spring up and eventually it will replace the proprietary nonsense. It’s only a matter of time. This news about HDMI being rejected is just another shove, moving the world away from that protocol.

    There actually is a way for proprietary bullshit to persist even when it’s the worst: When it’s mandated by government.