In the new version anyone can create chains and add it to the RBT, but the key search will only use chains that are listed in a small (non text) file called ChainAuthor.map. But in version 2 we need so many chains that for a single person it's not practicable (I needed more than a year to get 77.4% success rate and the RBT has still space for more chains available). 3Ĥ Community In version 1 chain sharing was not needed. Also not adding half-good chains and only good chains from a chain file to the RBT increases the need of much more chains. Of course we need much more chain files to find the same amount of keys. But because the chain length in version 2 is 10h times shorter, the creation time for a chain file is also 10h times faster. Chain file The speed to create x keys per second is the same in both versions. the middle of the chain it contain new keys, but from the middle to the end-value the keys are already present in the RBT. If an end-value is already present in the RBT but the start-value is different, than it is a half-good chain, because only from the start-value to ca. In version 2 only good chains will be added to the RBT. In version 1 all chains get added to the RBT. At creation time they can't be identified. So with 12 bytes only 1000h keys can be found, but post calculation after a look-up is much faster. In version 2 a single chain contains 1000h values. So with the storage of 12 bytes (6 byte start value and a 6 byte end value of that chain) 10000h keys can be found, but post calculation after a look-up takes very long. Chain length In version 1 a single chain contains 10000h values. Chains are incompatible To get the very high key search speed it was necessary to use an other chain length (1000h instead of 10000h), so version 2 can't use chains that were created with version 1. Because 1.25 TB don't fit on a single SSD the tool offers an option to split the RBT to more smaller files that are located on different SSD drives at RBT creation time. A look-up for an end-valueprefix needs only one read access. The fixed size was necessary to speed up the look-up. In version 2 the RBT has a fixed size of 1.25 TB even when only a single chain was added. For 99% success rate it required only a few hundred MB which fits on a single SSD. A look-up for an end-value-prefix needs multiple read accesses (binary search). Each time a chain was added it was merged with the RBT and sorted and the complete resulting RBT was written to disk. When adding the first chain the size is very small. RBT In version 1 the RBT has a variable size. The most are required to get the high speed in key look-up. I don't know what success-rate a full RBT will have.Ģ Index Introduction.1 Changes between version 1 and RBT.3 Chains are incompatible.3 Chain length.3 Chain file.3 Community.4 RBT and GPU on same or different computers.4 Quick start guide.5 GPU connection.5 RBT creation.7 Add jobs.8 Add chain files to the RBT.9 Define search settings.10 Search keys.11 Create chains and share it.12 Crypt8 search.14 Getting performance data and success rate.15 Special functions.16 Remove name.16 Name.17 Referencesģ Changes between version 1 and 2 There are many changes in version 2. If the community creates more chains and share it to others the success rate can be increased to maybe 90%. The fixed RBT size of 1.25 TB is still not full. It requires 1.25 TB and the success rate is currently 77.4%. It is able to do a key search in ~4 seconds on SSD (on HDD it takes 29 seconds). The version 2 was rewritten from base and the top design goal was speed. On HDD a key search takes nearly one hour and on SSD only some minutes on a RBT size of MB. The version 1 of the tool was fast enough to break static BISS keys, but to slow for CAS systems. To speedup the things the tool will use the Graphics Processing Unit (GPU) on a video card from Nvidia to do the calculations necessary to create the RBT and also for the little post calculation during key look-ups. After the one time RBT creation was done it can be used for many key look-ups that are very fast. The CSA-Rainbow-Table-Tool is able to create a large database called Rainbow Table (RBT) based of these encrypted null packets which will take a long time. If the video bit-rate is lower than the required bit-rate mostly zeros are appended to the video packets before the stream gets encrypted. As base for video/audio encryption they also use CSA but the key changes every ~10 sec. The better systems use a Conditional Access System (CAS) like Conax, Cryptoworks, Nagravision, Seca, Viaccess, NDS Videoguard. The BISS encryption use a more or less static CSA key. CSA is used to encrypt the video and/or audio. 1 Introduction CSA-Rainbow-Table-Tool-V2 Documentation (Version 1.00) up-to-date version on Colibri Nearly all encrypted digital television programs transmitted via satellite are scrambled by the CSA algorithm.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |