проверил, не должно быть таких багов
@Saenro, посмотри
xor rax, r13
add rax, r11
mul r12
xor rax, r10
add rax, r11
shr rax, 0x3
add rax, r8
shr rax, 0x3
add rax, r9
@@:
add rax, 'eN?_'
ror rax, 16
xor rax, r10
add rax, r11
rol rax, 12
xor rax, r8
add rax, r9
ror rax, 8
xor rax, r14
add rax, r15
rol rax, 7
xor rax, r12
add rax, r13
add rax, 'si(2'
lea r15, qword[r15+1]
cmp ah, 0xFE
jna @b
Я параллельно ещё написал один алгоритм, там всё намного сложнее, но не успел написать для него дешифровщик
Вот Я проверял, должно быть всё нормально теперь. Взял ещё повороты из ChaCha8
Да всё то же самое ведь, всё также без компа можно подогнать исходные значения.
Как так... После константы там теперь не может быть одного значения при нуле Сейчас ещё перепроверю, скину результаты
Добрался до калькулятора и вот один из вариантов: r8=0 r9=0 r10=0 r11=0 r12=7D84 EF8F 4426 6FC0 r13=0 r14=0 r15=0 RAX=5584 EF8F 7907 FF26
Да я уже почитал про коллизии. Оказываются, они везде (SHA, MD, CRC). Помогает только сложный запутанный алгоритм)) И сам уже проанализировал - там где минус, можно подать значение того, что "минусуется", и выйдет 0, ну и т.д. Тем самым получить фиксированное значение, просто прочитав алгоритм
Избавится от коллизий возможно только при условии что длинна хеша длиннее сообшения
Это я к тому, что тебе нет смысла мастерить 2^512 непонятно чего, но достаточно хорошего 128 битного хеша.
Обсуждают сегодня