Sniph

I am currently heavily editing this page and the technical document that goes with it so a much clearer and full description of the entire process from start to finish can be illustrated. I hope this brings legitimacy to the cipher on top of what the github code already produces. -------------------------------------------------------------------------------------- Sniph is meant to be a dynamically shifting multi-dimensional cipher. The impulse for creating this cipher was twofold: to create the first dynamically scalable N-dimensional cipher and to create the first cipher that is in principle impossible to mathematically brute force. This is accomplished by using a combination of several well-established cryptographic techniques (like symmetric key streaming), as well as a new one, with psuedo-random segmentation between the two that allows for absolute deniability of encryption. This also makes the use of perfect forward secrecy irrelevant since the keys can never be reverse-engineered without creating a hermeneutical lacuna, or gap in the knower's capacity to know which keys were used with the original plaintext. Further, I wanted to be able to use a homebrewed cipher without higher-maths so the entire process could be easily done by hand on paper. This is a work in progress but all these goals are now provably met. This gdoc explains how the cipher works. The same document is archived as a PDF here. Since the keys are random (or random enough), are longer than the plaintext, can be kept completely secret, and their reuse does not generate the same output/ciphertext, the resulting ciphertext is impossible to decrypt or break. Even if the OTP process is found to be insecure, it is no longer questionable if this cipher has the property of perfect secrecy- the key material is not from a truly random source, the OTP keys (or given this cipher, 'pathways') are generated around the given input dimensionality, but this does not pre-determine the keys, since the complete particular pathways are ultimately chosen randomnly and the representation of those pathways is obfuscated by the stand-in numbers; this is then impossible to reverse without simply knowing the passphrase/OTP beforehand. A more in-depth description of this property is as follows (requires gdoc to understand): This is like if the algo from Library of Babel's website was turned into a cipher. In order to brute force this you would have to generate every possible character combination for the spots shown in the ciphertext, and even if you knew the table dimensions you would still have to generate every possible character combination. So while you could technically brute force this, you would never know if you did because you wouldn't be able to tell which combination was the right plaintext. For example: You're given a string of 16 characters as a ciphertext, so you know the plaintext was 4 characters long (unless extra characters were added to the ciphertext), and now you have to try every pathway combination to each of those coordinates in the ciphertext in order to figure out the passphrase/OTP used. The problem is that each character carries a different pathway/OTP key. Each character might be shifted over by an entire charset (in this case that's 70 characters total), so you have to try every possible shift of the charset for each character. There is no way to line these up and know if you got all the OTP keys right for each individual character in a way that specifies a single viable plaintext. This should make it obvious now, in that sure you'll have bruteforced it, but you'll have bruteforced everything else at the same time and have generated every four- letter word in every language using latin characters past present or future. Again, this is like the Library of Babel's algo, you can reverse engineer any text out of any other text and it's all contained within a set space (in this case four characters). So sure, you could crawl through it, but there would be no way of knowing which word was the right word. As with individual words, so with whole sentences and books. Within a 5,000-character plaintext space, you would generate all 5,000-character sequences possible, including every text in every language (using latin script) ever possibly made, and including every copy of the original plaintext with single-character deviations. This becomes absurd. There's no way to tell what the particular plaintext was even if you had infinite computing power. Jay Lapham requested some examples of ciphertext to see if it could be broken. This gist is currently serving as that test, and will be changed out with more robust examples once the code for the cipher is updated. Sniph is based on an older project of mine under a very similar name, the sourcecode of which is hosted here. Note: duplicating the xor property of the shift to the table dimensions means there will be dual-OTPs, or competing key sets you will be required to bruteforce. This can extend to the charset size as well which would create a stuttered charset wrap and mean three OTPs will be competing (triple redundancy). Additionally, these could be controlled by separate passphrases. If the same property could be applied to the output itself, then an infinite amount of keys would always work for an infinite amount of plaintexts-to-ciphertexts, making plaintext attacks meaningless, but I have no idea how to implement this.