CSA Brute Force

D

dale_para_bajo

Registered
Messages
646
I spent whole night studying possibilities.

SAT is a program with a promest of finding solutions. But process still to complicated for my mind.

So I did spent quite some time studying possibility of Meet at The middle for CSA. CSA rounds are 23. So the middle is not exactly half as 12.5 is in the middle of a round. So I did a modify version. Encrypt to 12 decrypt to 13. And there we can get to a middle expression common to both. So the possibility is there. But how useful it is on a Full Round description we still doing 12+13 = 23 rounds!!

Now many paper mention this reduction on rounds. But I can not really see how to process the whole Idea to arrive to a final incomplete key.

Well I can see how doing 4 rounds can utilize 32 of the 64 bits. ANd I could accept we could build a table of 48GB just with 4 round Block Cypher. But then I get stock trying to match (Meat at the middle) a Real Crypt8 that was found with Whole CSA ( including stream) to out 48GB incomplete CSA ( ONLY Blocks)Table. UFF there is something I do not understand as 32 bits are not enough to generate the stream cypher needed to decrypt. I give up for today on this.
 
D

dale_para_bajo

Registered
Messages
646
This is old stuff. Going from paper to paper. Maybe the one that originate the comment knew what is and how to apply. You can read constant mention on this but never exposed what it really means.

So what I had done is sit think and figure out what they had try to say. I have no Idea if I am in the right direction.

Most of this thesis start from the point that the Key is 64bit long. Yes we ALL know now about the effective 48bit.

*So I guess 64/2 = 32 bits. This is Half the Key length.
*You can get 32 bit used at the 4th round ONLY in the Block Cypher. Yes a few are flip due to 0x0101010101010101 but they do its job transforming the data anyway.
*In any table creation you need 12 bytes = 6bytes start 6byte end (result). So 12*(2^32)/1024/1024/1024 =48GB

Well the previous is the easy part. Now how did the original exposer pretended to use the Original pair Clear/Crypt made with FULL CSA rounds and compare encryptions with 32 bit only and no Stream Cypher? HEHEHEHE This is what I have not figure out.

By the way this is my whole interpretation of this comments on reduce rounds and bits. But I can be wayyyyy OFFFFFF of what they intended to say. But as all mathematicians never clearly say.

PD: What is Round. Well in CSA we do in fact have many places we have Rounds(Loops)!.
But this mention on Key bits of Block Cypher. So Round is 1 of 56 where a KS key is used. Each KS has in fact 8 bit of the original key K. So you need only 4 KS to have 32 bits of the original K. Sorry if I forgot to mention. Now what to do with MAIN CSA 23 Rounds. I guess 1 is not enough as only 4 BC Rounds will leave to many Bits without XOR so they stay the same. Again a guess is that we do the 23 Rounds of CSA.
 
Last edited:
D

dale_para_bajo

Registered
Messages
646
What I understood is that they try to use a small table 48GB to try to guess 32 bit ahead. Then to calculate the last ones. To do this guess there is no other way if they do not use the Clear/Crypt pair?

Or I am still confuse?

In any case do not put to much attention on this as is only my interpretation on reduce bits/reduce rounds comments on papers.

Listen I wasted time on this because I have no good Idea at the moment to implement. But If I can guess 1 bit on the Key that means half the time to brute force. So 40 days becomes 20 days or 2 days becomes 1. A 32 bit guess, will be a gold treasure.
 
P

Peerate

Registered
Messages
117
K2TSET said:
Yes... just 1 bit would be a great win :)
Click to expand...

Can we find biss key through checksum values?
I mean, if someone can develop app who would "roll" checksum values who would lead us to valid key?

Example:
checksum 13 would give 38 29 B2

I know checksum values are not important to our emus (I can put 00 as any checksum and it will show picture) but this way, with BFing 2 checksum bits, we would significantly speed up process of finding keys...
 
K

kebien

Registered
Messages
1,329
Peerate said:
Can we find biss key through checksum values?
I mean, if someone can develop app who would "roll" checksum values who would lead us to valid key?

Example:
checksum 13 would give 38 29 B2

I know checksum values are not important to our emus (I can put 00 as any checksum and it will show picture) but this way, with BFing 2 checksum bits, we would significantly speed up process of finding keys...
Click to expand...
Interesting
But cheksum value is 13 when the sum is 113 and 213,and 413 ....to F13
Would it shield the same key value?
Apparently the checksum would shield validity to any key as long as it is correct,no?
 
D

dale_para_bajo

Registered
Messages
646
kebien is correct even when the maximum will be 3 x 0xFF or 2FD.

Listen any Ideas are welcome even when the may seem simple. Maybe they are so simple that all of us has ignore the importance.

But just as the EMU ignore those. We in our software implement procedure to ignore those, and yes we already speed from it.

