DIY ciphers/encryption

:: Homebrewed Ciphers/Protocols? :: Hey Lain, I was wondering if any of you have hobbyist projects you work on related to ciphers or encryption protocols. I love this stuff even though I'm bad at it. I've had a few ciphers that I tried making over the years for various purposes. The last one I made was designed to be easily deciphered by hand, yet dynamically expandable to higher dimensions (a first ever I believe), and mathematically impossible to bruteforce (another first). I did the first two pretty easily but the last part was more problematic for obvious reasons. You can still technically bruteforce it, but it would be more like pure luck or random chance than an actual bruteforce. There is no cap on the processing time or power required to exhaust keys like there is with all other ciphers, so I guess I got half-way to mathematical impossibility. *shrug* The outline for the cipher is here - https://snerx.com/sniph - and when I finish coding it I will through it up on github (or share it sooner if people care). I know I'm not the only hyper-autist on this forum lol, so I'd like to see similar projects you guys have worked on.

>There is no cap on the processing time or power required to exhaust keys like there is with all other ciphers generally you put a limit on the size of the key when doing such analysis. As for your cipher, it looks like a pretty interesting twist on substitution ciphers. I might do a cryptanalysis of it tonight, not like I have anything better to do. I've never personally made a cipher worth talking about. As a teenager I had that dumb idea like all budding cryptanalysts that I could make a OTP cipher without all the downsides, but it ended up just being a soykafty stream cipher.

>>3904 >it looks like a pretty interesting twist on substitution ciphers Yea, someone else described it as vigenère ciphers seated inside vigenère ciphers, and that's close to what it is. >I might do a cryptanalysis of it tonight If you do, please share your process/code, I would love to see how to do this. Even if nothing comes of it, all info like that is useful to me. >not like I have anything better to do. You are on lain after all lol. >but it ended up just being a soykafty stream cipher. Do you mind sharing it anyways?

>>3905 I don't have the code anymore. This was 5 years and 2 hard drive failures ago. Do you have some code I can see for the key generation and what values are considered 'secret' (not to be shared by common implementations)

>>3906 or just really detailed descriptions. The description on your website isn't detailed enough to really know the cryptosystem(how are S-boxes generated?)

>>3907 oh also HTTPS is broken on your website. Drops the connection.

>>3908 I'm not having an issue with the TLS, and the cert isn't expired so idk what to say about that. >Do you have some code I can see for the key generation No I don't. All the examples in the test git were done by hand. I'm not a coder and half the impetus for making this was that I could do it by hand. If anyone wants to adapt the code from the prior project similarly named Snyph, they are free to do that since the code is publicly available. I will actually pay you hard skrilla if you want to code the rest of this, but until I find someone to finish it the code won't be available. >or just really detailed descriptions. This I can do. The pathways to the characters are arbitrarily or /randomnly/ chosen, since the pathways don't matter except for shifting/transforming the charset. The 'end-tables' as I call them are where the charset starts to get chosen, the second-to-last table is what I am calling the 'end-tables' and are more notable than the last tables, or 'final tables' here. I am bad at naming these and am open to suggestions lol. All tables in that second-to-last dimension (read: end-tables) start as being completely identical. The position '1-1' of each of those tables expands into the same charset layout of the final tables, where A is in the first position, B is in the second, etc. The remainder characters are wrapped into the second spot '1-2' of the end-table. So these all start as being identical. As noted in the gdoc, this would make it seem like the pathway up until the last two dimensions could be disregarded because the last tables are all the same, but this is not actually the case. The pathways are used to determine how many shifts of the charset need to be applied. This is why I believe each character's ciphertext also serves as a one-time-pad, since each character (or at least the disproportionate majority) will have unique pathways to their end-tables. The pathway before the end-table is added up (the x-y mentioned in gdoc) and the total is given as the number of shifts of the charset, just like a Caesar Cipher. The way this transformation /looks/, is by taking the total, let's say it was 5, and then adding those 5 characters to the start of 1-1, so when 1-1 in the end-table is expanded, 1-1 of the final table is now '9' instead of 'A' (given the charset in the gdoc). 1-2 of the final table is '0' instead of 'B', etcetera, until you get to 1-6 (or an equivalently wrapped 2-N depending on the table size) which is where you get your first 'A'. So the 'key generation' that you asked about should be well-limned now. The OTP keys are not decided by the user, at least not in the code version, because the pathways are randomnly chosen. I think the beauty in this is that, if I'm not a retard and missing something obviously crippling about this, I've found a way to make OTP keys randomly assigned and yet also arbitrarily reversible if you know the table size and seated dimensions. I am basically a retard though and so I'm sure someone will be able to show a devastating flaw with this. Hopefully this can be used as a launching pad for true perfect secrecy though.

>>3910 weird, when I use a US proxy HTTPS works fine but when I use a dutch proxy it doesn't work at all. >The 'end-tables' as I call them are where the charset starts to get chosen, the second-to-last table is what I am calling the 'end-tables' and are more notable than the last tables, or 'final tables' here. I am bad at naming these and am open to suggestions lol. All tables in that second-to-last dimension (read: end-tables) start as being completely identical. The position '1-1' of each of those tables expands into the same charset layout of the final tables, where A is in the first position, B is in the second, etc. The remainder characters are wrapped into the second spot '1-2' of the end-table. So these all start as being identical. okay, so, if the table size is bigger than the alphabet each character in the last table is offset by all preceding numbers in that character of the ciphertext, and if the table size is smaller than the alphabet then the alphabet is truncated in each table? Or are both effects at the same time?

>>3911 ah, wait, it's x-y. So, in your example, H is encoded as 2423, but shouldn't it be 2421 since the alphabet gets shifted by 2-4 = -2?

>>3912 er, I mean shouldn't it be 2425, 4-2 = 2

>>3911 >okay, so, if the table size is bigger than the alphabet each character in the last table is offset by all preceding numbers in that character of the ciphertext, and if the table size is smaller than the alphabet then the alphabet is truncated in each table? This sounds correct, but just keep in mind the tables can't be bigger than 10x10 since 0-9 are the only characters used to represent them, making it max out at 10 total. >>3912 >So, in your example, H is encoded as 2423, but shouldn't it be 2421 since the alphabet gets shifted by 2-4 = -2? Okay, a couple things, the first: The tables in the gdoc are not accurate, it's just for representational purposes, although I suppose I should make them more accurate so it's less confusing? The 5x5 tables in the gdoc have no transformations applied because they have no prior pathways, those 5x5 tables are the end-tables and final tables as I've described them, with no preceding tables. I noted in the gdoc that in order for this cipher to actually work, you need a minimum of four sets of tables, or four 'seated dimensions', whereas the doc only shows two. This was to save space so that on a 16:9 display you could see the entirety of the text and example tables all at once, but it also means it's not accurate to what the cipher would actually expand into. Second thing: Let's say we did it the proper way and the pathway did indeed shift by -2, The charset would indeed be shifted, however that shift starts at 1-1 of the end-table (not reset per final table), so by the time you get to 2-4 (of that 5x5 table in the gdoc), you have to keep in mind that the tail of the charset is already wrapped from all the other spots in that end-table, so the final table from the end-table's 2-4 probably doesn't start at 'A' like I have showing, it would already look shifted like the 5-3 position does (although again these are not accurate). I hope this clarifies it. All that being said, what do you make of it so far? Am I coming across like a retard or does this look like it has potential to do what I am claiming it can do?

