Anyone play with ciphers? - Page 1
Forum section: electronics / general

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 05, 2016, 01:15:41 pm
content: Like crypto puzzles, and stuff like that. Have a riddle:Code:H]=3g\#t;_c(3,qpyaxu64G):J8Lt7:V;92F61\;!=G28mKw%m6Zt8zq59B([/TW0=X('.[ <W.z$M:W=5$I/5cf!bL'T\*='x2U-9*#%*uW 1k#FW2U-,9/3nLzw\c 'rX=4[,WH*>>w7T :*eIg#Z#0=Xd 7e;9b8!85kvo*iU-1Z=mKVG0+e 0O8zg,#bB6BOwY<=:=>>$#kv<9i(<0%(m$X]6_#4HIu:s0.+P9-'w_#hH2V:P0.+39=l6/[(:[B:PxJ)$/10o7s*9x=*$b+,3:V(=x-WF5m/V1qW(E1:Px<_(/X!g\k$-9/-;xu+9!1j$Y<(:/B:PxJ)$/12m.Z(y8xHzXj+(*\:*7\D-9h-pXj+9!1H$-<(Weje0X<6([xZYH++(/1(O=5w%JA25!5H3u25pB#y mC*lT#uh/1:p0A+(93(,_-X(/1:tTj+:5Iid1x(:! -0J5P9!1H$%h) 5C*$=++E[h(=X3wf5M/v1x(Y8x:zXj+(*::p72$Uo=4Y7-XEi/)t3jP:%24Y7jX(/1:tTj+:\7D3_#4hifV(0.+C9-'W0Qq$9 -;<;U9!1j$0920)XjZE-lP*::P70)F)J-;<-+9!1j$-<)-2BhshJ)*/%2T-<(mE Y*x<_(/Z$$1%TA5I*$>+33[/(=X-w F2'G,QwMehJ5J<6([xLG\0;'RA27!;,M[25pB#D'oM;3_#uhiU)50.+C6:2V0%(:/B:PxJ)$/12,8qW3E%+9><_(/Xl:_#pH:Hj(0.+397>T%[/-9%-PxJ+981:$S:M-6:29!],)S25P=#/Tra2=E+je:V(=xVW K,Iy7.jH:Ft00.+397A<%qW*[BS7>J)*/u2[M4(y(This is only an excerpt; I have another few kB worth I'm working on. More examples aren't hard to find. In fact, it's an HSPICE "protected" model. There's no restriction on downloading, reading or reverse-engineering this code, so don't worry about anything legally.)I've poked at this a bit. The message is plain text, likely uppercase, alphanumeric with some punctuation. May be comments with mixed case. The encoded frequency looks an awful lot like plain text, i.e., just a substitution cypher. I'm not sure yet if the newlines are preserved or converted. The range of characters used are 33 to 122 (ASCII #), plus 10 (LF). It's definitely not encrypted, nor a stateful cipher. That's why I'm thinking substitution.Tim

author: Kalvin
author_rank: Super Contributor
timestamp: June 05, 2016, 01:26:04 pm
content: Tim, you naught boyAnyway, the HSPICE (or spice) has a definitive syntax and keywords, so it should not be too hard to figure out the ciphering algorithm.

