Which GPU to buy to search BISS keys in TABLE V1

dahaka

Registered
Messages
700
V1 tables search code in CSA Rainbow Table Tool far from perfect. You can drastically improve speed by rewriting software.


As we know Colibri stop coding it few years ago unfortunately , otherwise you have some new ideas to apply ;) .
 

kebien

Registered
Messages
1,329
BLACKCRUSADER
V1 tables search code in CSA Rainbow Table Tool far from perfect. You can drastically improve speed by rewriting software.

And the thread is not really about that,do we agree?
I mean,you could have been a great help 4 years ago,he he.....

Some people missed the boat,but hey knew they could have swam faster than the boat........a boat that already made the trip 100 times
 

BLACKCRUSADER

Senior Member
Messages
2,000
And the thread is not really about that,do we agree?
I mean,you could have been a great help 4 years ago,he he.....

Some people missed the boat,but hey knew they could have swam faster than the boat........a boat that already made the trip 100 times

I thought this thread was about what is the best GPU to use.

Mine seems to work well :)
 

sss146

Registered
Messages
47
kebien
I don't get it. I thought that V1 tables still very useful.
And there's source code available for CSA Rainbow Table Tool (old version, but major stuff is there).
 

kebien

Registered
Messages
1,329
kebien
I don't get it. I thought that V1 tables still very useful.
And there's source code available for CSA Rainbow Table Tool (old version, but major stuff is there).
I agree,what i see it as the best card gets keys in a minute and a half,how lower can we get? 60 seconds?
is it really a big improvement??

As we see,the video card is what makes the difference,the amount of cuda cores.

BLOCKBUSTER
Is not what the best card is,the title says which GPU he should buyWe all are giving our input,is up to his budget to buy what he wants and is allowed to spend.
Not everyone can spend $2000 to search biss keys the fastest way (card,ssd,power supply,and else).
I do agree you have a killer setup.
 

kebien

Registered
Messages
1,329
kebien
More like down to 6..40 seconds (depends on "luck").

As I said,somehow the whole idea of NOT finding CW keys real time maybe was the motivation to NOT really improve efficiency to the point the providers change the whole scene and abandon CSA altogether.

I believe you,everything is possible,as is also possible this whole thing we experience now is gone because we become "too smart".
 

campag5242

Feed Hunter
Messages
2,585
kebien
More like down to 6..40 seconds (depends on "luck").
Thanks for posting your timings: it was my inspiration to seek & find better algorithms... all the same I needed a hardware upgrade to 1070ti to get somewhere close.
Blackcrusader's search of v1's public tables B8hxFFh (1 & 2 merged) from earlier in this thread is repeated here:

Code:
Using table D:\CSA_B8hxFFh_10000h.rbt, 28.454 billion chains. End6 range 000000005DD0h-FFFFFFFFAADFh.
Searching rainbow table for C8: F6 A2 3E 1D 91 36 32 BA, range 2000h links per round.

2.8s: 2000h end6 values calculated, commencing disk search E000h-FFFFh

6.3s: 3590 chains found. Rebuild using 8 grids @ 15 x 256 threads needed for max link FE96h:
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link F04Ch
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link F04Ch
9.9s: 10304 chains found. Rebuild using 7 grids @ 41 x 256 threads needed for max link DFF7h:
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link C396h
15.5s: 17578 chains found. Rebuild using 6 grids @ 69 x 256 threads needed for max link BFFDh:
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link BD3Bh
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link BD3Bh
20.0s: 23806 chains found. Rebuild using 5 grids @ 93 x 256 threads needed for max link 9FFFh:
25.6s: 30272 chains found. Rebuild using 4 grids @ 119 x 256 threads needed for max link 7FFBh:
31.1s: 36734 chains found. Rebuild using 3 grids @ 144 x 256 threads needed for max link 5FFEh:
35.0s: 44100 chains found. Rebuild using 2 grids @ 173 x 256 threads needed for max link 3FFEh:
38.7s: 50688 chains found. Rebuild using 1 grids @ 198 x 256 threads needed for max link 1FFEh:
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link 047Dh

Found CW: FD 41 5A 98 B7 8A FF 40

All end6s calculated in 11.5s, 217072 start6s fetched in 29.2s, all chains rebuilt in 28.8s. Total 39.7s
Blackcrusader has a stunningly fast SSD: using the Colibri tools here gives 4x slower performance cf what reported.
With blackcrusader's SSD & your GPU, a v1 search might be done in 20secs (compute bound).
And yes, I am missing a handful of found chains v Colibri/Blackcrusader's count, to be investigated.
 

kebien

Registered
Messages
1,329
Thanks for posting your timings: it was my inspiration to seek & find better algorithms... all the same I needed a hardware upgrade to 1070ti to get somewhere close.
Blackcrusader's search of v1's public tables B8hxFFh (1 & 2 merged) from earlier in this thread is repeated here:

Code:
Using table D:\CSA_B8hxFFh_10000h.rbt, 28.454 billion chains. End6 range 000000005DD0h-FFFFFFFFAADFh.
Searching rainbow table for C8: F6 A2 3E 1D 91 36 32 BA, range 2000h links per round.

2.8s: 2000h end6 values calculated, commencing disk search E000h-FFFFh

