There's no clear segmentation. There's symmetric and asymmetric primitives (and stuff that doesn't fit into these like ZKP), algorithms, protocols, research in many different types of attacks against each of these, research in design and defenses, and plenty of people will cover completely different subsets.
"don't" roll your own cover everything from "don't design your own primitive" to "don't make your own encryption algorithm/mode" to "don't make your own encryption protocol", to "don't reimplement an existing version of any of the above and just use an encryption library"
(and it's mostly "don't deploy your own", if you want to experiment that's fine)
I wonder if there is a concrete point at which it turn into “this is common sense security that even you should know about” like not conflating hashing and encryption, or “you should just have someone else do do security for you”? I guess at larger entities you have a CISO role but what about in smaller, scrappy endeavours, how does one know where one is at the limit of their due-commonsense and hand it off?
Most practitioners in security --- from information security to compliance to systems security to software security to red-teaming --- have very little competence with cryptography. Cryptography is hyperspecialized. It is not part of the toolkit of any ordinary professional.
(That's nothing to do with how hard cryptography is, just with how little demand there is for serious cryptography engineering, especially compared with the population of people who have done serious academic study of it.)
The fact that every email encryption integration exports secure context messages into insecure contexts when decrypting (which is how encrypted messages end up cited in plaintext) means email can't be secured.
This is true both for GPG and S/MIME
Email encryption self-compromises itself in a way Signal doesn't
You need a private PKI, not keyring. They're subtly different - a PKI can handle key rotation, etc.
Yes there aren't a lot of good options for that. If you're using something like a Microsoft software stack with active directory or similar identity/account management then there's usually some PKI support in there to anchor to.
Across organisations, there's really very very few good solutions. GPG specifically is much too insecure when you need to receive messages from untrusted senders. There's basically S/MIME which have comparable security issues, then we have AD federation or Matrix.org with a server per org.
> You could say, we do not need gpg, because we control the mailserver, but what if a mailserver is compromised and the mails are still in mailboxes?
How are you handling the keys? This is only true if user's protect their own keypairs with strong passwords / yubikey applet, etc.
What you described IS WHY age is the better option.
GPG's keyring handling has also been a source of exploits. It's much safer to directly specify recipient rather than rely on things like short key IDs which can be bruteforced.
Automatic discovery simply isn't secure if you don't have an associated trust anchor. You need something similar to keybase or another form of PKI to do that. GPG's key servers are dangerous.
You technically can sign with age, but otherwise there's minisign and the SSH spec signing function
Then your next best bet is Matrix.org. Not to the same security standard as Signal, but if you don't have a specific threat against you then it's fine.
Pros of Matrix: it actually has a consistent history (in theory); no vendor lock-in.
Cons of Matrix: encryption breaks constantly. Right now I’m stuck in a fun loop of endlessly changing recovery keys: https://github.com/element-hq/element-web/issues/31392
I’m facing it on Element Desktop, but I’ll try to reproduce it on Element Web. I’ve tried to submit logs from Element Desktop, but it says that `/rageshake` (which I was told to do) is not a command. I’m happy to help with debugging this, but I’m not sure how to submit logs from Desktop.
Something like this happens basically every time I try to use Matrix though. Messages are not decrypting, or not being delivered, or devices can’t be authenticated for some cryptic reason. The reason I even tried to use Element Desktop is because my nheko is seemingly now incapable of sending direct messages (the recepient just gets infinite “waiting for message”).
Weird. Encryption these days (in Element Web/Desktop and Element X at least) should be pretty robust - although this whole identity reset thing is a known bug on Element Web/Desktop. You can submit debug logs from Settings: Help & About: Submit Debug Logs, and hopefully that might give a hint on what's going wrong.
Asking for an equivalent to GPG is like asking for an equivalent of a Swiss knife with unshielded chainsaws and laser cutters.
Stop asking for it, for your own good, please. If you don't understand the entire spec you can't use it safely.
You want special purpose tools. Signal for communication, Age for safer file encryption, etc.
What exact problems did you have with age? You're not explaining how it broke anything. Are you compiling yourself?
Age has yubikey support and can do all you described.
> if your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years.
This applies to algorithms, it does not apply to cryptographic software in the same way. The state of art changes fast, and while algorithms tend to stand for a long time these days there are significant changes in protocol designs and attack methods.
C2PA has the problem that it has a ton of optional metadata support and no well-defined strict validation procedure, so it's trivial to make fake photos appear valid using currently available C2PA enabled software.
They absolutely must define a much stricter mode that actually means something, and distinguish it from what they have now (which is essentially prototype level in terms of security model)
Also, the RPi is the wrong kind of hardware for attestation, at least use something like USB Armory which provides a user programmable ARM TrustZone environment.
Since USB Armory supports pinning multiple keys for secure boot (and IIRC protected storage), you could even deliver it set up with a manufacturer attestation key and allow the user to load and pin their own attestation key (useful for an organization like a news company) as well as allowing "dual boot" between the attested firmware signed by the pinned manufacturer key and the user's own firmware. I've wanted that kind of behavior in consumer hardware for a long time, where you have full freedom between using the locked down OEM environment or your own and switching between them freely.
(I assume the USB Armory might also not be ideal in terms of ability to sleep and boot speed, etc, but if you have a quicker smaller controller that's the main board then it could wake the one that supplies attestation and make that functionality available after it's done booting)
Assuming that people only share conversations they think are good, would that be bad? Isn’t that the basis of RHLF?
There are a few times on Reddit that I want to explain something that I know well. But it will be a long post.
I’ll be lazy and ask ChatGPT the question, either verify it’s correct based on what I know, ask it to verify its answer on the web - the paid version has had web search for over year - or guide it to the correct answer if I notice something is incorrect.
Then I’ll share the conversation as the answer and tell the poster to read through the entire conversation and tell them that I didn’t just naively ask ChatGPT. It will be obvious from my chat session.
I’ve had pretty good luck when having it write Python automation scripts around AWS using Boto3.
If it’s a newer API that ChatGPT isn’t trained on, I would either tell it where to find the newest documentation for the API on the web or paste the documentation in.
It usually worked pretty well.
If the author of the library wrote good documentation and sample code, you wouldn’t need StackOverflow hypothetically if ChatGPT was trained on it
Apple is training its own autocomplete for Swift on its documentation and its own sample code.
We don't have to guess. Just look at languages which have been around for a while, achieved some baseline level of popularity to have a decent amount of public code available, like Elixir.
I haven't found an LLM that could reliably produce syntactically correct code, much less logically correct code.
Since LLMs have been a thing, I’ve been heavily involved in the AWS ecosystem and automation.
ChatGPT is well trained on the AWS SDK for various languages. I can usually ask it to do something that would be around up to a 100-200 line Python script and it gets it correct. Especially once it got web search capabilities, I could tell it to “verify Boto3 (the AWS SDK for Python) functions on the web”.
I’ve also used it to convert some of my handwritten AWs SDK based scripts between languages depending on the preferences of the client - C#, Python, JavaScript and Java.
It also does pretty well at converting CloudFormation to idiomatic CDK and Terraform.
I was going into one project to teach the client how to create deployment pipelines for Java based apps to Lambda, EC2 and ECS (AWS’s Docker orchestration service).
I didn’t want to use their code for the proof of concept/MVP. But I did want to deploy a sample Java API. I hadn’t touch Java in over 20 years. I was a C#/Python/Node/(barely) Go developer.
I used ChatGPT to create a sample CRUD API in Java that connected to a database. It worked perfectly. I also asked about proper directory structure.
It didn’t work perfectly with helping me build the Docker container. But it did help.
On another note: it’s not too much of leap to see how Visual Studio or ReSharper could integrate an LLM better and with static language, guarantee that the
code is at least syntactically correct and the functions that are call exist in the standard library or the solution.
They can already do quick, real time warnings and errors if your code won’t compile as you type.
Its own answers, with feedback about whether the answers seem to have worked.
Learning to predict what word will lead to a successful solution (rather than just looking like existing speech) may prove to be a richer dataset than SO originally was.
Most of the time this would happen in the form of an interactive debugging session, with immediate feedback.
Code review is its own domain. In general at some point LLMs need to be trained with a self-evaluation loop. Currently their training data contains a lot of "smart and knowledgeable human tries to explain things". And they average out to conversation that is "smart and knowledgeable...about everything". That won't get us to, "Recognizably thinks of things that no human would have." For that we need to get it producing content that is recognizably higher than human quality.
For that we should find ways to optimize existing models for an evaluation function that says, "Will do really well on self-review." Then it can learn to not just give answers that help with interactive debugging, but actually give answers that will also do well with more strenuous code review. Which it taught itself how to do in a similar way to how AlphaZero manages to teach itself game strategies.
reply