PGP Signed Tweets | Hacker News Reader

PGP Signed Tweets

shkspr.mobi

53 pointsedent25 comments

I don't see any useful point in doing this. And I doubly don't see a point in doing it with PGP.

See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html for an explanation on why PGP is disliked by cryptographers.

Presumably,If you get phished,whoever posts on your account won't use pgp signatures. But then again use a yubi,totp or something (but then again your phone or yubi might get stolen).

At the very end in a parenthetical the author includes:

> (NB - alt text is really important for visually impaired users. Please don't needlessly clutter their timeline with garbage.)

What is the impact on screen readers? Do visually impaired users have to suffer through 1000 base64 characters being read aloud?

At the very least it seems like this warning should be at the top of the article with a disclaimer to only use this method for good reasons (eg after recovering your Twitter account post-hack or as a one-time proof of identity).

Please don't use this and end up discouraging software and services from properly supporting accessibility features!

While I agree with you, detecting garbage text and not reading it out without explicit request sounds like a feature that screenreaders should have.

Better yet a PGP aware screen reader could actually check the signature and then simply mention that "This message was verified against the authors signature" or similar.

I expect those who'd actually want such a feature would have a workaround in place already.

You're of course correct but I also think you greatly overestimate the number of people willing to even put up with PGP, let alone sign their tweets with it.

I think a screen reader user would probably just skip to the next element once they figured out it was gibberish. It might be nice to add a line before the PGP header explaining what was going on, though.

> It might be nice to add a line before the PGP header explaining what was going on, though.

Maybe something like ...

  -----BEGIN PGP SIGNATURE-----

This?

If the proposal is to use this for general purpose tweeting then you need to assume the audience does not know what a pgp signature is.

> Do visually impaired users have to suffer through 1000 base64 characters being read aloud?

Yeah, but they'll use the keyboard to navigate to the next paragraph after a few characters - or the next the tweet entirely.

Meanwhile, a minisign signature might be short enough (without the comments) to fit into the tweet itself. And it's more secure, and not "baroque".

https://jedisct1.github.io/minisign/

minisign seems to give 289 character signatures with no comment but the first 54 seem standard and droppable which does you give wiggle room for a short tweet + the signature.

I just tested this with VoiceOver and when it reaches the image, it tries to read aloud the alt text of the image, so it starts reading each character and number, almost as if it went bonkers.

Therefore yeah, while it is a cool experiment to show how to hide additional data on tweets (it doesn't seem that Twitter search includes alt texts, unlike other stuff like display names or handles), it is also disrespectful and unpolite to users who depend on accessibility features like screen readers.

(There are already other subtle ways to be unpolite to screen reader users on Twitter, such as sharing critical but well-designed announcements inside images with no alternate text available and no link to a text-only version – something that governments seems to do often once they get aboard the Twitter train)

signify[1] signatures are 64 bytes + 10 byte header, making total base64 encoded length 100 characters, which would conveniently have fit to even the old alt text easily

[1] https://man.openbsd.org/signify

How would you get the public key to verify such a signature?

> There are no key servers for signify. No web of trust. Just keys. The good news is the keys are pretty small. As demonstrated. We can stick them just about everywhere, and we do. They're on the web site, they're on twitter, they're on the top side of CD. 56 base64 characters. You can read it out loud over the phone in under a minute. Wide dispersion makes it harder and harder to intercept all the ways you may get the key and increases the risk of detection should anybody try some funny business.

https://www.openbsd.org/papers/bsdcan-signify.html

but if you really want to have a central public place for keys, then the recently discussed https://keys.pub should work, just needs minor format conversion: https://keys.pub/docs/specs/keys.html

I just tried this and I get 140 characters for the `.sig` file - to verify it, you do need the first line "untrusted comment: verify with sig.pub" which adds 39 to the 100 for the signature (but I suppose since that's a standard part, you could take it as read...)

As i understand it you have to be careful with signing short messages with no metadata or context.. reply to some tweet with

> this is a great idea

and sign only that text.. now there's a signature of "this is a great idea". I believe the signature has the creation time, but there's nothing to tie it to the message you are replying to.

I guess you could make sure each signed tweet starts with a YYYY-mm-dd HH::MM::SS (TZ) line by itself. At least then a reused old message would look weird because the time would be wrong, and easily visible (but also easily ignored in the common case, which is probably what is wanted).

What is lost here by doing so?

If someone tries to imitate your Twitter account:

  - they could clone your signed messages, but *you* wrote them.
  - they could use a new PGP key to sign their messages, but they aren't claiming your PGP identity
  - modern cryptographic algos have many resistance properties so your stated scenario is not a weakness

Such a short signed message could be used out of context in the future. Bob somewhere else is talking about a different idea, and I claim to be Alice and send Alice's signed "this is a great idea" message. The signature checks out, and it seems to be in response to what Bob is talking about, so Bob would assume Alice think his idea is great.

You want to make sure that whatever you signed can't be used against you out of context. It would be safer to sign a message like "date> {today's date}, re> {parent message hash}, this a great idea"

Back in the day, I used to PGP sign Usenet messages. I used a news reader where I could specify message ID. So I signed text that included the date and message ID.

Aren't elliptic-curve signatures pretty short? (Though I may be blatantly mistaking the applicability of the curves.)

Also til that somewhere on Twitter, alt-text can be specified.

64 bytes for ed25519 signatures.

Is it possible to sign something, get the hash of that, and upload the hash to a blockchain?

The blockchain forms the backbone of a digital notarization service. This guarantees that it was you that sent the message.

Then you send the encrypted message to your recipient. The recipient decrypts it with his private key. And then, he can verify on the blockchain that it did indeed come from you.

I’m thinking this can be used for verified communications, e-commerce, e-banking, e-contracts, etc.

This is just an off the cuff thought. I haven’t really thought through all the scenarios for this idea.

Reply on news.ycombinator.com