Пожалуйста, не используйте # @ $ @ номер без присваивания. Просто назовите его BIP-oleganza резервным копированием на данный момент, пока текст не будет готов. В противном случае мы получаем беспорядок числа столкновений и людей, называющих вещи сталкиваясь номера они выбрали и не желая, чтобы изменить их. (Это не придирки, это случилось несколько раз)

Otherwise- это звучит полезно! Если это возможно, указать еще на службе хранения? например сколько данных вы можете ожидать, чтобы сохранить, как бы такая услуга будет компенсировано? как вы знаете, какие услуги (ы) вы используете?

Последнее, в частности, кажется, сложный вопрос ... но в целом мы, вероятно, следует попытаться указать "минимальная единица совместимой", И я не уверен, что если в одиночку сообщение страшно интересно.

WRT спецификация. IV действительно должен быть не determinstic, это уже хранится в зашифрованном сообщении. При постоянном IV наблюдатель может сказать с AES блока точностью, где первая модификацией обновленной копии была (и, возможно, некоторые более сложными атаками, например, было бы тривиальным небезопасно, если шифр режим был выбран CTR-). Там нет необходимости для IV детерминированный, что я знаю ... Если вы беспокоитесь о встроенном качестве устройства ГСЧА, вы могли бы рекомендовать IV быть построен как H (время || другими-случайным || Публичного ).

Вы, кажется, не имеют длины, закодированную для открытого текста. AES-CBC способен только кодировать целое число блоков, так что-то должно кодировать открытую текст длину. Я мог бы предложить его использовать самостоятельно описательные отступы, например, всегда есть по крайней мере один байты заполнения, и последний байт говорит, сколько байт заполнения есть (до 16 лет, хотя, возможно, некоторые приложения могут захотеть больше дополнения, чтобы закрыть размер sidechannel?). Другой стиль самостоятельной описательной обивки я видел используемый для прокладки с 0 битами, а затем всех теми до конца, и приемник удаляет все хвостовые 1s и последние 0 (имеет преимущество меньше расшифровки является недействительной).

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

Есть ли причина, чтобы сохранить AuthFingerprint? Она может быть получена из самого сообщения и подписи (например, как работает подписанное сообщение Bitcoin в), опуская это позволит сэкономить ~ 19 байт.

Есть ли конкретная мотивация для использования цифровой подписи вместо того, чтобы использовать MAC? Одна из причин, я мог видеть, что вы можете иметь несколько серверов синхронизации своих данных без индивидуально разговаривать с пользователем, как PGP SKS keyserver-, но для этого случая вы хотите добавить порядковый номер (так что вы знаете, если обновление вы получаете это сообщение новее или нет).

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

[Hm. Ого, сервер синхронизации будет супер круто для этого, если у нас был хороший способ избежать злоупотреблений.]