Существует ли алгоритм шифрования подвижного блока?

Question

Я делаю веб-приложение для заметок , которое непрерывно сохраняет заметки при вводе. Я отправляю diff, чтобы предотвратить отправку слишком большого количества данных по проводам, что прекрасно работает, когда заметка представляет собой простой текст.

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

Основываясь на моем недавнем чтении, я мог (но не должен) использовать режим шифрования ECB-блочный шифр , который разбивает открытый текст на 16-байтовые блоки и шифрует их независимо. Это будет означать, что различие будет работать, если редактирование происходило в конце (или если редактирование добавляло или удаляло кратное 16 байт). Но любые изменения, которые происходят в середине заметки, влияют на зашифрованный текст для остальной части заметки.

Итак, когда я лежал в постели прошлой ночью, я начал задаваться вопросом, существует ли алгоритм шифрования «скользящий блок», который шифрует каждую часть заметки на основе символов вокруг нее, так что изменение / добавление / удаление любого одного символа только изменил бы 16 окружающих байтов. Надеюсь, это имеет смысл. По сути, я хочу алгоритм шифрования, чтобы небольшие изменения в открытом тексте вносили довольно небольшие изменения в зашифрованный текст.

Существует ли такой алгоритм? (Будет ли это другой режим работы блочного шифра, который можно использовать с AES, а не совершенно новый алгоритм? И как его безопасность будет сравниваться с более обычным режимом блочного шифра?)

Первоначально у меня был такой вопрос в виде JavaScript, потому что это то, чего я в конечном итоге хочу, но это, вероятно, немного.

Answer 1

Вы все еще можете использовать CBC - просто всякий раз, когда последовательность блоков в середине сообщения обновляется, вам нужно будет помнить старое значение зашифрованного текста последнего блока в этой последовательности. Например, приведен оригинальный текст:

                         | IV 0          |
| Plaintext 0  | <=====> | Ciphertext 0  |
| Plaintext 1  | <=====> | Ciphertext 1  |
| Plaintext 2  | <=====> | Ciphertext 2  |
| Plaintext 3  | <=====> | Ciphertext 3  |
| Plaintext 4  | <=====> | Ciphertext 4  |
| Plaintext 5  | <=====> | Ciphertext 5  |

Если клиент хочет обновить блоки 2 и 3, он использует Ciphertext 1 в качестве IV для CBC и отправляет новые блоки зашифрованного текста Ciphertext 2b и Ciphertext 3b. Сервер сохраняет Ciphertext 3 как IV 1, поэтому теперь он выглядит следующим образом:

                         | IV 0          |
| Plaintext 0  | <=====> | Ciphertext 0  |
| Plaintext 1  | <=====> | Ciphertext 1  |
| Plaintext 2  | <=====> | Ciphertext 2b |
| Plaintext 3  | <=====> | Ciphertext 3b |
                         | IV 1          | (= Ciphertext 3)
| Plaintext 4  | <=====> | Ciphertext 4  |
| Plaintext 5  | <=====> | Ciphertext 5  |

Очевидно, что это снижает эффективность хранения данных на стороне сервера по мере накопления правок.

---

Кроме того, вы можете использовать режим, который используется для зашифрованных файловых систем, например, режим XTS. Это включает разбиение вашего текста на обновляемые сектора, которые больше, чем блок зашифрованного текста.

Answer 2

Вы захотите использовать режим шифрования stream , например, CFB, OFB или CTR, вместо режима шифрования block , например, ECB или CBC. См. блочные шифры режимов работы . Вы можете использовать их с общими алгоритмами шифрования, такими как AES и Blowfish. Режимы потокового шифра, такие как CTR, часто используются для таких программ, как SSH, поскольку вы вводите один символ за раз.