• 1 Post
  • 1.03K Comments
Joined 3 years ago
cake
Cake day: October 6th, 2023

help-circle







  • As another user said below, the biggest problem is making sure you’re using a good prng. There are really simple algorithms for generating “ok” random numbers, that’s the kind of thing you might get when you use a rand() function in a programming language. Those rand functions are plenty good enough for deciding dice rolls in a video game, but they aren’t robust enough for cryptography.

    Outside of that, you’re correct that the next problem is the seed, and how much total entropy is in that seed. In this context, entropy means the total search space for the seed (“hello” would be a low entropy seed, “RPSTl6HF7mPo3g” would be a much higher entropy seed).

    Like you suggested, sometimes your seed is a long timestamp combined with other factors, that makes for a great high entropy seed! But sometimes, like with a Bitcoin key, you want your seed to be recreatable, should you lose it. That’s when you tend to use a password as a seed. So the way that actually works, is that your key is a long string of binary bits, say 256 bits, and that string of bits is generated using your password as a starting seed. This process is the hashing algorithm. And this is where there tends to be a problem. Your hashing algorithm may produce 256 bit keys (high entropy), but whether it’s actually secure will depend on whether your seed phrase (password) is high entropy. You can create a key based on anything, it could be (should be) a phrase with more entropy than the key itself, for instance “my special long password with 1 secret word Brathrok” that’s a very long seed and it includes a word that won’t be in a dictionary, that’ll be hard to brute force, but easy to remember. Or… it could be a single word with low entropy, like “fool”, which is a good way to lose your bitcoin, so please don’t do that.




  • Yeah, this has actually been a known thing for a while. The government has been sneakily getting their hand into NIST standards and trying to ensure they have back doors in the commonly used “best practices”.

    So as a result for instance, encryption based on pseudo random numbers generated with hashing algorithms are actually safer that these theoretically “actually random” numbers generated in dedicated security modules in hardware.




  • Absolutely right! And to be fair, sometimes you can get that tangible satisfaction in tech hobbies. You know, I’ve hacked some consoles, installed custom router firmware, built a crypto miner. Stuff like that can absolutely be personally satisfying.

    But I think you hit the nail on the head, however you get it, I think we really do need some kind of tangible product of our efforts sometimes. You need to be able to say “yeah, I did that”.


  • I worked in IT for years, I’m good at it, I like problem solving, I like fixing things, I like building things.

    But as time went by, I found myself in a more managerial role and truth be told, that’s not really my jam. And when I wasn’t doing that I was the specialist who could support some of our organizations’ worst and most troublesome systems. I was also put in charge of training people to use the company’s new web app (which was supposed to make people’s jobs easier, but really didn’t). Let me tell you, I do not like supporting shitty software or hardware, and I really do not like encouraging users to embrace useless web apps that don’t work well and serve no real purpose. I hated my job and it was time for a change.

    So at that point I decided to completely shift my career and learn to code. I figured, if I hate supporting shitty software, why not just build good software. So I took some free classes through MIT’s open course ware, and learned to code. I spent a couple of years coding, picking up skills, learning languages, working with different compilers, taking additional math classes. And by the end of it all, one of my major takeaways was that I do like building things. But… as a professional software developer, I probably wasn’t going to be doing a lot of that. At the end of the day I might be able to say, “I squashed some bugs in some code that I didn’t write and don’t really know the greater purpose of”. Or if I’m lucky, “I wrote some functions that took in some inputs and produced some outputs”. But that doesn’t really feel like building something, that just feels like being a cog in a machine.

    Over that same period when I was learning to code I was also picking up a second set of skills. We inherited the home my wife grew up in (which to be sure, is a pretty great deal). But it’s a fixer upper, it needed a bunch of attention. And since I was basically home schooling myself I thought I’d earn my keep by doing a lot of that maintenance myself rather than hiring a pro. I collected power tools, I learned to use hand tools, I made a lot of trips to Home Depot. I went through the basement full of rusty tools and restored many of them, replaced handles, sharpened blades, greased gears. I learned how to replace drywall, how to install an electrical outlet, how to repair a dryer. I replaced thermal fuses in kitchen appliances to bring them back to life, I mixed cement and rebuilt a crumbling retaining wall in the backyard.

    Over time I got good enough at this that I started helping some of our friends with their homes. I could strengthen a rickety front step, or repaint a room, or replace a toilet. I had skills that people needed and actually, I generally liked doing it.

    TLDR: In the time it took me to discover that being a programmer might somehow still not allow me to build things, I also learned that being a handyman would allow me to build things.

    So yeah, career changes are scary, and it rarely looks like a good choice, but it is an option. And honestly, I’ve been a computer guy my whole life, but seriously, working with wood and screws and PVC has been super rewarding. So yeah, I guess I’m saying keep an open mind, and consider trying something different, you never know what might work for you.