I see all these fancy password managers and I think… why not simply use an encrypted text file with your passwords on it? Less code, fewer vulnerability vectors.
Actually, there are potentially more vulnerability vectors.
If storing all your passwords in an encrypted text file works for you, that’s fine; more power to you. But I don’t think it’s accurate anymore to claim that going that route is more secure than alternatives.
For the same reason you don’t manually decrypt and paste in your ssh private key every time you log in to a host—convenience.
A password manager can also do some checks that humans may miss or flub, like stopping the pasting of your Gmail password into a convincing phishing site.
You would like pass(1)
That’s a bit presumptuous – I’m not pizzaiolo, but while I do personally employ (essentially) the encrypted-text-file method, I think “pass” is actually pretty grossly misdesigned.
I have some issues with pass too: namely, it leaks metadata like names, creation time, and change history, and it encrypts without authenticating. Is there anything else I should know about?
There are little things like its somewhat oddball dependency list (tree? what?), but the metadata-in-the-clear aspect is definitely the major one for me (the gross misdesign I referred to).
That would be hard to use on a mobile phone I think.
I think it is not that hard to write a GUI application able to decrypt GPG encoded files, or read stdout by making subsequent calls to pass.
This is getting pretty seriously far away from the implied simplicity of “simply use an encrypted text file”.
Depending on your use case, this might be the solution. I have written my own at http://pestilenz.org/~ckeen/blog/posts/pee.html
I find the lack of dynamic allocation especially interesting. In what sort of situations would this be necessary?
As an example though, what sort of system requires SSL and does not allow dynamic allocation? Not questioning the purpose of the feature, just curious :)
It’s not about “not allowing dynamic allocation”.
Statically allocating everything is more predictable, since you don’t have to worry about e.g. heap fragmentation. It reduces some amount of security issues, like failing to handle malloc errors, and use-after-frees, and double-frees. It makes it impossible (ish) to have memory leaks, which can also be security-relevant. It makes it easier to write thread-safe code.
Ahhh, that makes a lot of sense. Thank you!
You don’t know how annoying it can be when a library uses something you don’t have in some corner you have backed yourself into. its easier to just be careful from the start.
I can imagine needing to use amazon IOT with client certificates on some bare metal platform for example.
for when you need your refridgerator to make purchases with a credit card
He wrote this book: http://www.prometheusbrother.com/ Which is interesting. All SSL hackers have very varied interests.
On top of embedded, they can be designed to use fewer resources if it’s a fixed-allocation scheme or easier to analyze. In terms of analysis, you might be able to do timing analysis for covert channel mitigation, same analysis for real-time situations, static analysis with tools like Astree Analyzer to show absence of critical errors, or whole app analysis showing it follow your policies in every successful or failed state due to determinism. Always go for static designs when you can. If you can’t, then mix the two so at least portions can be exhaustively shown to be correct with extra eyeballs on the dynamic stuff. Similar to mixing pure and impure components in languages like Ocaml.
Dumb CS question: if you restrict yourself to static allocation, are you Turing-complete?
Individual programs are generally not Turing-complete (what would that even mean?) - the question only makes sense for language implementations. (Admittedly any program that accepts input is in some sense a language implementation, but for something that just decrypts SSL not really).
A Turing-complete language implementation necessarily needs access to unbounded storage. In a sense such storage has to be “dynamic”, but it could e.g. use the C stack and potentially recurse to arbitrary depth (which I believe would qualify as “static allocation only” in the casual sense; it would be limited by stack size but you can set an arbitrarily large stack at runtime). Or use a fixed amount of memory and a file/database/etc. for storage.
Unless you are statically allocating an infinite amount of memory, no
…but this is true whether or not you restrict yourself to static allocation. There’s always an upper bound on memory on physical systems.
What do physical systems have to do with this? The same principle applies to Turing machines, you can’t simulate an arbitrary TM using a predetermined (finite) subset of the tape.
Stack machines with just one stack and no other storage are not turing complete. Turing completeness is not a requirement for certain algorithms, though and sometimes avoided, because non-turing completeness does allow for more interesting proofs about the program at hand (e.g. liveness).
Turing-completeness is also interesting because it is not hard to reach, making some things accidentally turing complete, such as Magic - the gathering.