Be careful with PDF! There are many ambiguities in the specification that are implemented differently between parsers, as well as implicitly accepted malformations that almost all parsers will silently accept without warning. It is very easy to accidentally produce so-called file format schizophrenia: When the same file is rendered differently between two parsers. For example, with PDF, what if you have a PDF object stream that has a length that doesn't agree with the position of its `endstream` token? What if you have a PDF dictionary with duplicate keys? Do you use the value of the first key or the second? What if you have two, valid PDFs concatenated one after the other? Do you render the first or the second? What if an object in the XREF table has an incorrect offset?
Shameless plug: I am one of the maintainers of PolyFile, which, among other things, can produce an interactive HTML hex editor with an annotated syntax tree for dozens of filetypes, including PDF. For PDF, it uses a dynamically instrumented version of the PDFminer parser. It sounds like it might satisfy your use case.
Companies (particularly financial institutions) that have enterprise apps deployed only to their employees care because a jailbroken phone imposes the risk of attackers MITMing traffic.
Ethereum contracts are effectively Turing complete (well, technically linear bounded automata complete). But you get the same state space explosion issues as with formal validation of any other language.
We number with BCD in honor of the HP48 calculator's floating point implementation, which matches decimal rounding errors. 0x0A, &c., are reserved for special issues in the future ;-)
Hi, I'm Evan Sultanik, author of this toy cryptosystem. (Emphasis on "toy.") My intention was never for this to be a commercial grade cryptosystem, nor was the focus ever on truly securing the ciphertext. I suggest you read the PoC||GFTO article from issue 0x04, as it goes into more detail about the motivations than my short blog post. My claims about the probability of a key existing in the public domain that decrypts a given ciphertext to any desired plaintext makes the assumption that the ciphertexts and plaintexts are all English language books. This was glazed over in my blog post (once again, cf. PoC||GTFO 0x04). The math behind that claim was first developed in an older blog post: http://www.sultanik.com/blog/copyright-quandry which itself was motivated by a much more abstract thought experiment in what it means to infringe upon a copyright.
Shameless plug: I am one of the maintainers of PolyFile, which, among other things, can produce an interactive HTML hex editor with an annotated syntax tree for dozens of filetypes, including PDF. For PDF, it uses a dynamically instrumented version of the PDFminer parser. It sounds like it might satisfy your use case.
https://github.com/trailofbits/polyfile