История изменений

Сказать сколько i3 в секунду успевает раз поменять местями два байта в оперативке?

Случайных? Именно в RAM? Гораздо меньше, чем ты думаешь: RAM — тормоз.

Окей, там будет не 64кб случайного, но сколько?

Ровно столько, сколько энтропии содержится во времени твоего нажатия на кнопку.

Время нажатия на кнопку ПРЕДСКАЗУЕМО. Допустим, мы берём промежуток в 2 минуты (реалистично?) с точностью до наносекунды. Получаем 1,2*10¹¹ разных значений, что соответствует 37 битам энтропии. Это — длина твоего ключа если ты шифруешь белый шум. Но у тебя ещё более серьёзная проблема: разница между разными значениями — одна (!!!) перестановка. Если известно хоть что-то о том, что было в исходном файле, то время атаки (и без того смешное) сокращается ещё в несколько раз. Если ты всерьёз считаешь, что твой «ключ» будет достаточно случайным после этого — ты серьёзно ошибаешься.

Все перестановки предсказуемы т.к. псевдослучайны и некриптостойки по определению. Всем пофиг, сколько перестановок делает твоё железо (хотя это — ещё один, но небольшой, вклад в энтропию).

Про частотный анализ тебе уже всё сказали, но он будет тебя волновать только если считать твой «ключ» достаточно случайным. А в твоём случае в нём 37 бит вместо 64 килобайт информации.

Увеличение временного промежутка в 2 раза добавляет 1 бит энтропии. Можешь посчитать, сколько тебе до хотя бы 60 бит.

Кстати, почему именно с точностью до наносекунды: вообще, это — переоценка. Клавиатура (либо мышь) физически не опрашивается настолько часто, поэтому энтропии от неё — ещё меньше.

Помедитируй над тем, почему иногда для генерации действительно случайных ключей просят *много* событий ввода от клавиатуры/мыши, а не одно.

Сказать сколько i3 в секунду успевает раз поменять местями два байта в оперативке?

Случайных? Именно в RAM? Гораздо меньше, чем ты думаешь: RAM — тормоз.

Окей, там будет не 64кб случайного, но сколько?

Ровно столько, сколько энтропии содержится во времени твоего нажатия на кнопку.

Время нажатия на кнопку ПРЕДСКАЗУЕМО. Допустим, мы берём промежуток в 2 минуты (реалистично?) с точностью до наносекунды. Получаем 1,2*10¹¹ разных значений, что соответствует 37 битам энтропии. Это — длина твоего ключа если ты шифруешь белый шум. Но у тебя ещё более серьёзная проблема: разница между разными значениями — одна (!!!) перестановка. Если известно хоть что-то о том, что было в исходном файле, то время атаки (и без того смешное) сокращается ещё в несколько раз. Если ты всерьёз считаешь, что твой «ключ» будет достаточно случайным после этого — ты серьёзно ошибаешься.

Все перестановки предсказуемы т.к. псевдослучайны и некриптостойки по определению. Всем пофиг, сколько перестановок делает твоё железо (хотя это — ещё один, но небольшой, вклад в энтропию).

Про частотный анализ тебе уже всё сказали, но он будет тебя волновать только если считать твой «ключ» достаточно случайным. А в твоём случае в нём 37 бит вместо 64 килобайт информации.

Увеличение временного промежутка в 2 раза добавляет 1 бит энтропии. Можешь посчитать, сколько тебе до хотя бы 60 бит.

Кстати, почему именно с точностью до наносекунды: вообще, это — переоценка. Клавиатура физически не опрашивается настолько часто, поэтому энтропии от неё — ещё меньше.

Помедитируй над тем, почему иногда для генерации действительно случайных ключей просят *много* событий ввода от клавиатуры/мыши, а не одно.