>>3915 okay, so with the table size 3x3 and 4 dimensions, with indexes starting at 0, would 12011211 decode to A?

>>3916 or would it decode to E?

>>3917 wait nvm it can't decode to E, messed up a bit there.

>>3916 >okay, so with the table size 3x3 and 4 dimensions, with indexes starting at 0, would 12011211 decode to A? So as I've shown in the table spot titles and charset, numeration starts at 1 and ends at 0, 0 stands for 10 in this cipher. I know that this isn't how a lot of programming languages handle this, since arrays start at 0 and 1 means 2 for them, but like I said I'm not a coder, and even if I was I think this is stupid. One should mean one, not two. Anyways, indexes starting at 1, not 0, your example of a 3x3x10 with a path of '12011211' is parsed as the following: The first part of the ciphertext is '1201', which is the first two dimension's pathway, 1-2 and 0-1 respectively for the first two tables. This is what's used as the transformation/shift data. 1-2 = -1 and 0-1 = -1, totaling -2. All end-tables, and therefore final tables, start the same. The 1-1 position of this end-table would spit out a final table whose 1-1 position is 'A', the 3x3 in the gdoc is accurate in this regard. The 1-2 position of the end-table here spits out a final table whose 1-1 position is 'J', as the gdoc shows the cut off charset needs to be wrapped through the rest of the tables (otherwise you could not access the entire charset by default). So now we have to apply the transformation; a shift of -2 would make the end-table's 1-1 position spit out a final table whose 1-1 position is 'C', since C is two letters down from A. This same end-table's 1-2 position would then spit out a final table whose 1-1 position is 'L', since L is two letters down from J. The transformations should make sense now, you seemed to have thought previously that the transformation was per-final table when it is actually per-end-table (technically both I guess). So now we have the second part of the ciphertext, '1211'. 1211 is the end-table and final table positions/spots. 1-2 means you've selected the second position in the end-table and 1-1 means you've selected the first position of the final table, which given the gdoc and our applied transformation, means you selected the character 'L'. If you or someone else requests, I will put a full derivation of a text, like we just did, as part of the description on the webpage or gdoc, but I was hoping it was clear enough that this wasn't needed.

>>3916 if so, I think I cracked your cryptosystem. You basically are putting the caesar cipher key into your ciphertext, so each letter is encoded as a series of offsets(all the x-y bits), and the last two numbers are just coordinates for the letter itself. The only wonkiness here is that the alphabet might not fit in the last tables, and it repeats through the second-to-last tables. So, if you let S be the sum of offsets, we can succinctly state your cipher as P = plaintext, d = dimensionality, n = side length of tables, j = last y-value, k = last x-value, A = size of the alphabet P = ((sum(offsets) mod (n^2)) + j*n + k) mod (A)) we don't have to worry about the offsets being modulo n because we're already doing mod n^2. if we assume all indices start at 0. I encourage you to check this, as I'm not exactly sure if this is correct. A full example in graphical form would be really helpful. Anyway, this is very cheap to compute if we know n and A. I assume A is a known quantity, so all we have to do is find d(to know what are characters and what are offsets) and n, and finally we need to find the wrap point. So the amount of tries to brute-force this algorithm is 200*n*d, which in most cases be less than 100,000 since n < 10 and a value of d greater than 50,000 would make messages far too large to be useful(a 10-letter plaintext would encode to over 1,000,000 digits). if you confirm that my understanding of the algorithm is correct, I'll write a program that decrypts it.

>>3919 I'm not going to bother with offsetting everything by 1. Starting at 0 makes the math much cleaner and doesn't affect the cryptosystem.

>>3919 3x3x4*, not 3x3x10. >>3920 Sorry lol, try again.

>>3921 >Starting at 0 makes the math much cleaner and doesn't affect the cryptosystem. Not true, it fuarrrked up my math in critiquing your example, since 0 can't show up in a 3x3 table given the framework outlined in the gdoc. I don't understand why coders insist every number has to mean a different number. 1 = 1 in my system, keep it simple lol.

>>3923 literally just start indices at 0. It doesn't change anything. I'm not going to change anything about my math to make it work with indices starting at 1.

>>3920 >You basically are putting the caesar cipher key into your ciphertext That is explicitly what I am doing, as this seems to be the only way to randomnly gen OTPs without the parties having to agree on them in advance. >each letter is encoded as a series of offsets(all the x-y bits), and the last two numbers are just coordinates for the letter itself. Correct. >the alphabet might not fit in the last tables It shouldn't fit in most or all of the tables depending on the table size. This is why it wraps. >n = side length of tables There's no reason the table sides have to be the same length. The cipher works just the same for 3x9, 8x2, and 7x10 sizes. >I'm not exactly sure if this is correct. I'm bad at math and have no idea if what you put is like my thing or not, but we can say it is for argument's sake. I would critique your use of, "we don't have to worry about the offsets being modulo n" however, because you have to keep in mind that you don't know how many dimensions are being used when you see only the ciphertext, and the dimensionality expands the text drastically, meaning you might start look for your 'j' and 'k' variables five characters in, like the 3x3x4 example, or 97 characters in if the table was 100 dimensions deep. There's no way to tell this without knowing in advance. >this is very cheap to compute if we know n and A. You mean 'd' and 'd', right? You would have to know both the table size and dimensionality in advance, and at that point it is supposed to be easy to compute, in fact it's so easy you can do it by hand like I've been doing lol. This is the point, if you know the configuration of the cipher in advance it's supposed to be easily reversible. The issue is that you can't know the configuration in advance by seeing the ciphertext. >so all we have to do is find d Good luck? lol >since n < 10 No, the table size is always less than 100, not 10. >a value of d greater than 50,000 would make messages far too large to be useful Unless you do it to encode a single sentence. There's no reason you can't since it's easy to process the ciphertext output. If you expand a 2,000 page book at 10-D it would like comparably large, and there's no way to tell how long the plaintext input was prior to deciphering it, so the seated dimensions can be whatever you want (this is scalable as processing power increases). What you've proposed might cut down processing time to decipher, but bruteforcing a decipher is still exponentially to exponentially more processor intensive than outputing ciphertext, and again this scales however high you want. Actually, what you've proposed doesn't cut any processing time because you still have to systematically check every table starting at 3 dimensions deep and work outwards to 10, 50, 1000 dimensions? The number of tables you have to check increases exponentially quicker than your algorithm could crawl it.

>>3925 >each letter is encoded as a series of offsets(all the x-y bits), and the last two numbers are just coordinates for the letter itself. Sorry, not correct, the last *FOUR* numbers are the coordinates.

>>3925 >since n < 10 I was incorrect in saying you were incorrect, yes n would be 10 or less.

