[dcow]

Which is a naive way to implement reuse mitigation because you have have a db that grows endlessly. Send a nonce and have the user sign it. Make sure the nonce is only valid for one use (burn it after it’s used). Then you only have to remember active nonces and you can expire them after a short interval.

[_pzht]

Used signatures are purged from the DB after they are no longer valid (too much time has passed). I realize this is a naive, toy implementation (in general). I wrote it to have a broader discussion.

[ghusbands]

You've got the problem that a lot of people have tried to create a lot of novel cryptographic protocols, and they are almost always lacking and insecure. It becomes useful to be able to quickly dismiss things that seem uninformed, as nobody has time to read every such thing.

The inclusion of a nonce/challenge (and other chosen-text and offline-attack mitigations) helps with a lot of security flaws, and that you've omitted them for no clear reason undermines your position as creator of a novel protocol.

As a trivial example, imagine that someone else comes up with a protocol that uses a signed current-date to authorise a bank transfer; as it's not distinguishable from your protocol, there would be many avenues for tricking a user into providing you with the ability to steal their money.

In responses elsewhere in the thread, you say that users should have a public key per website, but in your readme, you repeatedly imply that users have a single key-pair. "Register your base64 encoded public Ed25519 key with the website." "Use your private Ed25519 key to sign the current Unix Epoch Time" "Websites store the users' public keys."

Requiring users to keep generating keys and manage them manually introduces insecurity through non-compliance. It's not simple if you've got to manage something that behaves entirely like a local password database.

You say elsewhere "The demo website and the github repo contain this information" - but the demo website has no descriptive text (can you perhaps provide a link?) and the readme barely mentions threat models or goals. How do you prevent MitM attacks? Can your design support multi-party authentication or delegation of any kind?

I have no experience with WebAuthn, but it's likely that a lot of its features are to improve security in many ways, and omitting these features might make things easier at request-protocol level, but perhaps just simplistic overall.

You say you're trying to facilitate a conversation, but the proposal is so basic that you're effectively asking people to create a useful protocol for you.

[dcow]

You might want to look at webauthn since you say you’re unfamiliar. It’s not much more than a signed nonce with relying party domain name. It actually isn't that complicated. I don’t feel like the author is asking people to implement a protocol for them. They just maybe could have done some research into why WebAuthn has the complexities it does and presented a compelling argument in the readme for why they think they’re overkill or not necessary.

[_pzht]

I like the idea of signing a nonce rather than the current time. That solves several problems. Thanks for the advice.

[dcow]

Time is just icky. I have a personal requirement/standard that I never depend on wall clocks in software I design. Timestamps can be used as an optimization, sure. But never as a fundamental component in the protocol or system.