Good timing for me too. I'm currently looking for a first customer with whom I'd possibly shape the product a bit. The development phase was fun, now comes the hard part.
Additionally I'm working on a security related product (digital artifact authenticity validation) and I feel like security is a hard sell especially in my network as they don't seem to correspond to the product's target (or I'm a poor promoter of the solution....). .
It's not you, security is indeed a hard sell (coming from the other side, as security engineer trying to push for adoption of solutions). There's some products like Wiz that you don't really need to push hard for, but everything else seems like a struggle
Damn! Would you have the opportunity to share experiences? My emails is in my profile, it would be great to hear from you. (It is an open source project, which makes it even harder to sell probably, so every hint might help!)
Putting finishing touches on an open source multi sig solution to authenticate digital artifact, aiming to increase security of the software supply chain. It's open source, completely self hostable, incl internally, support air gapped signers, fully auditable (data store is a puglic git repo). It's an alternative to sigstore, making different decision.
I've been working on a new project using ed25519 signatures and discovered they are not quantum resistant.... I went with ed25519 due to possibility of using openssh keys. Any opinion on this choice at the light of this article and other quantum computing news?
Signatures aren't as urgent to replace as encryption keys are. You can wait until someone is about to build a quantum computer, then change all your signatures. Encrypted data is more critical because the NSA's going to store all internet traffic for centuries if it thinks it can decrypt it later.
No, very much no. If store now decrypt later is the problem, then we basically have no problem (Just like what Peter Gutmann argues [2]). The vast, basically all communication over for example TLS need confidentiality in minutes, hours. Not 30-100 years. My bank statement right now, the plans we discuss for the project next year etc.
But what is very important crucial, what makes our digital world including secure communication, web commerce possible is the web of trust - identification and authentication. I'd claim that the important part of TLS including certs is this part. We could by and large not need the confidentiality. But since it costs so comparatively little we can just as well always encrypt too.
You seem to think that changing a certificate is something we can fix in minutes. Globally. The reality is far from that. Esp in things that are not just your browser. Things like network equipment, FW for basically every embedded system, cars, busses. And crucially for critical entities.
These things have long lifespans (decades), often need manual intervention to change certificates (connect a JTAG, serial intercace), possible even replacement. But replacing root certs in all our normal devices - phones, laptops etc are also far from easy and done in minutes. Then you have all digital identification solutions - from ID cards, car fobs, 2FA tokens, passports, credit cards. You may have to replace millions of physical things, even distribute to whole populations.
And back to the web. If we can crack an RSA-2048 key in 24 hours (which is the measure used when guessing we have QC capable enough [1]). We really don't have that many CAs. The times they have had problems have caused problems that have taken days, weeks to trickle down. Having CA issue new rootcerts several times a day isn't viable. So I'd wager that transitioning to PQC safe certificates, authentication isn't something we can wait with. It will take years and huge efforts - not minutes and when the problem hits us.
If you look at time plans for transitioning to PQC from CNSA, EU, UK and others, the area they all list as most critical to complete transition as soon as possible for is SW, FW-signing for infrastructure, embedded systems [1].
So, in reality unless you have a legal responsibility for keeping state secrets then store now, decrypt later is not really your main reason for PQC transitioning. Authentication very much is. Unfortunately most cryptographers by large seems to miss this. And people in uniform have a large saying, influence in the debate. My guess is that this is because gov to a large degree finance a lot of the QC research and they have a different threat model that most of the world. But that is just my guess.
As Gutmann argues, we don't even really know that there even is a viable store now, decrypt later threat. Unless you can pinpoint the exact TLS session that is interesting, you can't store or decrypt all traffic that may be the interesting ones (if we assume that the cost of breaking a single RSA is not zero and takes minutes, seconds. Not 24 hours). And if indeed if TLS and normal key exchange mechanisms, are really used for those juicy messages.
The open source project I'm working on aims to authenticate artifact downloads (project name is asfaload, in short it is a sigstore alternative).
My understanding is that in a post-quantum world, the private key can be derived from an ed25519 pub key. That means that an attacker can generate new signatures. But I don't think an attacker would be able to generate a malicious artifact that matches an existing signature. It would seem that once we are nearing PQC, Asfaload would need to support PQC signatures, and its uses would need to migrate to new keys, but that existing signatures would still be safe to use for validation. Is that right?
That is how I understand it yes. I can create a new FW and sign it with the vendors key I cracked and it will be trusted to come from the vendor. But generating a malicious FW that has the same signature is still a hash collision problem.
Sigh, that argument again. I may have used the wrong example, sorry.
How about the current temperature in my bedroom? The battery status of my robomower, Or the vat/tax and total sum I paid at a cash register for the Plopp candy bar earlier today? I could share all this with you if you want.
Depending on where you live, all these systems may, quite possibly talk over TLS and other protocols that include encryption. In some cases unfortunately encryption is the only security mechanism used, when instead device identity, authentication and message authentication is needed. And all are examples where the secrecy requirement is zero or zero after a very short time.
I agree! It's amazing to require the visitor to edit the url to go from blog to main site. For my projects I pay attention to avoid this as I find it so annoying. I want visitor that are interested to have easy access to the website!
I'm not only complaining, I also work on a solution (asfaload) that I want easy to use. As it is multisig, such platform breaches become impossible. Below is the doc of the CLI, i'm looking for testers and challengers of the solution!
I'm very happy using docker swarm on a single host with traefik as reverse proxy using the setup described here: https://dockerswarm.rocks/
Super easy deployment of additional apps, defined completely in one file (incl setup on host, backups, reverse proxy config, etc).
Never found a reason to migrate away. Swarm was already considered dead when I started using it in 2022[1], but the investment was so low and benefits so big, that it was the right choice for me. I think a lot of people are replicating swarm features with compose, losing a lot of time. But hey, to each their own choice!
Docker context for remote access - over Internet or vpn, whatever.
Swarm-cronjob for scheduled things.
Labels for things that need to run in particular places.
So easy.
Personally, k8s is fine, but its an abstraction for building a service architecture, not the thing an end user (developer) should ever use. If you are in a big company and you are using helm or k8s yaml files to roll things out, your infra or platform teams have missed something out.. building the platform!
As I read it, they didn't look up the account to process the refund. They looked up the account to decide whether to process the refund, and then the decision was "no".
The rest of the support response is just pleasantries and padding, to dance around this fact ("Your detailed reproduction steps will be valuable" blah blah).
I have such a project I just can't shut down: https://myowndb.com/
I started it 20 years ago, with ruby on rails. I neglected it but then decided to rewrite it in F# and publish it as open source (https://gitlab.com/myowndb/myowndb).
There are very few users, some from many years ago, all non paying. None gave any feedback I asked during the rewrite.
I should have shut it down years ago, but I just can't take the step. I'm focused on another project now, but who knows, maybe I'll get back to it....
Hey that looks pretty neat! I sort of miss MS Access sometimes, and this feels like it might fill the same niche. The star count also just went up 50% :-D
Does it use Sqlite or something on the backend, or is it all it's own? Do you know if it runs on Linux?
Edit: My answers based on a quick review (please correct if I'm wrong). It uses Postgres (cool!) and definitely runs on Linux (I see Dockerfile in there). UI is through the browser?
Perfect website! Clear texts, clear screenshots, and an about page with a small photo of the person behind it. If I wasn't already using PHPMyAdmin I would definitely consider your product trustworthy. Am I right that it is - sort of - the same functionality as PHPMyAdmin?
I especially appreciate the honesty about the upcoming pricing. Do you plan/want to make it a business?
Thanks for the positive feedback!
It combines administration features and end user interace. The definition of data structure is not very intuitive, and that would be the first and most important thing to fix. I think a lot of people get lost at the definition of their first table....
reply