81–90 of 112 posts
There are a little over 256 unicode Combining Marks that have a 2-byte UTF-8 encoding. I picked a set of them, defining an encoding I call zalgo256: https://gist.github.com/DavidBuchanan314/07da147445a90f7a049... Since an arbitrarily tall stack of combining characters still counts as one grapheme cluster, if some application limits string length by counting grapheme clusters then you can stuff an unlimited amount of…
I did something similar a while back but using all the invisible characters to encode extra data into telegram messages for metadata storage https://github.com/sixhobbits/unisteg
I had fun writing a Racket version: #lang racket/base (require net/base64 threading) (define FIRST-INVISIBLE-CHAR 917760) (define (invis-encode str) (list->string (for/list ([c (in-list (string->list str))] #:do [(define cnum (char->integer c))] #:when ( char (+ cnum FIRST-INVISIBLE-CHAR))))) (define (invis-decode str) (list->string (for/list ([c (in-list (string->list str))] #:do [(define plaintxt-c (- (char->intege…
There are a little over 256 unicode Combining Marks that have a 2-byte UTF-8 encoding. I picked a set of them, defining an encoding I call zalgo256: https://gist.github.com/DavidBuchanan314/07da147445a90f7a049... Since an arbitrarily tall stack of combining characters still counts as one grapheme cluster, if some application limits string length by counting grapheme clusters then you can stuff an unlimited amount of…
Also I'm reminded that the unicode normalization annex suggests that legitimate grapheme clusters will be 31 code points or less. "The value of 30 is chosen to be significantly beyond what is required for any linguistic or technical usage."
It's hilarious that Stream Ciphers are the closest thing to the One-Time-Pad (which provides "Perfect Secrecy") and this thing is a Monoalphabetic Substitution Cipher which provides no security whatsoever.
There are a little over 256 unicode Combining Marks that have a 2-byte UTF-8 encoding. I picked a set of them, defining an encoding I call zalgo256: https://gist.github.com/DavidBuchanan314/07da147445a90f7a049... Since an arbitrarily tall stack of combining characters still counts as one grapheme cluster, if some application limits string length by counting grapheme clusters then you can stuff an unlimited amount of…
HN filters some combining characters? That's weird, compared to the symbol/emoji blocking. Also I'm reminded that the unicode normalization annex suggests that legitimate grapheme clusters will be 31 code points or less. "The value of 30 is chosen to be significantly beyond what is required for any linguistic or technical usage."
Earlier quoted context omitted.
HN filters some combining characters? That's weird, compared to the symbol/emoji blocking. Also I'm reminded that the unicode normalization annex suggests that legitimate grapheme clusters will be 31 code points or less. "The value of 30 is chosen to be significantly beyond what is required for any linguistic or technical usage."
If I had to guess, they probably filtered the ones that could be used to break page layouts by creating very-tall glyphs.
I have been using ROT13, but I’ve been looking for a post-quantum replacement so definitely I’m going to convert to SCREAM. It’s generally understood that qubits are unable to represent or even discern the little squiggly bits above normal Latin letters. Thank you for this important contribution to cryptography!
The important part about applying ROT13 is the number of iterative applications. The security of even-numbered applications is undeniable. Odd-numbered is even better than that. I’m currently building an implementation with fractional rotation. Of course I will post a Show HN when it’s ready.