#kdf — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #kdf, aggregated by home.social.
-
https://www.europesays.com/africa/103125/ Defence Ministry seeks Sh241 billion to safeguard Kenya’s security, sovereignty #DCI #DefenceMinistrySeeksSh241BillionToSafeguardKenya’sSecurity #Headlines #KDF #Kenya #MInistryOfDefence #National #NationalIntelligenceService #news #nis #sovereignty
-
Hallo @marudor, bei https://bahn.expert/details/RE%2091595?journeyId=20250126-844b6efa-18a8-3064-8193-389a433e5298 stehen zwei Züge, auf die der 91595 wendet:
https://bahn.expert/details/RE%2091898/2025-01-26T16%3A03%3A00.000Z?journeyId=20250126-5da7619d-b3fd-35fd-a82b-0fd73d8fdf8c (der ist richtig oder mindestens plausibel) und https://bahn.expert/details/RE%2091893?journeyId=20250126-43ce8dec-014f-3352-896e-cf5d2613673f (diese Wende wäre #FKW -> #KDF). Andere Fahrten bei der Linie sind auch komisch mit verknüpften Zügen.Wahrscheinlich Daten kaputt, ich weiß, aber on the off-chance dass du da was drehen kannst wollte ich mal Bescheid geben.
-
Как и в любой сфере вокруг криптографии полно новостей из ничего. Претендующих не столько на сенсации, сколько выпускаемых в мир лишь для создания в дальнейшем псевдо-правдоподобного маркетинга. Как смешать всё в кучу и якобы обосновано объявить использование ряда алгоритмов небезопасными?
TL;DR: пост о том, чем именно определяется реально используемая на практике криптография. А крики и суета ориентированы на аудиторию понятия не имеющей о стандартах и регламентирующих документах.
Имеет ли смысл при всём этом раскладе ставить использование «Магма» в один ряд с использованием таких же «устаревших» #Triple-DES / #3DES и #Blowfish? Только потому, что они все используют при шифровании блоки длиной 64-бит, но при этом имеют более чем разумную длину ключа? Обосновывая это устаревание киванием в сторону #SWEET32 атаки?
Это определяется режимом использования любого из этих шифров:- какой режим шифрования выбран
- какой «padding mode»
- использование «key meshing» / KDF при этом.
Громогласно и с каждого утюга рассказывалось о чём-то вроде #SWEET32 атаки. Если что-то и пояснялось, то весьма путано и заумно, не для обывателей. Суть при этом сводилась и сводится к тому что:- Для получения возможности угадать содержимое HTTP-cookies надо мониторить долго существующее HTTPS-соединение между браузером и сайтом, сохранив 785 гигабайт трафика.
- Надо создавать внутри этого соединения большое число запросов для заранее предсказуемых данных в ответах, а токен аутентификации должен передаваться в каждом http-запросе.
- Подчёркивать, успешное подтверждение, мол исследователям удалось сделать это меньше чем за пару дней с помощью специального JavaScript-кода для генерации трафика.
А ничего, что никакие вменяемые библиотеки шифруют массивы данных постоянно меняя сессионный ключ?
В крайнем случае #TLS библиотеки ограничивают продолжительность сессий TLS-соединений вообще в целом, а не только для 64-битных шифров, заново устанавливая соединение.
А тот же #OpenVPN давно содержит принудительный повторный выпуск ключей (reneg-bytes 64000000).
Использование ротации ключей для ГОСТ 28147-89 / «Магма» регламентируются официальными документами (использование KDF определяется рекомендациями 1323565.1.022-2018 и 50.1.113-2016) без соответствия этим требованиям в РФ не получить сертификат о корректно реализованной криптографии.
Да и более скоростной вариант такой ротации — key meshing — изменении ключа каждые 1024 байта восходит аж к 2006 году и описан в RFC 4357.
Который именно про ГОСТ 28147-89 и в целом определяет:- режимы шифрования,
- алгоритм усложнения ключей (key meshing),
- режим заполнения (padding mode),
- S-box таблицы перестановок (S-преобразования);
Однако, про RFC 4357 чаще всего вспоминают в несколько ином контексте (см. в конце). И такие вещи как padding mode и key meshing из этого RFC на всём фоне суеты с узлами замены (S-Box) конечно же теряются. Однако, описанный key meshing является гораздо более производительным вариантом классической ротации ключей посредством KDF. Однако в инициативе #КриптоПро имеется одно упущение — не упомянуто каким именно образом изменяется вектор инициализации (IV) во время этого key meshing.
В тоже время, при использовании в TLS 1.2 российского алгоритма «Магма» необходимо реализовывать способ работы с ключами согласно рекомендациях по стандартизации 1323565.1.020-2018).
И сам по себе подход используемого key meshing выполняется исходя из режима шифрования. Для примера можно ознакомиться с режимами #CTR-ACPKM и #OMAC-ACPKM.
Т.е. ACPKM — это Advance Cryptographic Prolongation of Key Material
а CTR-ACPKM делает возможным работа блочного шифра в поточном режиме (вместо потокового).
и OMAC-ACPKM относится к обычным #MAC (выработка имитовставки) — средствам проверки и обеспечения целостности данных.
Эти режимы в России описаны в рекомендациях по стандартизации 1323565.1.017-2018.
И вот у кого после этого всего сохранится впечатление дремучей отсталости РФ в вопросах собственной криптографии на фоне работ прогрессивного мирового сообщества по выведению из эксплуатации устаревших блочных алгоритмов в 64-битными блоками?
«Кузнечик» появился в ГОСТ 34.12-2015 отнюдь не потому, что ГОСТ 28147-89 якобы устарел, потому что нужно вводить развиваться, вводя в обиход и оборот нечто более современное. Поскольку само собой на ровном месте не появится нечто способное когда-нибудь в дальнейшем заменить ГОСТ 28147-89 в лице «Магма».
—————————
Про суету вокруг RFC 4357 — именно в нём были обозначены параметры таблицы перестановок, предложенные #CryptoPro:- OID: 1.2.643.2.2.31.4 (id-Gost28147-89-CryptoPro-D-ParamSet)
- OID: 1.2.643.2.2.31.3 (id-Gost28147-89-CryptoPro-C-ParamSet)
- OID: 1.2.643.2.2.31.2 (id-Gost28147-89-CryptoPro-B-ParamSet)
- OID: 1.2.643.2.2.31.1 (id-Gost28147-89-CryptoPro-A-ParamSet)
Это восходит к тому, что сам по себе ГОСТ 28147-89 позволяет использование различных наборов S-Box'ов, описывая тем самым не один алгоритм, а целое семейство.
И только через десять лет после RFC 4357, уже в ГОСТ 34.12-2015, на государственном уровне оказался официально зафиксирован набор S-Box'ов для однозначного определения шифра «Магма» — один конкретный вариант из множества реализаций ГОСТ 28147-89.
Соответственно, так же создал и RFC 7836 хорошо известным ТК 26 Росстандарта (Техническим комитетом по стандартизации «Криптографическая защита информации»). Описываемый набор S-Box'ов получил обозначение OID: 1.2.643.7.1.2.5.1.1, id-tc26-gost-28147-param-Z.
#маркетинг #криптография #шифры #crypto #cryptography #KDF #инфобез #infosec @Russia -
I'm excited to announce the release of oct v0.11.0 🚀️
oct is a tool for inspecting, configuring and using #OpenPGP cards 🔒 (https://crates.io/crates/openpgp-card-tools)
oct can now set up cards in #KDF mode, the text output format was improved for readability, and some minor bugs were fixed.
Finally, version 0.11.0 uses #rPGP, a pure #Rust OpenPGP library 🦀.
As a result, the binary on #Linux links to four fewer dynamic libraries, while at the same time being 10% smaller. -
Tails - Weak cryptographic parameters in LUKS1 https://tails.boum.org/security/argon2id/index.en.html #cryptsetup #parameter #dm-crypt #argon2id #weakness #crypto #pbkdf2 #tails #luks #kdf
-
@Ihazchaos Hey Terri, zu dem Thema LUKS hat mein @ct_Magazin-Kollege Sylvester Tremmel (@syt) was auf @heiseonline geschrieben.
-
Many of you have been asking for my thoughts on the #LastPass breach, and I apologize that I'm a couple days late delivering.
Apart from all of the other commentary out there, here's what you need to know from a #password cracker's perspective!
Your vault is encrypted with #AES256 using a key that is derived from your master password, which is hashed using a minimum of 100,100 rounds of PBKDF2-HMAC-SHA256 (can be configured to use more rounds, but most people don't). #PBKDF2 is the minimum acceptable standard in key derivation functions (KDFs); it is compute-hard only and fits entirely within registers, so it is highly amenable to acceleration. However, it is the only #KDF that is FIPS/NIST approved, so it's the best (or only) KDF available to many applications. So while there are LOTS of things wrong with LastPass, key derivation isn't necessarily one of them.
Using #Hashcat with the top-of-the-line RTX 4090, you can crack PBKDF2-HMAC-SHA256 with 100,100 rounds at about 88 KH/s. At this speed an attacker could test ~7.6 billion passwords per day, which may sound like a lot, but it really isn't. By comparison, the same GPU can test Windows NT hashes at a rate of 288.5 GH/s, or ~25 quadrillion passwords per day. So while LastPass's hashing is nearly two orders of magnitude faster than the < 10 KH/s that I recommend, it's still more than 3 million times slower than cracking Windows/Active Directory passwords. In practice, it would take you about 3.25 hours to run through rockyou.txt + best64.rule, and a little under two months to exhaust rockyou.txt + rockyou-30000.rule.
Keep in mind these are the speeds for cracking a single vault; for an attacker to achieve this speed, they would have to single out your vault and dedicate their resources to cracking only your vault. If they're trying 1,000 vaults simultaneously, the speed would drop to just 88 H/s. With 1 million vaults, the speed drops to an abysmal 0.088 H/s, or 11.4 seconds to test just one password. Practically speaking, what this means is the attackers will target four groups of users:
1. users for which they have previously-compromised passwords (password reuse, credential stuffing)
2. users with laughably weak master passwords (think top20k)
3. users they can phish
4. high value targets (celebs, .gov, .mil, fortune 100)If you are not in this list / you don't get phished, then it is highly unlikely your vault will be targeted. And due to the fairly expensive KDF, even passwords of moderate complexity should be safe.
I've seen several people recommend changing your master password as a mitigation for this breach. While changing your master password will help mitigate future breaches should you continue to use LastPass (you shouldn't), it does literally nothing to mitigate this current breach. The attacker has your vault, which was encrypted using a key derived from your master password. That's done, that's in the past. Changing your password will re-encrypt your vault with the new password, but of course it won't re-encrypt the copy of the vault the attacker has with your new password. That would be impossible unless you somehow had access to the attacker's copy of the vault, which if you do, please let me know?
A proper mitigation would be to migrate to #Bitwarden or #1Password, change the passwords for each of your accounts as you migrate over, and also review the MFA status of each of your accounts as well. The perfect way to spend your holiday vacation! Start the new year fresh with proper password hygiene.
For more password insights like this, give me a follow!