author: StillTrying
author_rank: Super Contributor
timestamp: June 05, 2016, 03:00:52 pm
content: "just a substitution cypher"I'd tend think not, because the average byte value is 129.90,which is getting very close to the random averageeven in that small 892 byte sample.I wouldn't really know where to start with that.N Ascii Count %1 58 : 36 4.042 40 ( 34 3.813 57 9 26 2.914 47 / 25 2.805 45 - 25 2.806 43 + 24 2.697 48 0 22 2.478 50 2 22 2.479 36 $ 21 2.3510 49 1 21 2.3511 61 = 21 2.3512 42 * 19 2.1313 120 x 18 2.0214 53 5 18 2.0215 51 3 16 1.7916 35 # 16 1.7917 88 X 16 1.7918 60 < 16 1.7919 55 7 15 1.6820 106 j 15 1.68Edit: Ignore that bit, I forgot to allow for C&P ascii and not binary, but still the frequency is too spread, it looks random to me, good luck with that!

author: amyk
author_rank: Super Contributor
timestamp: June 05, 2016, 04:02:52 pm
content: http://web.engr.oregonstate.edu/~moon/ece323/hspice98/files/chapter_28.pdfQuoteThe name of the circuit is probably the key, the algorithm itself is based on varying permutations at each position. If you have both plaintext and ciphertext together, this doesn't seem hard to break at all, especially if it's a deterministic encryption.

author: Kalvin
author_rank: Super Contributor
timestamp: June 05, 2016, 04:25:25 pm
content: Running the simulator under a debugger and studying the simulator's data memory may reveal deciphered plain text, which can be used for further analysis of the ciphering algorithm. Reverse engineering the cipher using the debugger can also be one option.

author: nctnico
author_rank: Super Contributor
timestamp: June 05, 2016, 04:32:33 pm
content: Quote from: Kalvin on June 05, 2016, 04:25:25 pmThis would be the target of my first attack. Have some idea what kind of encryption is used. It can also be the result of encryption which binary result is then pulled through a uuencoding scheme so the characters are all in the readable ASCII range.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 05, 2016, 09:28:55 pm
content: If it is Enigma, it must be resetting frequently, because further down in the file, there's a passage like so:Code:!KVO*I2v</D<%dH)X#;Y8xafmQPh[1+;0.Pp6:2TOq+H2F0o7cK-2B:0b5)*/H0o7k((E*h)<8_:=AHzXri36:26/c((EV+(j8_:]7*5!jq$96Uyb]Iw:BvLT#2 ) il!KVO*I2v$/D<%dH)X#;Y8xafmQPh/vVS0.Pp6:2TOq+H2F0o7cK-:BE*E;)*/H0o7k((E*Y*x8_:=AHzXUP)6:26/c((EJj5h8_:]7*5!jq$96UyjJ+>(BELT#2 ) il!KVO*I2vi/D<%dH)X#;Y8xafmQPh[ +S0.Pp6:2TOq+H2F0o7cK-$BhPjR)*/H0o7k((EJEs=8_:=AHz=;4(6:26/c((EVS9$8_:]7*5!jq$96UyhV,)(BvLT#2 ) ilThis is two units (so you can see how similar they are), out of I think 40 repeats or so. The variations between each group would be reasonable if they are identical blocks except for net names.I don't see how code like this could possibly arise out of an Enigma process, unless it's being reset each line or something. Which sounds preposterously badly written (but then, so does a substitution cipher..).Lastly, an Enigma process should be producing reasonably flat output frequency. I get an average of 69 over the whole code set, which is close to half the range (i.e., 7-bit ASCII), except any code below 33 is conspicuously absent (I'm not counting LFs), so the average should be 80, not 69.If it resets each line, the frequency might still be skewed, but that still can't explain the similarities in the repetitive section.Here's the frequency for the whole file:Code:BinFrequency5832150296402944222236218482035420147188411875717443170551633516045150561447214184135120135511316013110613169119801171041143311361111951119110953108881065910011310037996692749112191869011189898699847978987710874118747573857046694969976911266626410562122627658101581095873573953705281526551835187519050935068451004510245117431194211541444010740116395236923282297724712011417671110310782110234038063064094096012301240125012601270Ed: graphed below. The curve is really, tantalizingly, suggestiveingly, similar to that curve. As bizarre as that should be (it should be a power law for most language text). The trend curve follows the red data; the blue part looks like a linear tail, dropping to zero for the unused codes.Tim

author: StillTrying
author_rank: Super Contributor
timestamp: June 05, 2016, 10:24:44 pm
content: Quote from: T3sl4co1l on June 05, 2016, 09:28:55 pmWouldn't that be to keep it always printable. Perhaps all codes below 33 can be ignored as data - they're just formating?I imagine virtual rotors that are massive in size compared to the small blocks of data and should work almost like a one time pad, so I'm surprised there's any repeats anywhere!Don't forget that the last line of every block is the same one statement line.