6.3s: 3590 chains found. Rebuild using 8 grids @ 15 x 256 threads needed for max link FE96h:
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link F04Ch
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link F04Ch
9.9s: 10304 chains found. Rebuild using 7 grids @ 41 x 256 threads needed for max link DFF7h:
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link C396h
15.5s: 17578 chains found. Rebuild using 6 grids @ 69 x 256 threads needed for max link BFFDh:
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link BD3Bh
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link BD3Bh
20.0s: 23806 chains found. Rebuild using 5 grids @ 93 x 256 threads needed for max link 9FFFh:
25.6s: 30272 chains found. Rebuild using 4 grids @ 119 x 256 threads needed for max link 7FFBh:
31.1s: 36734 chains found. Rebuild using 3 grids @ 144 x 256 threads needed for max link 5FFEh:
35.0s: 44100 chains found. Rebuild using 2 grids @ 173 x 256 threads needed for max link 3FFEh:
38.7s: 50688 chains found. Rebuild using 1 grids @ 198 x 256 threads needed for max link 1FFEh:
RBTv1 kernel B8hxFFh hit using CW: FD 41 5A 98 B7 8A FF 40 @ link 047Dh

Found CW: FD 41 5A 98 B7 8A FF 40

All end6s calculated in 11.5s, 217072 start6s fetched in 29.2s, all chains rebuilt in 28.8s. Total 39.7s
Blackcrusader has a stunningly fast SSD: using the Colibri tools here gives 4x slower performance cf what reported.
With blackcrusader's SSD & your GPU, a v1 search might be done in 20secs (compute bound).
And yes, I am missing a handful of found chains v Colibri/Blackcrusader's count, to be investigated.

Killer.
Is the 40 seconds consistent? or it can get some keys faster that that?
The way it works is they send new CW and is sent and used right away by the CA device.
So,any search done even at 5 seconds,wouldn't be 5 seconds late in a live stream?

At your speed,buffering the stream for 50 or 60 seconds would work already.
Problem would be the CWs that it can't find.

I imagine people able to buffer enough at home and a server delivering CW,ird would sync CWs with buffer.
Oscam is already doing it with stream relay anyway.
Just a wondering mind.
 
Last edited:

campag5242

Feed Hunter
Messages
2,585
40 secs is consistent on that sized table to perform an exhaustive search of every candidate chain. That is tables 1&2 merged into one big table as Blackcrusader has. Of course I could've chosen to stop on the first hit, in this case around 8 seconds.

Fully searching table1 or table2 separately without merging takes around 30 seconds each with my hardware, again with the first hit no sooner than 6 seconds, depending on luck.
 

dmr0x

Registered
Messages
290
Samsung 970 EVO Plus PCIe NVMe M.2 should yeild a decent performance boost over an old school sata 3 ssd. Those sammy evo's are a decent price to.

a fast gpu was important for the creating of chains.
for searching cw's a faster ssd paired with a low end gpu will be faster than a slow ssd with high end gpu imo.
 

FaDeL®

Staff member
Super Moderator
Messages
7,389
Samsung 970 EVO Plus PCIe NVMe M.2 should yeild a decent performance boost over an old school sata 3 ssd. Those sammy evo's are a decent price to.

a fast gpu was important for the creating of chains.
for searching cw's a faster ssd paired with a low end gpu will be faster than a slow ssd with high end gpu imo.

Indeed
I have this M2 A good experience for me
Very fast in Boot Windows and Search V1 in 63 to 67 Sec Only
And now the 4 gen has been released
Search rate under 30 Sec And it all depends on the ٌRBT size
 

campag5242

Feed Hunter
Messages
2,585
Old school sata 3 SSD here, and worked v hard on the disk search algorithm to get > x10 faster ssd search times than the Colibri tool on the same hardware. The bottleneck here is GPU on B8h.

Good to know there is much better performing SSD, but for me it would make no difference on B8h. Different story for 08h... that would be super fast.
 

BLACKCRUSADER

Senior Member
Messages
2,000
40 secs is consistent on that sized table to perform an exhaustive search of every candidate chain. That is tables 1&2 merged into one big table as Blackcrusader has. Of course I could've chosen to stop on the first hit, in this case around 8 seconds.

Fully searching table1 or table2 separately without merging takes around 30 seconds each with my hardware, again with the first hit no sooner than 6 seconds, depending on luck.

Yes I merged the V1 into one very large table.

My PC is not so new but the GPU and the Samsung SSD and large tables certainly help. It's all about the SSD and GPU not the main PC. Also my PC for scanning the stream and getting the CW is a stand alone PC with no other function.
 

campag5242

Feed Hunter
Messages
2,585
For a laugh, I ported my windows command line code to Nvidia Jetson Nano (like a Raspberry Pi 4, but with tegra chipset for tablets etc including 128 CUDA cores). Not much required changing, a few __int64 to off_t and _fseeki64() to fseeko() etc, job done.

Of course the GPU sucks compared to a desktop GPU. But the *SAME* apparently crappy crucial mx300 sata3 ssd, *SAME* crappy NTFS file system, hanging off the *SAME* crappy USB3.0 adapter, performs 10x faster on this little arm CPU box than my big fat i7 6700 Desktop. It's not much different if I use PCI-e to SATA3 card on the PC. Windows sucks, apparently. Either that or my ability to write code for it. That's a *big 400GB* table disk search in *under* 4 seconds on the Jetson Nano, with its little GPU taking 47secs to rebuild the 260,000 08h length chains (my 1070ti will do that in <2s). No need for faster M.2 ssd, just get rid of the bloatware.
 

C0der

Registered
Messages
267
Maybe the data was just cached from a previous search?
Can you check the ssd iops with some benchmark tool?
 

campag5242

Feed Hunter
Messages
2,585
Nope, it's on a fresh search: reliably around 3.5s to search 400GiB, finding > 200,000 chains correctly on the ARM box.
This i7 PC is ~10x slower than that on a fresh search. And on a cached search, only about 2x quicker than the ARM can manage on a fresh search - WTAF? I'll look to use benchmark tools on both platforms...
 
Top