winhowes / grd.me

Grd Me (/ɡärd mē/) is an open source browser plugin that provides encrypted communication across any web platform.
https://grd.me
MIT License
11 stars 0 forks source link

Eliminate line-breakable and commonly escaped characters from decyrptions and tags. #14

Closed winhowes closed 9 years ago

winhowes commented 9 years ago

This should make decryptions easier to decrypt and reduce tag size

urandom2 commented 9 years ago

I really like the concept, as the line breaking that occurs with gpg always annoyed me. However this brings up other issues, what characters can we reliably assume will not be stripped everywhere and if we have access to these characters[I am assuming that we would be using unicode or something else standard], is it possible to use them in addition to the current characters to expand the compression factor? This does require rewriting your encoding scheme and that could be harder than just swapping two characters.

Would you prefer a character that is not '~'? I can go for anything just keeping with your crypt [it looks like ~~crypt~~ is an issue here] style. We can use some unicode here as well to decrease the likely-hood of a collision/false positive.

urandom2 commented 9 years ago

P.S. I like the concept of sticking with ascii if we can as it is much safer.

winhowes commented 9 years ago

Yeah so I was thinking of:

    • -> $
  1. / -> )

and using ! to denote that the "ciphertext" is a nonce for a short message (#11) instead of decryptable ciphertext. None of these characters should be line breaking. Right now ciphertexts are base 64 encoded so we can just stick to ascii with these substitutions.

Regarding the tags, I thought it might be helpful to change them to ~grdme~ and ~.grdme~ for start and end tags respectively. Right now it handles false positives gracefully so it's not that bad and they're also less likely to happen with "grdme". This also sorta promotes the thing which is cool, and I think it's fairly compact. The character that I really wanted to eliminate was the / in the end tag as it was line breaking.

Another thought on tags though is just to leave the start tag and switch the end tag out to something else as it doesn't really need the end tags in a lot of cases. This would help minimize the breaking change that this will be. Once we've settled on something and done a more official "release" we can't change the tags

urandom2 commented 9 years ago

If you wanted you could use one of the other base64 standards for replacement: https://en.wikipedia.org/wiki/Base64#Implementations_and_history But it is not too important. Otherwise all your suggestions seem reasonable

Do you want to stay away from small tags for any reason, "~cyhpertext~"? I really like the concept, as they look much cleaner, but realize they might be too undercover.

I realize this should pined down before any sort of official release.

winhowes commented 9 years ago

Yeah actually Modified Base64 for XML identifiers (Name) option ( "_" and ":" ) looks like a good option. I'm fine with small tags, I was trying to keep the tags kinda small, but still unique enough to thwart most false positives. The more false positives the more performance decreases, so I'm totally open to a short tag we just need to decide on something that's unique and should "never" occur in the wild. So that means the tag must be at least 2 characters if not 3 characters long. Also the end tag should be a little different from the start tag for performance reasons/decryption reasons - there's a few corner cases where having the same tag gets a bit messy. As for what the tag should be I'm wide open to suggestions

urandom2 commented 9 years ago

That sounds great, from what I can tell nobody uses the ^?/0x7f character. I sent you an email with the sites I looked at, and the only time that '^?' I found it was the "~^?^?" that I appended to <Winston Howes - Messages.htm>. From what I can tell it is likely that nobody uses ^?, and "[generic printing character] ^?" should be pretty unique. Thoughts?

floryst commented 9 years ago

Careful using ^? though, some sites likely do strip non-printable ascii. Facebook, Twitter, and Github don't, but you can't easily tell for others. A 4-character random tag seems like it would suffice.

urandom2 commented 9 years ago

I agree with this concern, but in testing it is the only non-printing that nobody strips. Twitter is the worst I have found, and they let that one through.

urandom2 commented 9 years ago

also, FLORYST!!!

winhowes commented 9 years ago

Welcome Forrest :) I think I'm in the same boat and sticking to 3-4 character printable ascii is probably best. Although I absolutely love the ui elegance of the ^? character.

urandom2 commented 9 years ago

thought: would you want to use ^? on white-listed domains? while we cannot stay that it will work with every service, we could say that it will work with some services, it looks pretty sparse on the web [sites.tar.gz], and some do not strip it

winhowes commented 9 years ago

We could, but a whitelist seems a bit tacky/thought of implementing a whitelist doesn't seem too fun, and it makes things weird if you copy and paste to somewhere else that's not on the whitelist

urandom2 commented 9 years ago

I agree, and will rescind the request; it would likely be more hassle in the long run.

urandom2 commented 9 years ago

So, at this point plan is [code] ~grdMe~ cyphertext ~.grdMe~ [/code] ??

winhowes commented 9 years ago

So, per more discussion with both of you today I have switched the tag from crypt to grdme and the closing tag's / to an exclamation point (!). I also realized their may potentially be issues with underscore so I was thinking of using ) and : for the two substitutions. Any final thoughts before I push the change?

urandom2 commented 9 years ago

Nope, I think that sounds great; did you make a decision about how to deal with old users after the hard-fork?

winhowes commented 9 years ago

Yeah, I'll just tell the ppl currently using it to switch over. We'll lose a little bit of work, but not a lot, so it's fine.

winhowes commented 9 years ago

For documentation's sake: I changed : to ( due to JSON issue that would have been annoying/slightly slower to work around

urandom2 commented 8 years ago

This issue was moved to GrdMe/GrdMe#19