Означает ли большее количество раундов хеширования при генерации ключа шифрования aes-128-ctr более надежное шифрование?

Рассмотрим следующую учетную запись Ethereum, которую я создал в MyEtherWallet :

{ version: 3,
  id: '4447b704-e28c-4e93-8b1d-32f519b46692',
  address: '115312fc0ab77a0fb15a66baf51f58baefcee1dd',
  Crypto: 
   { ciphertext: '299dd3b289bbfa049b42b9e8caff2a37ea9cc0606b33dad64afbb9b8aa5b2bc7',
     cipherparams: { iv: 'ab6abe38032296123b16b029cfce8240' },
     cipher: 'aes-128-ctr',
     kdf: 'scrypt',
     kdfparams: 
      { dklen: 32,
        salt: '2605c6988ea0c68dd8c363e29f815bbabb329a74493abc6766cad31b85b6fa2a',
        n: 1024,
        r: 8,
        p: 1 },
     mac: 'f4425caa02c682c74ffe1ba546ddec1f7e85b573848b896ef1e80f09adbc5511' } }

Значение равно . n_ В других реализациях, по-видимому, установлено количество раундов хеширования (упомянутое в keythereum ). Являются ли эти параметры менее безопасными? Если да, то в какой степени? Если нет, то почему?kdfparams1024262144

Ответы (1)

Что ж, приступим:

Во-первых, AES — это не функция ХЕШИРОВАНИЯ, а функция криптографии. Это не то же самое, поэтому не смешивайте оба.

Количество раундов означает, очевидно, большую безопасность. Это основа шифрования. Чем больше выполнено преобразований, тем меньше уязвимость к атакам дешифрования и анализу. Но больше раундов означает также больше времени выполнения и ресурсов, поэтому вы должны найти среднюю точку, в которой вы оптимизируете безопасность и вычислительные ресурсы. Для меня 1024 кажется справедливым числом.

В вашем случае самым слабым местом является IV. IV никогда не должен быть фиксированным значением, а случайным или псевдослучайным, поскольку использование фиксированного IV делает ваше шифрование более слабым и более уязвимым для атак «криптоанализа».

Надеюсь, мой ответ поможет вам.

FWIW, причина, по которой MyEtherWallet использует меньшее число, чем, скажем, geth, заключается в том, что нецелесообразно использовать такое большое число в браузере. Например, расшифровка хранилища ключей из Mist занимает 20-30 секунд через Javascript. В Firefox это особенно неприятно, так как время ожидания истекает дважды, и вы должны нажать «Продолжить» и надеяться на лучшее.
Не могли бы вы объяснить, почему вы считаете 1024 справедливым? По умолчанию количество раундов, которые использует Geth, в 256 раз больше, чем у MEW. С моей точки зрения непрофессионала, это кажется довольно значительным.
@thoCoStuff Ну, как вы говорите, geth использует в 256 раз большее количество раундов (262144), в то время как, например, keythereum использует всего 65536. Поскольку я немного изучил криптографию, 1024 достаточно для справедливой оптимизации безопасности. Как я уже сказал в своих ответах, очевидно, что чем больше количество раундов, тем безопаснее, но, по моему мнению (я имею в виду, что это просто мнение, шахта) 1024 довольно справедливо покрывает меры безопасности. Я думаю, вы уменьшили количество раундов для более быстрого вычисления или что-то еще. Так что 1024 было бы хорошим числом.
В этом обсуждении «количество раундов» рассматривается отдельно. Разница в значении может быть связана с разными KDF (функция деривации ключей). Различные KDF могут работать с разными значениями. На самом деле разные KDF могут даже иметь разные параметры. Например, в моей установке Parity KDF — «pbkdf2», параметр числа раундов — «c» и равен 10240. Также есть параметр PRF, установленный на «hmac-sha256». В случае OP KDF — это «scrypt», параметр числа раундов — «n», а параметр PRF отсутствует, возможно, потому, что в сценарии есть логика для случайной генерации, поэтому PRF не требуется.
Означает ли большее количество раундов хеширования при генерации ключа шифрования aes-128-ctr более надежное шифрование?
СпросиСетьПолитика конфиденциальности1y, 0v