There are still some open questions here:
1. how do you know if the decryption worked correctly ? You at least need to know the key, the plain text and the cipher text (you didn't state that you have all of this information)
2. you didn't mention the details about the encryption algorithm e.g. the block cipher mode (ECB, CBC, OFB, CFB, CTR, XTS, OCB)
One straight forward way to find the correct key could be to just use the openssl command/executable or any scripting language (python/perl) to perform the decrypt+validate operations (hint: you could for instance divide the total keyspace 2^32 by the number of your cores - e.g. 8 or 12 or 16 etc - and let each "thread" compute just a subpart of the whole problem, like an external divide-and-conquer style)... or course this approach might not be the fastest one, but for this relatively small keyspace, it shouldn't take more than a few hours/days
of course you should first test if the approach you choose works with a known key+plaintext+ciphertext pair
BTW: your examples are really missleading (or at least not very clear), you say that the key is made of "eight repetitions of a 4 byte" but I think it is actually just 2 bytes repeated 16 times (at least that is what all of your examples look like, they all have 16 times the same byte values, i.e. if we assume that 0x7C is 1 byte and 0x68 another one).
Furthermore, you might also consider generating the keys on-the-fly without needing to read the disk all the time, this should be pretty fast and it might speed up the overall computation by removing the disk bottleneck
1. how do you know if the decryption worked correctly ? You at least need to know the key, the plain text and the cipher text (you didn't state that you have all of this information)
2. you didn't mention the details about the encryption algorithm e.g. the block cipher mode (ECB, CBC, OFB, CFB, CTR, XTS, OCB)
One straight forward way to find the correct key could be to just use the openssl command/executable or any scripting language (python/perl) to perform the decrypt+validate operations (hint: you could for instance divide the total keyspace 2^32 by the number of your cores - e.g. 8 or 12 or 16 etc - and let each "thread" compute just a subpart of the whole problem, like an external divide-and-conquer style)... or course this approach might not be the fastest one, but for this relatively small keyspace, it shouldn't take more than a few hours/days
of course you should first test if the approach you choose works with a known key+plaintext+ciphertext pair
BTW: your examples are really missleading (or at least not very clear), you say that the key is made of "eight repetitions of a 4 byte" but I think it is actually just 2 bytes repeated 16 times (at least that is what all of your examples look like, they all have 16 times the same byte values, i.e. if we assume that 0x7C is 1 byte and 0x68 another one).
Furthermore, you might also consider generating the keys on-the-fly without needing to read the disk all the time, this should be pretty fast and it might speed up the overall computation by removing the disk bottleneck