| General > General Technical Chat |
| Anyone play with ciphers? |
| << < (5/6) > >> |
| GlennSprigg:
I create my own 'ciphers'. (Mainly for fun!). I 'think' it is un-crackable, and is 'not' like any existing other!! There are 'no' substitutions, and any original 'characters' can & do have virtually an infinite number of variations, even within the same 'word'. And there is 'no' Key needed. Also, lengths of 'words' and 'spaces' are totally irrelevant! And the principal of any 'algorithms' as such, is impossible to fathom by Reverse-Engineering methods. (For many reasons). If I explained how, you 'would' say... "Oh... Shit. Yea... I see what you mean! Why has no-one thought of that!" :-+ |
| T3sl4co1l:
[Necropost warning] So I got around to doing a differential comparison. Here's the code and method: https://www.seventransistorlabs.com/HSPICE_Decode.html Basically, for every symbol in column N, plot its value as the X coordinate, and its predecessor (column N-1)'s symbol value as the Y coordinate. For each case, increment the pixel value. Then draw with VGA palette (eh, it's handy and has okay contrast between values). If it were a simple substitution cipher, this should produce lots of repeated values. That is, stacking up the results for each column should show lots of repeated pixels. That doesn't seem to be the case here, and there are a few repeats, but probably only statistically many. If it is an Enigma-based method, there may be some repeats as wheels tick over, but without knowing how the wheels or "plugboard" are wired or what steps/wheel, I don't think there's really anything to solve? And without known plaintext (or anywhere near enough at least), each permutation might as well be a one-time pad..? Attached are the results for the commented code at the bottom (view source, copy and paste to console) for offsets of 1 and 2. This stacks (adds up) results from the above method, for all columns in range. The blocky clustering is related to the low frequency (occurrence) of some symbols, which cause the horizontal and vertical cuts. Within each block, the remaining codes seem to be fairly evenly distributed, and also aren't obviously symmetrical. There does seem to be a bit of a checkerboard pattern, don't know if that's significant or not. Tim |
| peter-h:
I don't know why anybody would use enigma or some such, when des or aes256 are dead common, dead easy, and totally unbreakable for all practical purposes. In this case the key must be stored in the product doing the decoding. That is how DVD encryption was originally broken - by disassembly of a software DVD player (PowerDVD or some such)! I would be surprised if enigma produced a uniform character frequency distribution, given that a character would never encrypt onto itself, so I would expect a slightly reduced frequency across the character set of the plaintext. |
| T3sl4co1l:
Well it's not a new thing, I'd take a wild guess they were using this since it was introduced in the 80s. Which would have to be based on public and possibly non-munitions methods. Or someone just clever enough, come up with something novel and probably not very good in absolute terms, but good enough to serve the purpose. It's absolutely not your great-grandpa's Enigma, what with the >= 84 symbol output. (The ASCII coding, in particular the gaps, and conversions of formatting elements like TAB, need not be part of the cipher itself; that could be a pre/post translation step just to avoid certain ASCII and string formatting characters.) I suppose the last thing I should try is, find as much of this as I can, with suspected known plaintext. If it's something like a OTP per column, the permutations are endless; if it were regular text I might have some chance of success, but technical content (SPICE) has a positional bias that may never reveal some columns' full keys. And the variable line length makes it similarly biased against higher columns' keys. It appears they did move to more secure methods at some point, as there are examples where the ciphertext is blocks of hex with high entropy. (Might that ironically be easier to solve, on account of DES being broken? It would be a likely pick for early 2000s.) (And no, I don't have they key in any form. If I really needed to know, I expect I could pirate a copy of the software, disassemble it and find the cipher functions and data.) Tim |
| peter-h:
DES was never broken. All that happened is that the effective key length is reduced substantially (from 2^56 to something like 2^35) if you have a huge amount (megabytes) of known plaintext, and such like, but you are still way way outside the "can crack this with a PC running for a month" area. It's been possible since the 1970s to build a special purpose machine which does an exhaustive search (and looks for an output which looks like some human language) but that's been the sole province of the national security agencies. For this kind of commercial stuff, DES is totally secure. Far more likely somebody will just buy the product and extract the code and the key. Many years ago I was making a product which "encrypted" the code, sitting in two EPROMs (it was a 16-bit CPU; the Z280) by jumbling up the EPROM address and data lines. Before programming the EPROMs we processed the binary with a little prog, done in C in about 15 mins, which did the reverse jumble. This just stopped somebody reading the EPROMs in an EPROM programmer; they would have had to work out the PCB tracks, which were hidden inside 2 solid layers, but they could have done it in some hours with a multimeter. It just p*ssed off some amateur... in fact one of them told me of his attempt and that he gave up bothering :) The code was all written in assembler and would have been fairly easy to disassemble. You just need to do a little bit to make it hard, and most will give up. And if your product is making loads of money you just need to market it fast and make money fast because the Chinese will rip it off anyway. |
| Navigation |
| Message Index |
| Next page |
| Previous page |