author: amyk
author_rank: Super Contributor
timestamp: June 06, 2016, 04:36:40 am
content: Very simple substitution cipher, and reset every line, but the substitution depends on the position within the line (which is probably why they called it "Enigma".)As mentioned above, HSPICE has a very small number of keywords so the variations within those repeats should give some very good clues about what the substitutions are within each line, based on what varies.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 25, 2020, 03:19:42 am
content: Necropost warning!Heh, bored today, flipping through spreadsheets I remembered this one. Never got anywhere with it back then. Have tried a little correlation today, which has two interesting results:- I think I've decoded numbers 1-8 (or 0-7, or some likely sequence) in column 9, and maybe some others- The cipher may repeat every 16 characters(!)It still seems to be a permutation cipher. Even given a mere 16 columns, that's 96! * 16 possible keys. Of course the permutation wouldn't be picked from truly any one possible, and presumably the permutation is merely rotated each step, if we are to believe the reference to Enigma. (Presumably then, there is one wheel with 96 positions, which moves through only 16 steps before resetting? Or at best two, the second one moving only one carry step.)How does one write such a permutation? Is it enough to say column 1 is x * p^1 (for plaintext x and permutation p), col 2 is x * p^2, and so on? (Where "multiply by p" might be implemented by simply running the left-side operand through a lookup table.)I'm a bit less sure about what the plaintext even is; the periodic (repeats every 10 lines) section seemstooperiodic to be likely SPICE? Unless HSPICE allows component instances of the same name? Take these two groups for instance (lines 308-327):Code:!KVO*I2v$/D<%d:)X#;Y8xafmQLh(/e*0.P)6:2TOq+H2F0o7cK-'B+5$u)*[10o7k((E*Y*x8_:=AHzX;,W6:26/c((E*v9b8_:]7*5!jq$96UybV+m$B+LT#2)il!KVO*I2vi/D<%d:)X#;Y8xafmQ,huj)90.P)6:2TOq+H2F0o7cK-'Bt(>R)*[10o7k((EJEs=8_:=AHzXvJ(6:26/c((E*j*>8_:]7*5!jq$96UyjuIc2BjLT#2)ilThe per-char diff, 10 line spacing, is:Code:000000006900000000000000000-3207759-6015000000000000000000000073-1326-350000000000032-2073-59000000005930-470000000000-12-15-3600000000000000083130-10140630000000If the statements are something like "Mnmos33a 42 47 0 0 MYNMOS", surely the "33a" or "42" or "47" have a lot more entropy? Yet the first columns with variation are the 6th and 7th. Which isn't terribly far from my example statement, that's true, but there doesn't seem to be enough characters remaining on the line. Most of all there are threeidenticallines in this passage; either they're repeated component instances, or they're comments. But they have different starting characters.The second part is line 23,Code:$$y<=-91-pXj+981:$u'(:!%-pXj+981:$,'(:/bJ5eU)*/2j/<2'kA25!j+(/2$pX#/tDA0See it? Column 9 on, wrapped by 16:Code:-pXj+981:$u'(:!%-pXj+981:$,'(:/bIt's not even full length either. S'pose it could be chance, if rather low. Though, flipping through a few other libraries I have, I do see what are most likely long strings of commented "#", encoded in repeating units. Doesn't seem to be any long repeats in this text unfortunately. I'm still not sure how helpful that would be, given that a known string still only makes a few trips through the permutation matrix -- I'd need a full 16x96 block of sequential characters to do that trivially.Attached is a plot of frequencies; gray cells are unused codes, '1's are single occurrences, white cells are multiple occurrences, yellow are >10 and red are >40. (Codes are by row, 32 to 126; columns are ordered same as the ciphertext). The first two columns do indeed look very different, low entropy suggestive of comment ("* ") and line-extend ("+ ") patterns. The plot is left-heavy because there aren't many long lines. Interestingly there are 11 completely unused codes (across all columns): 32, 34, 38, 63, 64 and 123-126 do not show up in the ciphertext (codes below 32 aren't counted, and if 10/13 are any example, don't seem to be encoded). Additionally, 78 and 110 are only used twice.Also saw a hint that ";" shouldn't show up in plaintext because of a bug in some past version of HSPICE, for whatever that's worth.Incidentally, I think I originally had a use in mind for this (plaintext), but that's long since been forgotten. What's more, I also seem to have misplaced the original file, or headers, etc... So, pffbt, this is just for kicks.Full ciphertext:https://www.seventransistorlabs.com/HSPICE_Decode_Source.txtTim

author: dietert1
author_rank: Super Contributor
timestamp: August 26, 2020, 11:01:40 am
content: Have a look here:synopsys.com/content/dam/synopsys/verification/datasheets/hspice-ds.pdf:QuoteElsewhere i found the file looks like this:.SUBCKT Encrypt 1 2 3.protRR1 1 2 100 DTEMP=-8.149999999999977RR2 2 3 100 DTEMP=-8.149999999999977RR3 3 0 100 DTEMP=-8.149999999999977.unprot.ENDSRegards, Dieter

author: amyk
author_rank: Super Contributor
timestamp: August 27, 2020, 03:17:21 am
content: I really don't understand how they can claim "without revealing sensitive information" when the user has both the ciphertext and the key. Then again, most hardware people probably don't understand much about software either

