Author Topic: Anyone play with ciphers?  (Read 5490 times)

0 Members and 1 Guest are viewing this topic.

Offline T3sl4co1lTopic starter

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Anyone play with ciphers?
« on: June 05, 2016, 01:15:41 pm »
Like crypto puzzles, and stuff like that.  Have a riddle:

Code: [Select]
H]=3g\#t;_c(3,qpy
axu64G):J8Lt7:V;92F61\;!=G28mKw%m6Zt8zq
59B([/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,#bB6
BOwY<=:=>>$#kv<9i(<0%(m$X]6_#4HIu:s0.+P9-'w_#hH2V:P0.+39=l6/[(:[B:PxJ)$/10
o7s*9x=*$b+,3:V(=x-WF5m/V1qW(E1:Px<_(/X!g\k$-9/-;xu+9!1j$Y<(:/B:PxJ)$/12m.Z(y
8xHzXj+(*\:*7\D-9h-pXj+9!1H$-<(Weje0X<6([xZYH++(/1(O=5w%JA25!5H3u25pB#y mC*l
T#uh/1:p0A+(93(,_-X(/1:tTj+:5Iid1x(:! -0J5P9!1H$%h) 5C*$=++E[h(=X3wf5M/v1x(Y
8x: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
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: Anyone play with ciphers?
« Reply #1 on: June 05, 2016, 01:26:04 pm »
Tim, you naught boy :)

Anyway, the HSPICE (or spice) has a definitive syntax and keywords, so it should not be too hard to figure out the ciphering algorithm.
 

Offline StillTrying

  • Super Contributor
  • ***
  • Posts: 2850
  • Country: se
  • Country: Broken Britain
Re: Anyone play with ciphers?
« Reply #2 on: June 05, 2016, 03:00:52 pm »
"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 average even in that small 892 byte sample.
I wouldn't really know where to start with that.

N  Ascii Count   %
  1  58 :    36  4.04
  2  40 (    34  3.81
  3  57 9    26  2.91
  4  47 /    25  2.80
  5  45 -    25  2.80
  6  43 +   24  2.69
  7  48 0    22  2.47
  8  50 2    22  2.47
  9  36 $    21  2.35
 10  49 1   21  2.35
 11  61 =   21  2.35
 12  42 *   19  2.13
 13 120 x    18  2.02
 14  53 5    18  2.02
 15  51 3    16  1.79
 16  35 #    16  1.79
 17  88 X    16  1.79
 18  60 <    16  1.79
 19  55 7    15  1.68
 20 106 j    15  1.68
 
Edit: 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!
« Last Edit: June 05, 2016, 03:20:36 pm by StillTrying »
.  That took much longer than I thought it would.
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8526
Re: Anyone play with ciphers?
« Reply #3 on: June 05, 2016, 04:02:52 pm »
http://web.engr.oregonstate.edu/~moon/ece323/hspice98/files/chapter_28.pdf
Quote
The library encryption algorithm is based on that of a five-rotor Enigma machine. The encryption process allows the user to specify which portions of subcircuits are encrypted. The libraries are encrypted using a key value that Star-Hspice reconstructs for decryption.

The 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.
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: Anyone play with ciphers?
« Reply #4 on: June 05, 2016, 04:25:25 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28429
  • Country: nl
    • NCT Developments
Re: Anyone play with ciphers?
« Reply #5 on: June 05, 2016, 04:32:33 pm »
Reverse engineering the cipher using the debugger can also be one option.
This 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline T3sl4co1lTopic starter

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Anyone play with ciphers?
« Reply #6 on: June 05, 2016, 09:28:55 pm »
If it is Enigma, it must be resetting frequently, because further down in the file, there's a passage like so:

Code: [Select]
!KVO*I2v</D<%dH)X#;Y
8xafmQPh[1+;0.Pp6
:2TOq+H2F0
o7cK-2B:0b5)*/H0
o7k((E*h)<8
_:=AHzXri36
:26/c((EV+(j8
_:]7*5!jq
$96Uyb]Iw:BvL
T#2 ) il
!KVO*I2v$/D<%dH)X#;Y
8xafmQPh/vVS0.Pp6
:2TOq+H2F0
o7cK-:BE*E;)*/H0
o7k((E*Y*x8
_:=AHzXUP)6
:26/c((EJj5h8
_:]7*5!jq
$96UyjJ+>(BEL
T#2 ) il
!KVO*I2vi/D<%dH)X#;Y
8xafmQPh[ +S0.Pp6
:2TOq+H2F0
o7cK-$BhPjR)*/H0
o7k((EJEs=8
_:=AHz=;4(6
:26/c((EVS9$8
_:]7*5!jq
$96UyhV,)(BvL
T#2 ) il

This 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: [Select]
Bin	Frequency
58 321
50 296
40 294
42 222
36 218
48 203
54 201
47 188
41 187
57 174
43 170
55 163
35 160
45 150
56 144
72 141
84 135
120 135
51 131
60 131
106 131
69 119
80 117
104 114
33 113
61 111
95 111
91 109
53 108
88 106
59 100
113 100
37 99
66 92
74 91
121 91
86 90
111 89
89 86
99 84
79 78
98 77
108 74
118 74
75 73
85 70
46 69
49 69
97 69
112 66
62 64
105 62
122 62
76 58
101 58
109 58
73 57
39 53
70 52
81 52
65 51
83 51
87 51
90 50
93 50
68 45
100 45
102 45
117 43
119 42
115 41
44 40
107 40
116 39
52 36
92 32
82 29
77 24
71 20
114 17
67 11
103 10
78 2
110 2
34 0
38 0
63 0
64 0
94 0
96 0
123 0
124 0
125 0
126 0
127 0

Ed: 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
« Last Edit: June 05, 2016, 09:46:53 pm by T3sl4co1l »
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline StillTrying

  • Super Contributor
  • ***
  • Posts: 2850
  • Country: se
  • Country: Broken Britain
Re: Anyone play with ciphers?
« Reply #7 on: June 05, 2016, 10:24:44 pm »
except any code below 33 is conspicuously absent

Wouldn'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.
.  That took much longer than I thought it would.
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8526
Re: Anyone play with ciphers?
« Reply #8 on: June 06, 2016, 04:36:40 am »
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.
 

Offline T3sl4co1lTopic starter

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Anyone play with ciphers?
« Reply #9 on: August 25, 2020, 03:19:42 am »
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[1] * p^1 (for plaintext x and permutation p), col 2 is x[2] * 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 seems too periodic to be likely SPICE?  Unless HSPICE allows component instances of the same name?  Take these two groups for instance (lines 308-327):

Code: [Select]
!KVO*I2v$/D<%d:)X#;Y
8xafmQLh(/e*0.P)6
:2TOq+H2F0
o7cK-'B+5$u)*[10
o7k((E*Y*x8
_:=AHzX;,W6
:26/c((E*v9b8
_:]7*5!jq
$96UybV+m$B+L
T#2)il
!KVO*I2vi/D<%d:)X#;Y
8xafmQ,huj)90.P)6
:2TOq+H2F0
o7cK-'Bt(>R)*[10
o7k((EJEs=8
_:=AHzXvJ(6
:26/c((E*j*>8
_:]7*5!jq
$96UyjuIc2BjL
T#2)il

The per-char diff, 10 line spacing, is:

Code: [Select]
0	0	0	0	0	0	0	0	69	0	0	0	0	0	0	0	0	0	0	0
0 0 0 0 0 0 -32 0 77 59 -60 15 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 73 -13 26 -35 0 0 0 0 0
0 0 0 0 0 0 32 -20 73 -59 0
0 0 0 0 0 0 0 59 30 -47 0
0 0 0 0 0 0 0 0 0 -12 -15 -36 0
0 0 0 0 0 0 0 0 0
0 0 0 0 0 8 31 30 -10 14 0 63 0
0 0 0 0 0 0

If 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 three identical lines 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: [Select]
$$y<=-91-pXj+981:$u'(:!%-pXj+981:$,'(:/bJ5eU)*/2j/<2'kA25!j+(/2$pX#/tDA0

See it?  Column 9 on, wrapped by 16:

Code: [Select]
-pXj+981:$u'(:!%
-pXj+981:$,'(:/b

It'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. :-DD

Full ciphertext: https://www.seventransistorlabs.com/HSPICE_Decode_Source.txt

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
Re: Anyone play with ciphers?
« Reply #10 on: August 26, 2020, 11:01:40 am »
Have a look here: synopsys.com/content/dam/synopsys/verification/datasheets/hspice-ds.pdf:
Quote
Triple DES Encryption
HSPICE offers robust 192-bit encryption compliant with Triple Data Encryption
Standards (DES). This feature enables users to distribute their HSPICE custom netlists
and models without revealing sensitive information. Third-party recipients of encrypted...

Elsewhere i found the file looks like this:
.SUBCKT Encrypt 1 2 3
.prot
RR1 1 2 100 DTEMP=-8.149999999999977
RR2 2 3 100 DTEMP=-8.149999999999977
RR3 3 0 100 DTEMP=-8.149999999999977
.unprot
.ENDS

Regards, Dieter
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8526
Re: Anyone play with ciphers?
« Reply #11 on: August 27, 2020, 03:17:21 am »
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 ::)
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 9320
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: Anyone play with ciphers?
« Reply #12 on: August 27, 2020, 03:46:17 am »
I really don't understand how they can claim "without revealing sensitive information" when the user has both the ciphertext and the key.
Just like other DRM schemes. Which is to say that a determined hacker can break it pretty easily.
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline T3sl4co1lTopic starter

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Anyone play with ciphers?
« Reply #13 on: August 27, 2020, 03:47:50 am »
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? :-DD

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
Re: Anyone play with ciphers?
« Reply #14 on: August 27, 2020, 05:16:24 am »
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
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3688
  • Country: us
Re: Anyone play with ciphers?
« Reply #15 on: August 27, 2020, 05:33:59 am »
Inviting people to try and crack a DES cipher or any other serious cipher

The 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.
 

Offline T3sl4co1lTopic starter

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Anyone play with ciphers?
« Reply #16 on: August 27, 2020, 07:50:02 am »
:-DD 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... :-DD

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
Re: Anyone play with ciphers?
« Reply #17 on: August 27, 2020, 10:51:42 am »
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
 

Offline T3sl4co1lTopic starter

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Anyone play with ciphers?
« Reply #18 on: August 27, 2020, 11:08:37 am »
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
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2473
  • Country: br
    • CADT Homepage
Re: Anyone play with ciphers?
« Reply #19 on: August 27, 2020, 12:42:04 pm »
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
 

Offline GlennSprigg

  • Super Contributor
  • ***
  • Posts: 1259
  • Country: au
  • Medically retired Tech. Old School / re-learning !
Re: Anyone play with ciphers?
« Reply #20 on: August 27, 2020, 01:08:14 pm »
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!"    :-+
Diagonal of 1x1 square = Root-2. Ok.
Diagonal of 1x1x1 cube = Root-3 !!!  Beautiful !!
 

Offline T3sl4co1lTopic starter

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Anyone play with ciphers?
« Reply #21 on: July 01, 2021, 07:14:14 am »
[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
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Online peter-h

  • Super Contributor
  • ***
  • Posts: 4355
  • Country: gb
  • Doing electronics since the 1960s...
Re: Anyone play with ciphers?
« Reply #22 on: July 01, 2021, 03:01:36 pm »
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.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline T3sl4co1lTopic starter

  • Super Contributor
  • ***
  • Posts: 22436
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Anyone play with ciphers?
« Reply #23 on: July 01, 2021, 10:07:48 pm »
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
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Online peter-h

  • Super Contributor
  • ***
  • Posts: 4355
  • Country: gb
  • Doing electronics since the 1960s...
Re: Anyone play with ciphers?
« Reply #24 on: July 02, 2021, 07:08:38 am »
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.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf