- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
void subBytes(uint8_t* block, size_t count) {
for (int i = 0; i < count; i++) {
size_t x, y;
char *temp = new char[2];
sprintf(temp, "%02x", block[i]);
temp = new char[4]{ temp[0], 0x00, temp[1], 0x00 };
x = stoi(temp, 0, 16);
y = stoi(temp + 2, 0, 16);
block[i] = sBox[x][y];
delete[] temp;
}
}
void invSubBytes(uint8_t* block, size_t count) {
for (int i = 0; i < count; i += 1) {
size_t x, y;
char *temp = new char[4];
sprintf(temp, "%02x", block[i]);
temp = new char[4]{ temp[0], 0x00, temp[1], 0x00 };
x = stoi(temp, 0, 16);
y = stoi(temp + 2, 0, 16);
block[i] = invSbox[x][y];
delete[] temp;
}
}
gost 31.03.2017 08:40 # +1
> uint8_t*
> stoi
Начали за здравие, кончили за упокой.
j123123 31.03.2017 09:04 # +4
Antervis 31.03.2017 10:27 # 0
j123123 31.03.2017 10:47 # +6
Это вообще надо талант иметь, чтобы столько говна натворить в столь коротком фрагменте
gost 31.03.2017 13:34 # +2
Ничего вы не понимаете, это там по стандарту FIPS 197 утечка!
roman-kashitsyn 31.03.2017 11:32 # +3
Уже смешно. Ок, прежде чем лезть в кишки реализации, давайте посмотрим интерфейс. О, тут явно линкуется libvanga, иначе как мы узнаем длину ключей и plaintext? Посмотрим пристальнее Действительно, ключи же не могут содержать нулевых байтов, это нонсенс. Да и шифровать бинарные файлы мы тоже никогда не захотим, тим uint8_t* нам толсто на это намекает.
1024-- 31.03.2017 11:38 # +3
Зачем над автором издеваетесь, это же для целочисленных файлов. Жаль только, что в C++ нет шаблонов, чтобы написать универсальный код для работы и с целыми, и с вещественными файлами. То ли дело C#, там даже объектные файлы можно шифровать.
roman-kashitsyn 31.03.2017 12:43 # 0
для строковых файлов
Antervis 31.03.2017 13:06 # +4
kipar 01.04.2017 10:45 # +3
roman-kashitsyn 01.04.2017 12:32 # +1
kipar 01.04.2017 16:52 # 0
j123123 01.04.2017 22:44 # 0
bormand 02.04.2017 13:18 # −14
Надо всё-таки в GF(255) переходить, чтобы ноль оставить специальным значением.
bormand 31.03.2017 19:09 # −16
bormand 31.03.2017 19:54 # −16
ASD_77 31.03.2017 13:22 # 0
Кэп я нихера не понял ? Это как?
j123123 31.03.2017 23:16 # +1
Он спринтф-ом получает из 8-битного uint числа строку, например если число было 63 то в 16-ричной системе это будет 3f. Потом он аллоцирует опять 4 байта, в первый элемент сует первый кусочек, во второй - второй кусочек. Ну т.е. если block[i] равен 0x3f то фактически получается:
После чего сие говно читается через stoi, иными словами он таким вот способом получает половинки байта
Сдвиги и битовые маски для лохов
1024-- 31.03.2017 23:32 # +2
j123123 01.04.2017 00:12 # +1
У new приоритет больший, чем у присваивания = и получается, что выполняемая внутри new питушня будет выполнена раньше, чем произойдет присваивание, и питушня в new будет отталкиваться от старого значения temp.
j123123 01.04.2017 00:19 # 0
В любом случае, лучше такого говна не писать. Тут надо учитывать порядок вычисления, а не приоритет операторов
1024-- 01.04.2017 00:26 # +2
1024-- 01.04.2017 00:42 # +2
guest 01.04.2017 03:05 # −14
Видишь, это код, который каждый писал в своей жизни хотя бы раз. Разница между этим кодом и i = ++i в том, что первый мутирует i только один раз в рамках точки следования, а второй два. Использовать старое значение i для вычисления нового значения абсолютно нормально, это не UB.
Antervis 01.04.2017 12:06 # 0
gost 31.03.2017 13:36 # +3
А, ну понятно, ещё один умник, не понимающий разницы между "паролем" и "ключом".
Antervis 31.03.2017 14:23 # +3
throw invalid_argument("password: letter 6 is incorrect");