>>3920 the inner modulo's sign has to be preserved. I'm reasonably confident in this, it works for 2421->H(subtract 1 from every number to use the equation) but I don't have a way of generating examples to work on easily and I don't want to do it by hand. >>3925 >That is explicitly what I am doing, as this seems to be the only way to randomnly gen OTPs without the parties having to agree on them in advance. you're sending the key along with the ciphertext. You don't see how that makes it easy to break? >There's no reason the table sides have to be the same length. The cipher works just the same for 3x9, 8x2, and 7x10 sizes. I didn't realize this. m_n = width of nth table(9 possible) n_n = width of nth table(9 possible) offset_na = first coordinate of nth offset offset_nb = second offset sum = sum ((offset_na mod n_n) - (offset_nb mod n_m) over n = d .. 3 s2 = size of 2nd-to-last "end" tables (has to be a composite number between 9 and 100) (71 possible) n = height of last "final" tables (7 possible) m = width of last "final" tables (7 possible) P = (((offset sum) mod s2) + (j mod n)*m + (k mod m)) mod A So now we have to do at most (200 mod 2d)*71*7*7*sum(81^d) over d = 1 .. L/2 tries, where L is the length of the message(obviously d cannot be greater than L). 200 can be mod 2d because we don't care if we get some junk letters at the start or end, we just care if we get the rest of them right. ;) that sum(81^d) is actually gonna get pretty big as d increases, but I maintain that in most practical applications d will be low. If the attacker knows the approximate length of the plaintext(which is a very very real cryptographic attack), they only have to check around d = L_ciphertext/(2*L_plaintext), which lowers the required processing time by roughly an order of magnitude. any d<4 would be easily breakable on a modern PC in a month or two, and a large cracking effort could probably pull off d<10 if you optimized the algorithm for some edge cases. Given that your key size(amount of information required to properly decode a message) is on the order of 20+7d bits, and that this is a very basic cryptanalysis, your cipher doesn't do well versus AES-128 for the same key size: 120 bits of security in the best case versus 126 in the worst case for AES-128.

>>3928 >n = height of last "final" tables (7 possible) I'm not sure why 'n' and 'm' are out of 7, shouldn't it be 10? The math seems sketch, but the problem remains as admitted in the following... >you're sending the key along with the ciphertext. You don't see how that makes it easy to break? I do now lol, but I'm not sure how else to do it. I will have to augment the structure of the cipher but how should it be done? I think if I make it two-stage'd I can fix this problem. If the path is also ciphered this issue goes away (and reduces the size of the output significantly), but only this issue, I now believe there is still a fundamental problem with this cipher because you could run an algo that tests every table size and dimension and the OTPs are then inconsequential. That ^ problem btfo's my cipher imo. So unless I can figure out how to make the pathways non-arbitrary when deciphering, this is provably weak now.

>>3928 >>3929 Okay, so after thinking about it a bit, you don't need to include the OTP keys in the ciphertext if the OTP keys can be generated themselves the same way the tables are (you could wrap this all up in user input in the cli). If the pathways chosen to the end-tables weren't random, and you could predetermine them, like by using a passphrase, then you wouldn't need to include the OTP keys in the ciphertext and the pathways would be obscured. This would also significantly reduce the output size, as all dimensional inputs, from 4 to 400 would only give 4:1 plaintext:ciphertext outputs because the outputs would only include the end-table coordinate and final table coordinate (four characters total). This quadruples the text size from input to output, but that's far less than 400x'ing it. I believe this solves the OTP key problem, however I think another problem persists- the dimensionality is now totally arbitrary because the pathways to the end-tables (the OTP keys) can be reduced to a range of 70 since that's the size of the charset. So ~70 iterations would have to be tried until you got the right one. Maybe this is a non-concern, because you would have to do this for every character and there wouldn't be any consistency between them since they each carry a different OTP key. Let me know if you think this solves the problem. Talking to people about this has been fun and I'm learning as I go, so pls no buli lol.

>>3930 I feel like this is /too simple/. I'm sure people have made OTP's generate based on passphrases before, right? Doesn't that solve the problem of OTP's being impractical or of perfect secrecy? I mean what I'm proposing is slightly more secure because the same passphrase doesn't garuntee the same output since the table size and seated dimensions also need to be known, but that's basically just like adding another layer, the core principle of OTP key generation has surely been tried before, right? If this is what most encryption algos use and I didn't know then I'm actually retarded lol.

>>3929 >I'm not sure why 'n' and 'm' are out of 7, shouldn't it be 10? 3x3 is the minimum size for the final tables, no? >>3930 >you don't need to include the OTP keys in the ciphertext if the OTP keys can be generated themselves the same way the tables are which brings up the main problem with OTP: transporting huge keys securely. >So ~70 iterations would have to be tried until you got the right one. 70^length, actually, since the addand is different for every character. >>3932 >I feel like this is /too simple/. I'm sure people have made OTP's generate based on passphrases before, right? that's called a stream cipher. An OTP is only an OTP if the keys are truly random and never re-used. It's a legitimate thing, but then the problem becomes, how do you efficiently generate data to add to your plaintext? It's harder than you might think.

>>3933 >It's harder than you might think. It always is. >that's called a stream cipher. An OTP is only an OTP if the keys are truly random and never re-used Can't you just have a built-in RNG make up a 32-char or 64-char passphrase? This would make the keys random. >how do you efficiently generate data to add to your plaintext? What do you mean by this? Are you worried people will be able to guess what's being written because the length of the output will be proportional to the length of the input? Or do you mean how to pass on the keys being used without revealing them?

>>3933 I solved the problem of re-using OTP keys as well. Just now edited the gdoc to show (and will probably continue to edit) you could re-use the same passphrase, the same OTP keys, and get completely different outputs over and over even if you're giving the exact same input. There is a separation between the OTP keys and the random selection by the code for which table position it should choose. If this is confusing, the gdoc should make it more clear now. So not only could you consistently generate new OTP keys, but reusing them creates completely different output text, so the issue of being able to reverse OTP keys goes away since they don't generate the same output. I'm sure I'm still missing something here (and please help me find it) but I feel like this problem that is hard to tackle is not an impossible problem. Again, even if I'm wrong about something here, do you think that at least someone will be able to use my cipher as a launching pad for something stronger?

>>3934 >Can't you just have a built-in RNG make up a 32-char or 64-char passphrase? This would make the keys random. the problem is entropy. If you're generating 1024 bytes from a 32 byte passphrase, you still *only have 32 bytes of entropy*, even if the PRNG is perfect. Basically, the point of a cipher is taking the randomness from the key and distributing it evenly and securely into the output. >What do you mean by this? you need to make good pseudorandom numbers. That's not easy. >>3936 >you could re-use the same passphrase, the same OTP keys, and get completely different outputs over and over even if you're giving the exact same input. the difference is superficial. You change up the values but they mean the same thing. It's not OTP if you reuse a key. Bottom line. >Again, even if I'm wrong about something here, do you think that at least someone will be able to use my cipher as a launching pad for something stronger? maybe. You'd need to make it a lot easier to understand before anything useful could come out of it imo, and simplify it to be more efficient.

>>3937 >the problem is entropy. Right, but as you can now figure out from what it says in the gdoc, since the passphrase used doesn't align with the table dimensions, a 32-string passphrase equals much higher entropy since the pathways are dynamically made given the input passphrase. >you need to make good pseudorandom numbers. That's not easy. Right, or just a five-word-long phrase. Seems pretty easy to me to be honest. Unless you can tell me what's not easy about randomizing a passphrase (use diceware if you have to) then this seems like a non-problem. >the difference is superficial. You change up the values but they mean the same thing. Maybe you misunderstood. I'm not changing the values at all. I'm saying with the exact same inputs, not just plaintext but variable inputs, the exact same table size, seated dimensions, passphrase for OTP keys, all of it, with all of that being the same, hitting enter in the cli generates different outputs each time. If you understood this and mean something else, then I'm not sure what you're calling 'superficial'. >It's not OTP if you reuse a key. Bottom line. Using the same passphrase (which determines the path chosen) but different table dimensions makes for different OTP keys. I mean, yea you might get lazy and use the same settings multiple times, but having the choice to do either just means you have the freedom to gen new keys each message or not. I mean, the paper pads that they used to use for OTPs got reused a lot of times, sure by title it's no longer "one-time" but being able to generate them arbitrarily allows you to use them one-time and toss them if you want. >You'd need to make it a lot easier to understand before anything useful could come out of it imo, and simplify it to be more efficient. If someone is willing to get paid to code it, having a working cli will make it much easier to understand. And as far as efficiency goes, I still maintain that this is incredibly efficient as far as generating ciphertext goes. There are no higher maths involved and it can still be done by hand (although somewhat more time consuming now).

>>3938 Now that I've slept on this, I am actually extremely confident that this does what I've described it does, and I can prove it. This is like if the algo from Library of Babel's website (https://libraryofbabel.info/) 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 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. Further, 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. All you can do is try every possible combination, thereby generating every possible combination of characters within a 4-character 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 lmao. 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 plaintext is even if you had infinite computing power. I have solved the problem. I have completed the system of German Idealism. I am your god now. Bring me your virgins.

>>3947 have fun with that

>>3948 It's already done. It's provably complete. Ignore the meme at the end of that last post, I figured out a solution to the problem and I'm confident it works. Don't trust my confidence though (obviously), try to break it yourself. Try to even conceive of a way in which you could successfully match up the ciphertext with a possible plaintext that couldn't also be matched up with many many other possible plaintexts that contain radically different yet equally plausible text. This is important not to dismiss; even if you think my particular cipher fails in this regard, the process described can be utilized for 'opaque boxes', principle'd lock-aways for information. This is wildly useful, don't you think?

>>3949 >It's provably complete. "I can't break the cipher I created" does not mean "my cipher is provably complete". >>3915 >does this look like it has potential to do what I am claiming it can do? no, not at all. but if you could provide a detailed and formal step-by-step description, we can tell you precisely why. you also don't need to claim anything, as the protocol will make it all clear enough. ---- Assume that parties A and B wish to communicate across an insecure channel. A and B have chosen to use the SNIPH n-dimensional cipher in an attempt to keep their communication private. A wants to encrypt the plaintext message "LAIN" and send it to B. Detail how keyphrases are generated and shared. Generate and provide a keyphrase to be used in the demonstration. Provide information on what kind of padding is used, if at all, and also how it is generated. Explain how each character is encrypted, step by step (one character at a time). Explain how the keyphrase is reused and how a new ciphertext is generated by it each time. Explain how the ciphertext is decrypted into plaintext by B, step by step (one character at a time). ----- Extras: Calculate: - The number of transformations needed to encrypt 1 bit of plaintext. - How the above number compares to the number of required transformations in for example a simple XOR-OTP or AES. - The (unavoidably finite) period of the ciphertext or keyphrase, assuming key reuse. - How locally and globally random the ciphertext actually is, during transaction 1 as well as later Explain how Sniph is "in principle" impossible to brute-force, and how this differs from being actually impossible to brute-force. Explain how "ciphering text with Sniph comes with very little processing cost since no higher maths are used", when both basic and higher math is in fact processed in the same non-abstracted way: by many iterations of simple logical operations. Explain how "Every possible table size and dimension combination has to be generated and tried in order to attempt a brute-force of ciphered text under Sniph" is exempt from the realistic half-keyspace brute-force concept. Explain how E's processing cost scales disproportionately relative to A/B's processing costs when dimensions and table size increases. Explain why anyone would want to use an algorithm that creates a 400-character ciphertext out of a 11-character plaintext ("hello world"), amounting to a 36 times overhead (2.75% signal; 97.25% noise).

:: WALL OF TEXT, SOZ LOL :: I tried answering all of your concerns, and I tried matching how smarmy you were about it too lol. >>3986 >"I can't break the cipher I created" does not mean "my cipher is provably complete". It's a good thing nobody said that then, huh? >"but if you could provide a detailed and formal step-by-step description, we can tell you precisely why." I'm not going to repeat it ten times here. If you need something more detailed than the full explanation which is given in multiple places now, I'll be uploading the code soon, with lots of comments, you can look at it then. >"Detail how keyphrases are generated and shared." This is given in the gdoc. >"Generate and provide a keyphrase to be used in the demonstration." The passphrase of 'henlo' given in the gdoc should work. >"Provide information on what kind of padding is used, if at all" For the sake of example, like the ones given in the gdoc, assume there is no padding. In the cli there will be an option to pad and offset the padding, but this isn't required for the cipher to be understood. >"Explain how each character is encrypted, step by step (one character at a time)." This is also given in the gdoc, as well as many posts here in this very thread lol. >"Explain how the ciphertext is decrypted into plaintext by B, step by step (one character at a time)." You just reverse the process, a process which should be incredibly easy to understand considering it is basically just a Caesar cipher shifting a Vigenere cipher. >"Explain how the keyphrase is reused and how a new ciphertext is generated by it each time." This is also given in the gdoc. Did you even read it lmao? >"Calculate: - The number of transformations needed to encrypt 1 bit of plaintext." Depends on the depth the user chooses (meaning the number of seated dimensions). The maximum number of shifts that matter, however, are 70, since that's the size of the charset. So maximally, it takes 70 total shifts to cipher/decipher. >"- The (unavoidably finite) period of the ciphertext or keyphrase, assuming key reuse... Explain how Sniph is 'in principle' impossible to brute-force, and how this differs from being actually impossible to brute-force." If you read the gdoc and are still asking this, then you fundamentally misunderstood what I'm going for here. I explicate that you can in fact bruteforce this, the issue is that you can never know if you did, this offers an absolute deniability of generated plaintexts. To obviate, you can crawl through every possible character combination in this cipher, just like you can in the Library of Babel's algo, but doing so is meaningless. A good distinction to understand here is which side of the IF / WHEN is being attacked. All ciphers, to my knowledge, have thrown out the IF, and said it's not a matter of IF people will be able to pair the palintext to the ciphertext, it's a matter of WHEN, and so they try to make it exponentially more difficult to bruteforce. I went the other direction, I said let's throw out the WHEN, let's give them infinite computing power and let them have all possible outputs immediately, who cares, they won't be able to tell IF any of their particular plaintexts were the original plaintext to match up with the ciphertext. Again, this is like the Library of Babel algo, the only thing ciphertext gives you is the page size you're crawling through. Unless you know the page number in advance you can't know which page you're supposed to be looking at. It's principally locked away. Hopefull this makes it more clear, and if it doesn't, then at least it's pretty meta that the explanations for how a cipher that creates a hermeneutical lacuna are themselves cryptic, no? lol >"Explain how 'ciphering text with Sniph comes with very little processing cost since no higher maths are used', when both..." This is just to say that I've been doing it by hand, it's relatively easy to do it by hand, and anything you can do by hand on a single sheet of paper is going to be done a lot faster by a computer. That is, at least to cipher and decipher given the variables in advance. If you are just crawling through the combinations randomly, like if you were trying to bruteforce it, it would take longer. That's all that was meant by that. >"...is exempt from the realistic half-keyspace brute-force concept." Same reason for the Library of Babel. There's only so many possible permutations of characters in a 10x10 grid, so this is already assuming you've cut down the bruteforce time, and assuming you're already getting unique combinations each attempt. >"Explain how E's processing cost scales disproportionately relative..." This is given in the gdoc... >"Explain why anyone would want to use an algorithm that creates a 400-character ciphertext out of a 11-character plaintext ('hello world'), amounting to a 36 times overhead (2.75% signal; 97.25% noise)." OKAY LOL I understand your problem for sure now, you actually didn't read the gdoc lmao. It's a 4:1 plaintext to ciphertext input:output, not 36:1. Yes, this still inflates it four times, but I don't see why memory space is a concern here if you want to have infinite deniability of obfuscated text. I mean if you're willing to cipher a 2,000 page book, then you were willing to store a really large PDF in the first place, which means you're willing to store four equally sized PDF's. Storage memory is cheap, right? Ghatdam my dood. You could have saved me this entire response if you just said right at the start of your post, "I didn't read the fuarrrking thing that describes how this works," lol.

>To obviate, you can crawl through every possible character combination in this cipher, just like you can in the Library of Babel's algo, but doing so is meaningless. A more common analogy might be a basic xor encryption to explain this, since people are more likely to be familiar with it that the library of babel. Since you can turn any byte into any other byte by xoring it with a certain key, it's meaningless to try all keys - you just end up with all possible plaintexts.

>>3987 >I tried matching how smarmy you were about it too. This is noise. >It's a good thing nobody said that then Oh, not explicitly. That's just how it seemed in >>3949, given the context. >I'm not going to repeat it ten times here. You haven't provided a detailed and organized structure even once. Try a properly numbered list, with examples, or something like picture related. >This is given in the gdoc. The gdoc where H is considered the 7th letter in the alphabet (but listed as the 8th letter in the 3rd dimension) but E is the 5th? The gdoc where the tables demonstrating how the protocol works "are not accurate", according to >>3915? >also given in the gdoc, as well as many posts here in this very thread No. The method is scattered and vague. >You just reverse the process Yes. And you need to demonstrate how you do this to demonstrate your protocol. That's how you show its functional symmetry. You demonstrate to yourself, and others, that other features such as the generated keys work repeatedly for both parties. >[how the keyphrase is reused and how a new ciphertext is generated] is also given in the gdoc Sure, but it's vague, unstructured, not detailed. Every part of the presentation of the protocol is sub-par. That's why I'm helping you by providing information on how to present things in a way that allows for peer review. >it takes 70 total shifts to cipher/decipher. Cheers. >I explicate that you can in fact bruteforce this I guess our definitions for "explicitly" differ /somewhat/. But if you're simply suggesting it's bruteforce-proof due to its claimed multi-use-OTP nature, then your point is clear. >[how E's processing cost scales disproportionately relative...] is given in the gdoc No. For any proper protocol, this is specified for various given values. For x amount of processing time spent by A to create a string of n bits, adversary E spends y amount of processing time. For x^10 amount of processing time spent by A, E spends z... And so on. And a simple description of how it scales for the different parties. >you actually didn't read the gdoc I did, but it was horribly unstructured. That /may/ be why much of the thread so far consists of clarifications and you explaining to people what you actually meant and what the protocol actually does. I'm personally used to more ordered articles. >It's a 4:1 plaintext to ciphertext input:output, not 36:1. Cheers, my bad. I didn't account for the bytes. >You could have saved me this entire response No, you could have saved me my responses (and the responses of several others in the thread) by presenting something that wasn't protected from cryptanalysis through obscurity. For future reference, please bear in mind that when your point doesn't appear to be getting across - the only two available options aren't "the person isn't listening/reading" and/or "the person is retarded". You could simply be failing to present what you mean in an accurate way. I hope the questions/template I provided will help with this.

>>3988 Yea, but I didn't know what xor encryption was. Since that's supposed to be the same thing, does that mean this problem has been solved? I thought in order to do this you would have to use an OTP, and those don't work very well because they're one-to-one input to output so you could reverse the keys if you reused them, no? If the solution to this is to make it one-to-many input to output, then I've done that, and surely this has been done before as well, right? >>3989 >"This is noise." You talk a lot but you don't say anything. >"You haven't provided a detailed and organized structure even once." I guess you'll never get the description you're looking for then lol. >"The gdoc where H is considered..." Yea, that one. It's not a whitepaper, it's a lazily made outline, get over the flaws or it'll become too difficult to yell responses to you up there on your high horse. >"The method is scattered and vague... it's vague, unstructured, not detailed." For you. >"Every part of the presentation of the protocol is sub-par." Hey, if you want to write up the whitepaper on it, feel free lmao. I did this as a goof, stop being mad that you spent your academic and professional life trying to do what I did in an afternoon. >"That's why I'm helping you by providing information on how to present things in a way that allows for peer review." Well hey, I'm helping you by letting you know a fuggin gdoc isn't what anyone here is seriously considering should be presented to a journal for peer review lol. Nice framing tho, letting me know that you clearly know better and you're just helping out the little guy here lol, could you be more pretentious? >"For any proper protocol, this is specified for various given values." No one said this was a protocol, let alone a proper one. All I've said is that this is a cipher with certain properties. >"For x amount of processing time spent by A to create a string of n bits..." Again, if you want to write up a technical paper on this, feel free, no one is stopping you. >"That /may/ be why much of the thread so far consists of clarifications..." Actually no, the gdoc was radically different when I started the thread. After things were clarified, those clarifications were added to the gdoc. You just suffer lower reading comprehension and probably low T as well, but feel free to write a paper on that too lol. >"you could have saved me my responses... by presenting something that wasn't protected from cryptanalysis through obscurity." But it's funnier this way, especially since you're such a negative person and you're getting mad for no good reason. >"the only two available options aren't 'the person isn't listening/reading' and/or 'the person is retarded'... You could simply be failing to present what you mean in an accurate way." Por que no los dos? >"I hope the questions/template I provided will help with this." Naw, I actually think your questions and template are really unstructured, vague, not detailed, scattered even, and sub-par. Try again next time.

>>3911 >US proxy works with HTTPS >Dutch proxy doesn't maybe your dutch proxy is MITMing you. >>3990 otp is (typically) implemented via xor encryption, so they're the same thing. It's in fact entirely trivial to reverse the key if you have the ciphertext and plaintext of a xor encrypted message, since ciphertex ^ plaintext = key.

>>3991 unlikely, considering that I run it.

>>3991 But if you already have the plaintext then you don't need the key wtf lol... >>3992 Are you sure you aren't MITM'ing yourself?

>>3993 known-plaintext attacks are a major weakness. want key -> craft plaintext that you know will be encrypted -> derive key from ciphertext

>>3994 Right but I mean if they're practicing good opsec then are the chances of getting the plaintext really higher than just bruteforcing the keys lol?

>>3994 actually i'm not sure you could do this with the cipher in this thread unless you are able to get many plaintexts and correlate many ciphertexts if you had just one plaintext and one ciphertext how would you be able to determine the "table dimensions" or "pathways" here? there would be many keys or passwords that get you the ciphertext from the plaintext i think

>>3990 >stop being mad Stop assuming that I'm somehow trying to bring you down. Try to realize that I provided a template for you that will make it easier for other people who want to take part of what you create. >your academic and professional life [...] No need for such ad-homs. >a fuggin gdoc isn't what anyone here is seriously considering should be presented to a journal for peer review "Peer review" isn't limited to scientific journals. You posting this in this thread is an example of a peer review request. >could you be more pretentious Yes. But that would be pointless. >No one said this was a protocol Well, that's not a very controversial claim. It does fit in various definitions of that word. Whatever you would like to call it, you bring the topic of scaling up in your gdoc. I'm just letting you know that you can easily properly calculate the scaling ratios for different bit sizes and such. >[insults re. reading comprehension and testosterone] Off-topic. >you're such a negative person / you're getting mad It seems to me like you're projecting. Ask yourself how much you're feeling insulted by the technical criticism I've provided, and the basic technical demands I set up for the text you provided. I'm just providing you with feedback. You're the one who keeps insulting me in various ways, and that would mean (to any rational observer) that you're the one who is the most "mad". >Por que no los dos "Dos" for the first part is covered by the and/or. If you wish to include the third option, and yet again attempt to insult me, you need to say "Por que no los tres". >I actually think your questions and template are really unstructured The questions are posed chronologically based off a standardized scenario. They're not wildly dissimilar from what is found in textbooks. Nothing controversial about them. The "extras" are basic things you need to know how to answer (in a structured way). Please learn to accept criticism and feedback, /especially/ when that's what you're requesting.

>>3990 Please note: you're the person who said: >It's provably complete >I am actually extremely confident >I have solved the problem. I have completed the system of German Idealism. I am your god now. Bring me your virgins. (albeit jokingly) >stop being mad that you spent your academic and professional life trying to do what I did in an afternoon. ... While also complaining about other people being pretentious, and asking them to get off their "high horses".

>>3395 this has nothing to do with opsec. It has to do with the security of the cipher.

>>4000 oops, that was >>3995 not using js is so annoying ;_;

>>3997 "I'm not trying to bring you down, I'm just pointing out why I'm better than you in every regard, why can't you understand that you fuarrrking plebeian?" - You. You're a condescending ~ F A G G O T ~ and your failure to understand that I am matching how smarmy you are being, even after you directly quoted it, means that at the very least we're equals lol. >>4000 How does having such poor opsec that someone can easily obtain your plaintext not a matter of opsec???(Always argue in good faith and avoid using personal attacks.)

>>4002 because you don't know whether a given piece of information was designed in such a way. It's a thing that is done in practice all the time to break ciphers.

this thread is worth nobody's time.

>>4004 You sound defeated lol.

>>4005 Not him but this thread is like two people calling eachother glitterboys and arguing about a small detail related to opsec

>>4006 Four posts out of the total are us two doing what you said, but yea. I stopped and I think he did too. >>3996 Kinda, you could get multiple keys/passphrases but then you would just test the few you got on other captured ciphertext and only one passphrase would give you non-gibberish. However, I'm sure someone could modify the cipher and create a new second layer utilizing the same property as the first, and make it so that /many/ passphrases matched with the plaintext and ciphertext. I don't know how to do that though, I think there would need to be an actual search algo like the Library of Babel and the ciphertext would just be the page number (not literally, but something analogous), so no keys involved at all. The question then is how you stop other people from plugging in the page number and getting the plaintext every time. Actually, you could just do both. You could cipher the page number and only ever send ciphered page numbers, but the process would have to be modified.

>>4004 seconding that >it's yet another basic cipher from someone who doesn't realize how little he knows

>>4008 Never said it wasn't basic, but since you know better, what's wrong with it?

>>3995 >>3993 there's a good deal of use-cases where the ciphertext is only meant to be encrypted for a certain period of time, e.g. classified documents that will later be declassified. Consider also if an adversary is within your agency, doesn't have access to your key, but can report messages that need to be encrypted. They report a message, send that message to their colleagues, and their colleagues determine the key from it. >>3996 >if you had just one plaintext and one ciphertext how would you be able to determine the "table dimensions" or "pathways" here? I'm not sure if you could determine the key from a plaintext sample, but there are weaknesses that allow you to learn a good bit of information: # Since the input_size:output_size ratio directly corresponds with the number of dimensions, you learn that piece of information. # Since 0 ≡ (dimensions - 2) mod pass_size AND dimensions - 2 >= pass_size, so you can immediately reduce the size of the set of the possible passphrases by a large magnitude. ## The above can be circumvented by continuing from the last position used in the passphrase when finding the path for the next letter. This may have been intended in the pdf, but the phrasing there indicates the process ends after reaching dimensions-2 nodes in the path, then restarts for the next path. If that's not the intended case, the spec should be reworked. # Since the passphrase directly corresponds to the paths chosen, aside from the random paths chosen at the end, you can use the paths for each letter in the plaintext to deduce information about the passphrase. e.g., if a passphrase was "aaa" meaning each step takes the 1st position in its respective table, the ciphertext would begin with 111111. This is somewhat mitigate by using all the numbers, 1-9, even with D < 9, but with a large enough sample, it would be trivial to determine when this obfuscation is occurring. # With a large enough sample, an attacker could map pathways together. For example, say the attacker knows that both 111213 and 333213 map to 'x' at different points in the ciphertext. He can then determine that 1112 and 3332 point to the same table with reasonably high likelihood (or, a table in which x is at the same spot). It's not a 100% likelihood from a single correlation but with enough correlations it approaches 100% certainty. You could probably work backwards and reduce the size of the set of possible passphrases this way too but I don't want to think about it. There's probably some other inferences you can make from a known-plaintext attack but I'm a little drunk right now. >to create the first cipher that is in principle impossible to mathematically brute force. Update your website to clarify that there are ciphers that are impossible to bruteforce, e.g. the xor cipher mentioned earlier. >>4002 any weakness in a cipher is a weakness, whether or not you want to shift the blame to someone's poor opsec. >easily nobody said acquiring the plaintext would be easy, but it's a very real possibility (leaks, hacks, etc) for most agencies. Analyzing plaintext samples is how America broke the Enigma cipher in WWII, after all, iirc.

>>4010 ># Since the input_size:output_size ratio directly corresponds with the number of dimensions, you learn that piece of information. Except it doesn't, it's always 1:4 input to output no matter what. >you can use the paths for each letter in the plaintext to deduce information about the passphrase... the ciphertext would begin with 111111. Because of what you pointed out way earlier, the key is no longer given in the ciphertext, the ciphertext is just the coordinates of the last two tables, nothing else, hence the 1:4 input to output. ># With a large enough sample, an attacker could map pathways together. No longer true by having only the ciphertext. If you have multiple plaintexts and paired ciphertexts, you can do this, but again, like in >>4007 I believe this can actually be worked around. I want to finish the code for the first part first though so I can share it here and have people complain about how bad it is before I work on this new part. >but I'm a little drunk right now. What are you drinking? lol >Update your website to clarify that there are ciphers that are impossible to bruteforce, e.g. the xor cipher mentioned earlier. Will do, but if these are the same, as in have the same property of being unable to determine the passphrase used to encrypt, then why are all common encryption protocols still worried about the amount of time it takes to bruteforce? If this already exists, why haven't people switched over to it yet? Is it just taking a long time to convince people? >Analyzing plaintext samples is how America broke the Enigma cipher in WWII, after all, iirc. I'll definitely try to fix this too then after I finish the initial code and redo my entire website and gdoc since apparently no one can follow it lol.

>>4011 >>Update your website to clarify that there are ciphers that are impossible to bruteforce, e.g. the xor cipher mentioned earlier. >Will do, but if these are the same, as in have the same property of being unable to determine the passphrase used to encrypt, then why are all common encryption protocols still worried about the amount of time it takes to bruteforce? If this already exists, why haven't people switched over to it yet? Is it just taking a long time to convince people? Well let's walk through xor encryption to highlight its weaknesses. xor encryption is very simple: you xor the plaintext with the password to produce the cipher text. Let's look at this in binary: [code] pass: 10101010 text: 01010101 cipher = code ^ text = 11111111 [code] To decrypt, you just xor it with the password again. [code] 11111111 ^ 10101010 = 01010101[code] This is works because of a property of xor: ( A ^ B ) ^ B = A. It's impossible to simply bruteforce a password because of another property: For two arbitrary bitstreams, call them A and B, there exists a bitstream C such that A ^ C = B (coincidentally, because of the above property, this C = A ^ B). In less mathy terms, if you have a "ciphertext" of n bits, you can "decrypt it" to every 2^n combination of n bits. So, an adversary could try every possible key (2^n) and he'd just end up with every possible message that could be sent in n bits. No help for him. Here's the problems: # the key has to be as big as the plaintext. Wanna encrypt a 2gb file? Better get a 2gb key. This is just impractical in most use cases. # plaintext attacks. Since ( A ^ B ) ^ B = A, then ( plaintext ^ ciphertext ) = key. If an attacker gets a hold of your plaintext, he can determine the key. So key re-use is unacceptable. Couple the inability to reuse keys plus the need to make keys the same size as plaintexts, and you have a massive headache on hand regarding practicality. sorry if that was too in-depth of an explanation than needed, im still drunk. >># Since the input_size:output_size ratio directly corresponds with the number of dimensions, you learn that piece of information. >Except it doesn't, it's always 1:4 input to output no matter what. Ah, I see. The passphrase is used to jump through the tables until the last two, then the ciphertext tells how to jump through those. Since an attacker doesn't know the passphrase, he can't get to the same table represented by the first pair in the ciphertext, so the pairs there don't help him. Neat. >What are you drinking? vodka mixed with off-brand koolaid.

>>4012 not that it's a big deal but here's the code tagged items properly wrapped in tags. whoops pass: 10101010 text: 01010101 cipher = code ^ text = 11111111 11111111 ^ 10101010 = 01010101

>>4012 ># the key has to be as big as the plaintext. Wanna encrypt a 2gb file? Better get a 2gb key. This is just impractical in most use cases. Except you don't need to store the key anywhere, I thought you said you had done this as a stream cipher before, the passphrase engineers the key in real-time while encrypting/decrypting, so I don't see how this is impractical. ># plaintext attacks. Since ( A ^ B ) ^ B = A, then ( plaintext ^ ciphertext ) = key. If an attacker gets a hold of your plaintext, he can determine the key. So key re-use is unacceptable. I'm trying to think how this could be stopped. If the plaintext doesn't correlate to the ciphertext directly, or rather if the key didn't correlate to the ciphertext directly, then maybe this could be avoided? Have people tried using hashes as outputs? If the ciphertext was always a 64-character hash block (length arbitrary for example), then there wouldn't be any direct or proportionate relations between the plaintext and ciphertext. Reversing the cipher would be more difficult but I'm sure someone has tried this before, no? >sorry if that was too in-depth of an explanation than needed, im still drunk. If it says it in the abstract on wikipedia, it can't be that in-depth lol. >The passphrase is used to jump through the tables until the last two, then the ciphertext tells how to jump through those. Since an attacker doesn't know the passphrase, he can't get to the same table represented by the first pair in the ciphertext, so the pairs there don't help him. Neat. How much did you drink lol? You're the one that made me change this. Are you not the same guy from earlier in the thread lol? >vodka mixed with off-brand koolaid. Are you a teenage girl? Is it at least good vodka?

>>4002 >You're condescending [+ various other insults] Well, thank you for yet again proving my point. Good luck with this truly groundbreaking cipher.

>>4014 with a typical xor cipher the key is as large as plaintext. You can use a CSPRNG with the key as a seed, or some other algorithm to convert the key to a stream, but then it's not mathematically resistant to bruteforcing in the same way. >>4014 >I'm trying to think how this could be stopped. If the plaintext doesn't correlate to the ciphertext directly, or rather if the key didn't correlate to the ciphertext directly, then maybe this could be avoided? Have people tried using hashes as outputs? If the ciphertext was always a 64-character hash block (length arbitrary for example), then there wouldn't be any direct or proportionate relations between the plaintext and ciphertext. Reversing the cipher would be more difficult but I'm sure someone has tried this before, no? hashing the output is going to screw over decryption. A hash is, by definition, one-way. >I'm trying to think how this could be stopped. with a plain xor cipher, it can't. But xor is used in a lot of encryption algorithms along with modular arithmetic, padding, nonces, etc, that greatly increase its strength. Triple-DES, and AES, for example, utilize xor operations. >How much did you drink lol? a lot. >Is it at least good vodka? it was the cheapest vodka at the liquor store. >Are you a teenage girl? y-yes

>>4016 >with a typical xor cipher the key is as large as plaintext. You can use a CSPRNG with the key as a seed, or some other algorithm to convert the key to a stream, but then it's not mathematically resistant to bruteforcing in the same way. You seem to be saying contradictory things now; is my cipher like a xor cipher or not? If it is like a xor cipher, then it is resistant to bruteforcing in the same way, and in the way you yourself described. If it is not, then why was it suggested I equate my cipher to a xor cipher? The keys are seeded or streamed /and/ are resistant in the same way as described, so is this meaningfully different than a xor cipher or not? >hashing the output is going to screw over decryption. A hash is, by definition, one-way. Unless the hash is the page number the text appears on, the page number or 'hash' is then always x/y pages whose total is a set number of digits (0932, for example). The library of babel can easily reverse this, and this is analogous to how the 'keys' feed in my cipher which is why I kept referencing their algo. This is why I'm now confused. Either this is better described as you are saying, by calling is a xor cipher, or since apparently it doesn't have the properties of a xor cipher, it is better described as I was saying, by referencing the Library of Babel. >Triple-DES, and AES, for example, utilize xor operations. Is it impossible to knowingly bruteforce these /and/ stop plaintext attacks? If not, then they aren't good examples for what you were talking about. If they can, then why do people still worry about "a matter of time" for bruteforcing attacks to happen? They can't in principle be bruteforced, yet I can google the amount of time it takes to bruteforce their keys so is this problem solved or not? Maybe my descriptions are vague because the answers to my questions have been vague. ARE THESE PROBLEMS SOLVED OR NOT YET? >it was the cheapest vodka at the liquor store. Why do this to yourself?

>>4018 I just figured out the problem with my cipher that I think is the problem you were trying to get at with these kinds of ciphers in general. Let's say you bruteforce it and ~1% of the keys result in plausible plaintexts. Okay, so you don't know which keys are the right ones, but all you have to do now is use those keys on a new ciphertext you intercept, and this time you only have to bruteforce for ~1% of the time of the original because you know which keys to start with. You can do this a couple more times over until there's only one set of keys that output non-gibberish and you've then successfully bruteforced the passphrase. This works because the total number of keys is finite, limited, and that finitude, that limitation, is determined by the maximum 10x10 table size and 70-character charset. But I set it to 10x10 max table size just to test this as a proof of concept and so I could do it by hand on paper. The table size can actually be whatever you want. The depth or 'seated dimensions' become arbitrary after 70 because the charset is 70 and so you can only shift it 70 times before it becomes meaningless, but the table's length and width never becomes arbitrary. The table size could be 100x100. The output would inflate 8 times, not 4, (the coordinates would be ##-##,##-## instead of #-#,#-#) but this wouldn't matter much. The table size could also just as easily be 1,000 x 1,000. The output would inflate 16 times here. So there is an infinite drawer to sift through here. There's an infinite amount of plaintext and key combinations possible, you would never be able to knowingly exhaust keys and you could never knowingly match plaintexts to ciphertexts since those matches are possible with and infinite amount of keys. So I take back what I said earlier, I'm not changing my webpage, because the dynamically scalable capacity of this cipher makes this is the first cipher to truly be impossible to bruteforce.

I recommend you learn a little bit about crypto, and stop using terms that don't have precise definitions, if you want to be taken seriously.

>>4021 Learning as I go, and all definitions are precise lol. I suggest you don't take people on the internet seriously and you'll solve both our problems.

>>4022 doesn't seem like you're learning so much as berating people who try to teach you. >all definitions are precise not in the slightest.

>>4020 I'm not going to waste much time on this, other than to quote Schneier: "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break", and make the point that anything remotely resembling a modern cryptosystem with a large enough keyspace is theoretically "unbruteforceable". The problem is, that's not really how modern cryptographic attacks happen. We've moved a long way from small keyspaces and known plaintext attacks; that was in the 1930s. I haven't looked at your code, but history is littered with the bones of cryptosystems invented by people who thought they were unbreakable. Do the rounds of your cryptosystem contain predictable difference propagation? Is there a predictable input/output correlation in your rounds? If so, your cryptosystem is already broken.

>>4023 >"doesn't seem like you're learning so much as berating people who try to teach you." I berated the guy who berated me. Again, me and him are equals. The other people who have offered help have been very nice, as I have been back to them. When I said hyper-autistic in the OP, I was joking, you guys didn't have to go full-social-outcast and try to belittle everyone you deem unworthy lol. >"not in the slightest." What then is 'defined' by the limned semantic? If a definition is given, is not the semantic /exactly/ that definition? Would this not then be 'precise'? >"I'm not going to waste much time on this" You didn't have to waste any time, yet here you are being a pretentious tool like the britbong was. >"and make the point that anything remotely resembling a modern cryptosystem with a large enough keyspace..." Okay but if you're making this argument then you don't understand the problem we're trying to solve here. It is this very thing you describe that we're trying to work around- to make the size of the keyspace a non-issue. >"history is littered with the bones of cryptosystems invented by..." For sure, and as I've said a few times in this thread, I hope someone finds out how to break my cipher, because I'm not that smart and surely you guys know better. I'm not being sarcastic when I say this (maybe some of the 'berating' was the reader's projection). >"Do the rounds of your cryptosystem contain predictable difference propagation?" No.

>>4031 >Would this not then be 'precise'? He's asking you to write it out formally. Give a mathematical description so it can be analyzed. If you don't know how to do that, implement it in code. If you can't do that either, at least give a complete example. Start with "Allen wants to send the string 'SECRET' to Bob", and walk through all the steps he would have to take. >No. Prove it.

>>4032 There was a complete example given starting from the first post, it was a gist sample, and the steps should be in chronological order given in the gdoc. But I know this isn't enough for you all, so here's the code (still a wip), should be working on python 3.x https://github.com/VivaCaligula/SNIPH

I know this thread died and I've been an annoying punk etcetera, but for a laugh, has anyone tried making a stream cipher where the randomness for generating new keys is determined by the plaintext being encrypted? "How would you share the key?" Well you would just send the plaintext so they could decrypt the cyphertext back into the same plaintext lol. A serious version of this I've tried: you can reverse the typical stego process and take the most significant bits of an image as your key for the message stuffed inside of it (MSB since LSB is altered by the stego process; a unique way to combine crypto with stego). This still requires an additional password. The password deterministically selects where to start picking pixels from, making every cyphertext as random as the images you pick to hide them in. Other people with the same image file cannot reproduce the keys despite the same source of entropy. In this way, every message has a source of 'true randomness' so long as you use a new image every time; this was the only way I could think of to have a 'true' CSPRNG at the time. All my attached pics, from past posts and including the current, are examples of this stego method in practice.

I wrote some python that encrypts text using any ebook you want. It puts every word from the book into an array, then looks up each word from the text in the book and replaces it for the element's index number. You need the exact pdf/epub to decrypt each message you encode.

>>4102 sourcecode?

>>4103 I'm pretty amateur at this so forgive me if my coding is poor. There's a few problems with the program, one being if a word is not present in the book then it cant be encrypted. #! python3 import string import array import textract import sys plainTextFile = "filelocation" encryptedTextFile = "filelocation" bookFile = "filelocation" start = input("encrypt or decrypt: ") if start == "encrypt": try: booktext = textract.process(bookFile) plaintext = open(plainTextFile, 'r') except: print("file missing") sys.exit(0) pt = plaintext.read() ptList = pt.split(" ") bt = str(booktext) btList = bt.split(" ") code = [] place = 1 for pword in ptList: try: place = btList.index(pword) except: pass code.append(str(place)) resultCode = "" for number in code: resultCode += number + " " print(resultCode) if start == "decrypt": try: booktext = textract.process(bookFile) encrtext = open(encryptedTextFile, 'r') except: print("file missing") sys.exit(0) et = encrtext.read() etList = et.split(" ") bt = str(booktext) btList = bt.split(" ") decoded = [] for number in etList: try: word = btList[int(number)] except: word = "_error_" decoded.append(word) resultText = "" for word in decoded: resultText += word + " " print(resultText)

>>4031 I'm too lazy to check, the circles turn into 4x8-bit numbers, which may or may not be plaintext. Each ring of each circle is an 8-bit number. This was an intro-level challenge at a CTF I went to.

>>4108 Nope :)

And I don't mean to sleep in this dead horse, but I finally got around to making a technical document that describes the cipher in painful step-by-step detail, so everyone can stop complaining now: https://snerx.com/sniph.pdf In case there is still some doubt about what this does, the test code is here: https://github.com/VivaCaligula/SNIPH And the old output tests used for breaking Sniph are here (will update soon): https://gist.github.com/VivaCaligula/d350161385c2f163cccd20fcbbc0c9fa I am also running a pseudo-bug-bounty. If anyone can find a cipher-breaking flaw that isn't already described in the technical document, and can show how to implement an exploit for it, I'll send you 0.01 BTC, the poor man's hundred-dollar bill.

>>4390 Not sure what you mean by "cipher-breaking". Cyphers are just security through obscurity. If I found something encoded with that cypher, I could just run sniph.py -d which you just linked to. What would I need to "break" the cypher for?

>>4397 How would you guess the passphrase? Ciphers are not /just/ obscurity... Something that would 'break' the cipher is something that would reliably return you the plaintext and keys used every time without knowing them prior.

>>4401 didn't realize it had a passphrase, thought it was just encoding like base64 or rot13, since the `if flag == 'd':` case only asks for the cyphertext, not a key

>>4404 Nah, the cli asks for a passphrase every time.

seems a lot like the spanish strip cipher op

your webpage isn't loading OP fix ur SSL

I'll get out the cryptographer's toolbox and get that .01 BTC tomorrow night, maybe thursday.

>Page 9 https://snerx.com/sniph.pdf >However, if multiple plaintexts are given with their matching ciphertexts, I believe there may only be some keysets that match up in the same dimensionalities between the pairs. The more ciphertexts you test will narrow down, very swiftly, which of those keysets is valid because very few, if more than one at all, will work with the same dimensionality each time. Or so I think. If p[N] and c[4N] are obtained by an attacker from a single observation, where each is the compromised plaintext of N characters and ciphertext of 4N characters respectively, then could this not be treated as N plaintexts of p[1] and N ciphertexts of c[4], thus leading to the "swiftly narrowing of valid keysets" cited? Due to the encryption process being the same each time for characters 1 to N (the dimensionality, and table size are constant throughout the encryption/decryption process).

site is ded