author: NiHaoMike
author_rank: Super Contributor
timestamp: August 27, 2020, 03:46:17 am
content: Quote from: amyk on August 27, 2020, 03:17:21 amJust like other DRM schemes. Which is to say that a determined hacker can break it pretty easily.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 27, 2020, 03:47:50 am
content: Heh well, obviously this version isn't DES, so there's that.I've seen a number of files that contain three sections, "strong" "normal" and "weak" or something like that, there does seem to be some option there, at least from newer versions. (The newer versions being big blocks of hex, with no obvious pattern by eye, though I've only glanced at them.) But that also means they're practically giving away the plaintext and hoping you don't crack their other modes, which just looks... amusing?Tim

author: dietert1
author_rank: Super Contributor
timestamp: August 27, 2020, 05:16:24 am
content: You shouldn't be inviting people to waste their time with nonsense. Inviting people to try and crack a DES cipher or any other serious cipher may be creating hundreds or thousands of wasted hours and frustration. Please stop that.Regards, Dieter

author: helius
author_rank: Super Contributor
timestamp: August 27, 2020, 05:33:59 am
content: Quote from: dietert1 on August 27, 2020, 05:16:24 amThe obfuscation applied to these files, which are used by the application software without requiring any kind of key input, are the exact opposite of a "serious cipher". They are a feel-good measure with no cryptographic protection whatsoever.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 27, 2020, 07:50:02 am
content: You're complaining about cracking DES when the quoted codes are blatantly, obviously some other chintzy thing? Have you even read the thread?Anyway, not like that's at all impossible -- it's a solved problem, and just a matter of it being worthwhile.https://crack.sh/This being an idle curiosity, it is not worth it. And wouldn't work anyway. Because it's not DES...Tim

author: dietert1
author_rank: Super Contributor
timestamp: August 27, 2020, 10:51:42 am
content: I have been involved with ciphers enough to understand that you know very little. You need to understand that a lot of so called cracks were disclosed by insiders for some reason. Don't believe the Mission Impossible junk. Reality is that it takes minutes to implement a private cipher that is mentioned nowhere and that you won't be able to crack. And mapping the result into something that looks like a simple obfuscation is easy enough.As far as i understand from information on the web this is a stateful cipher and you may analyze hundreds of messages without getting anywhere.This is not one of the riddles you may read about on the web.Regards, Dieter

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 27, 2020, 11:08:37 am
content: I certainly know very little, you are right!But you also seem to be implying that it isn't worth investigating anything ever in a field like this, so why bother, more or less. I'm curious why you would feel that way about something?Tim

author: dietert1
author_rank: Super Contributor
timestamp: August 27, 2020, 12:42:04 pm
content: When i start solving a Sudoku, i assume somebody checked the solution before publishing it. Your riddle may be a little unfair in that sense. It may very well give you frustration instead of a kick. But maybe i am wrong and one of the forum members has a brilliant moment and solves this without spending hours, who knows. I would first check whether encryption depends on file attributes like name, size or creation date.Regards, Dieter

author: GlennSprigg
author_rank: Super Contributor
timestamp: August 27, 2020, 01:08:14 pm
content: 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 aninfinitenumber of variations, evenwithin the same 'word'. And there is 'no' Key needed. Also, lengths of 'words' and 'spaces' aretotally 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!"

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 01, 2021, 07:14:14 am
content: [Necropost warning]So I got around to doing a differential comparison. Here's the code and method:https://www.seventransistorlabs.com/HSPICE_Decode.htmlBasically, 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

author: peter-h
author_rank: Super Contributor
timestamp: July 01, 2021, 03:01:36 pm
content: 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 asoftwareDVD 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 01, 2021, 10:07:48 pm
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: July 02, 2021, 07:08:38 am
content: 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 botheringThe 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 02, 2021, 08:30:49 am
content: Well yeah that's what I mean, a couple GPUs can run through 2^35 of something in hours to weeks. Hell, amateurs are cracking random seeds to video games on the order of 2^40 complexity,just for the lulz.Tim

author: peter-h
author_rank: Super Contributor
timestamp: July 02, 2021, 09:48:03 am
content: Not unless you are looking for a good chunk of known plaintext, but if you have that already, you don't need to break anythingLook up the DES algorithm and software implementations. I've done it, written the code... there are ways to speed it up a lot by turning the S-boxes into giant multi-megabyte lookup tables, but still...If somebody is doing crypto to secure some embedded product they will probably use AES256, but the weakness will still be that the key must be stored on the target...