See Pattents and Thesis (The so call papers ) and experts have something in common. They play the game that they are "Connoisseur". You language teacher use this stupidity to fake he knows a lot. So in his class he mention a line from Sheaskper. Or a speaker mention a line that Mandela said. Well in Papers as Pattents you can not write ONLY about YOUR own Idea. If you do so your paper is consider a piece of crap. You need to mention Other Paper preceding your work. As if their work validate yours. HEHEHEHE.

So we all see all this comments on paper about previous work. And some time they are there just to fake. But it look a very important comment that, sadly NO ONE can understands. HEHEHEHE Yes just like your Physics Class. So as the comment seems important many repeat the same expression making it every time more valid. So that was what I was behind. I still think it has some meaning but.........
 
D

dale_para_bajo

Registered
Messages
646
I know I should read more before posting the question. But since there is not much been done in this area of the forum I will show my concern.

Upss, I know the Biss AU people have a festival with; Is the server up or down thing. And the Gshare guys kept asking for the never ending more updates.

Here is the lines.
Code: 
47 01 10 D2 73 AF 05 5E 0E AA 9B CB 93 54 A6 94 20 5D 28 ED F0 67 AD 35 D3 B0 60 02 F2 C8 09 3C 7F C7 EF D1 7C B8 30 E9 CB 00 ED 02 24 0C 5A 
82 D6 20 83 0F 08 BF FF F2 12 F2 5E BF E9 50 F5 A2 3E 3B 17 67 12 2D CB B4 BB 0D 51 3E 79 F3 25 46 C0 C4 8D 86 B1 A8 E3 93 3C 47 F5 A0 4E EF 
80 70 63 A3 56 E8 D7 E2 00 97 7A 70 50 F0 BE 88 EB 49 16 BA 39 9C C4 2E 2F 99 5B EA 07 AD 05 B9 E0 22 ED C6 13 4B 5B 9A 04 AA 15 B1 6F 14 9F 
7B 3B 46 C8 4F 94 7F A2 2D BA 43 36 BD 5C 2C FA B0 19 A6 9B F2 F3 32 03 FB 1E 29 9A 2E 5A DA 09 C3 1C 68 93 C3 63 F7 BA 26 39 47 0E 2F 5A 98 
47 01 10 F3 77 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 05 F0 8A 54 E8 25 89 B8 D0 B0 FD E5 71 00 5B E6 70 
05 B0 50 2A 2A 41 2B A7 2F 14 87 3E D1 D8 A9 41 5A 86 EC 5A 3A A8 E8 1F 48 04 AA 14 B0 39 C2 B6 9E EC 4D 90 80 45 D5 95 E8 34 25 68 94 7F 5E 
47 01 10 23 B7 10 58 C1 AF 29 7E E5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
47 41 10 D4 3D A6 B4 12 50 11 B5 D7 43 EF 31 66 18 E3 0D 8B D5 EA 5A 7F 81 A5 17 E2 A3 CB CF AF 34 03 33 B6 F0 28 12 08 0B 9B 70 2D B8 E3 D6
So encrypted data was showing normally until the Adaption Field show up so Unencrypted FF filed every thing until "05 F0 ..." encrypted again.

Code: 
47 01 10 F3 77 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 05 F0 8A 54 E8 25 89 B8 D0 B0 FD E5 71 00 5B E6 70 
05 B0 50 2A 2A 41 2B A7 2F 14 87 3E D1 D8 A9 41 5A 86 EC 5A 3A A8 E8 1F 48 04 AA 14 B0 39 C2 B6 9E EC 4D 90 80 45 D5 95 E8 34 25 68 94 7F 5E

This I have clear. Now next ts line.

Code: 
47 01 10 23 B7 10 58 C1 AF 29 7E E5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

So I need to check but I have a feeling that this is what you guys discused earlier of NOT?

Question is are the next 8 byte encrypted normally by Block and Stream cyphers? So is just an 8 byte CSA encript.

Or was encrypted by last encryption process and data display on next line?
Or it is just encrypted by the Stream Cypher?


Thanks ahead,
 
K

K2TSET

Registered
Messages
125
dale_para_bajo said:
Question is are the next 8 byte encrypted normally by Block and Stream cyphers? So is just an 8 byte CSA encript.

Or was encrypted by last encryption process and data display on next line?
Or it is just encrypted by the Stream Cypher?
Click to expand...

Not sure where you have the ts snips from?
You could upload it so we talk about the same data and if you also know the key we can compare to the clear data as well.

The thing I did try to investigate was if the video payload after the unencrypted adaption field could be BF faster due to the fact that when you have a non 8 bytes length Resuide it will only be encrypted by SC.

I did look in to many TS and did find this is correct but you will need to find TS block of 184 where the AF are long so you only need to do the SC on so few rounds as possible.

So there are absolutely a lot of AF lines where this is possible to do, BUT the problem are we do NOT know what the unencrypted part should look like so how to know if we have a match?
 
D

dale_para_bajo

Registered
Messages
646
Not encrypted uhm!

I just came to have a quick pick. And I do thank you. I know I need to read more on Mpeg TS Basics structure. And Colibris old german paper. I am having little time to work on this. But as soon as I can I will be back.

This is last year log I have on 103W of missing key tanberg channels. New logs seems it has improve obfuscation but the main Idea is there. I do not have a key for this. Now I do not quite understand your comment as you can get yourself a key by FPGA BF24. I will come back later as I am busy now.
 
J

jab90

Registered
Messages
9
Can somebody tell me how I can find out what chains are inside a table? Is it even possible? Do I have to write my own utility? thanks
 
D

dale_para_bajo

Registered
Messages
646
@jab90
You are hijacking the tread. Becarfull
In any case I did try to help you but did not fond the thread. There is a tread of a program a good friend of us made and posted here. I do not recall the details but is like CSA RBT Editor or something like this. Just keep searching or maybe some one know and give you a hand.

@C0der and @K2TSET and all others

Here is the log I been playing with.
Code: 
http://s000.tinyupload.com/index.php?file_id=43189986987197792146
 
K

K2TSET

Registered
Messages
125
Hi.. very quite in here.

I did some reading in some old pdf's and saw a statement in this one "Dedicated Digital Hardware for DVB-CSA Encryption"
http://www.ijet.pl/old_archives/2012/3/33.pdf

I know it's for encoder but guest it will apply for decoder as well

The interesting part on page 243 -244

Block cipher requires 56 cycles to process 64 bit data.
Stream cipher delivers 2 bits per clock cycle, which makes
32 cycles for 64 bits. These blocks may operate concurrently
in pipeline providing a throughput of 1 data block (64-bit) per 58 clock cycles (block cipher slice plus 2 cycles for
registers reload). A higher performance could be achieved by
implementation of 2 block cipher units working in parallel and
this way reducing the slice to 32-34 cycles.

So my question are what does 2 block cipher units working in parallel in 32 cycles mean?

Will the one block cipher only run the 1-23 rounds and the other 24-56 in parallel?

I would expect this to be impossible since round 24 would need the input from round 23... or it there a trick to xor the the 2 ones together after 23 rounds?
 
C

campag5242

Hi K2TSET. As you stated in your last sentence, the CBC XOR is done with crypted data from the previous block, together with plain data from the current. Only then is the BC run over the current 64-bit block. So no way to do that in parallel: it must be done block by block, serially.

I suppose you could use a 2nd block cipher unit to crypt a second ts packet in parallel, giving 32-34 cycles as an average figure for the two.
 
K

K2TSET

Registered
Messages
125
campag5242 said:
So no way to do that in parallel: it must be done block by block, serially.

I suppose you could use a 2nd block cipher unit to crypt a second ts packet in parallel, giving 32-34 cycles as an average figure for the two.
Click to expand...

Hi campag5242, yeah makes absolutely sense

There might be some trick in front of you which no one never tested so it's worth to give all steps a thought.

Like in the keyschedule you have this xor 0x06, 0x05 etc. for the 7 block of 8 rounds of BC. I did a small test where I made 7 different s-boxers reflecting this xor and sure it worked fine. Not a big gain but it eliminate 1 step :)

Btw. nice to see other have done FPGA test
https://www.auto.tuwien.ac.at/bib/pdf_TR/TR0188.pdf
 
C

campag5242

Nice read, thanks. Will re-read more closely.

For my own (software) BF experiments, I haven't delved into the nuts and bolts of the algorithm at all thus far. I considered only the first 11 bytes of select payloads, first doing the BC, then applying the SC/XOR 1 byte at a time, stopping immediately if it didn't show that PUSI sequence. Guess there's nothing novel there though. Key schedule is something I should look at -
cheers for the tip.
 
C

campag5242

Feed Hunter
Messages
2,585
For blind BF ie using monotonically incrementing keys (as opposed to checking a list of random known old keys or date-encoded lists), there are some optimisations to libdvbcsa's key schedule.

eg when incrementing only CW[6], you can isolate those elements which change each time CW[6] changes (and consequentially CW[7]), and you can separate those parts which change when building the expanded key, from those that do not.

That way you, can pre-calculate the parts which don't change for 256 rounds, and save repetition.

That should work well for kernels which run on a CPU. But as I've gotten used to, any hopes to outsmart the CUDA compiler fell flat with this. For CUDA/GPU, it seems to like to see simple, elegant source code, and then it will do its best to produce fast executables.
 
You must log in or register to reply here.
Top