#ecdsa — Public Fediverse posts

Nonce Observatory:

Nonce Observatory: как превратить цифровые подписи в систему наблюдаемых nonce-инвариантов Большинство историй про ECDSA/Schnorr nonce звучит одинаково: “повторили nonce — потеряли ключ”. Но реальные дефекты часто тоньше: короткие nonce, частичная утечка битов, смещение, recurrence, window-locality, prefix-семейства, ошибки в multi-signature контексте. Мы собрали исследовательскую систему Nonce Observatory — не “кнопку взлома”, а forensic framework для анализа слабых nonce-структур в: ECDSA • Schnorr/BIP340 • MuSig2/BIP327 Что внутри: protocol-valid bridges affine hidden-nonce families HNP / lattice routes Q-LLL + fplll same-case checks AI sidecar на gpt-oss-20b-TurboQuant-MLX-8bit exact evidence / redaction / claim boundaries full-system audit Главный принцип системы: сигнал ≠ восстановление; кандидат ≠ приватный ключ; claim принимается только если d·G == public key . В статье расскажу: — что такое HNP и зачем он нужен для ECDSA; — как подписи превращаются в affine nonce geometry; — почему BIP340 и MuSig2 требуют protocol bridge; — как Q-LLL используется как lattice backend, а не “магический oracle”; — зачем нужен AI sidecar и почему AI не имеет права принимать d ; — как мы дошли до full-range controlled HNP recovery без nonce brute force; — почему full-system audit важнее красивого demo. Это статья не про “сломать Bitcoin”. Это статья про инженерную дисциплину в криптографической форензике: наблюдаемость, воспроизводимость, проверяемость и честные границы заявлений.

https://habr.com/ru/articles/1031858/

#информационная_безопасность #биткоин #криптография #алгоритмы #nonce #ecdsa #signature #audit

Well, it’s good that someone is drawing a line in the Crypto sand.

Google accelerates its readiness timeline to prepare for “Q-day” with post-quantum cryptography (PQC) migration to 2029. Reminder: Q-day = the date when quantum computing becomes operational and is powerful enough to break the digital signatures that secure the Internet, crypto (blockchain + Ethereum), and just about every other Information system in use today.

The Bitcoin crypto network relies on ECDSA elliptic curve signatures. https://techaptitude.substack.com/p/ecdsa-cryptographys-role-in-securing With an exposed crypto signature public key, a quantum computer could derive the private key. And then, the crypto assets would be freely available to a hacker.

Android 17 will integrate ML-DSA, an algorithm standardized by the NIST to secure digital signatures. https://security.googleblog.com/2026/03/post-quantum-cryptography-in-android.html

https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/ #Crypto #PQC #PostQuantumCryptography #Cryptography #Google #Quantum #QuantumComputing #Q-Day #BlockChain #ECDSA #NIST #ML-DSA #Security #CryptoSecurity #Internet #TechAptitude

Private keys are single points of failure. We've all known this, but we treat it as an operational problem — HSMs, rotation schedules, access policies.

Threshold signatures make it a *cryptographic* problem instead. DKLS23 splits a key across parties so no one holds the full secret, and the output is standard ECDSA.

I wrote up a plain-language explainer: https://eric.mann.blog/why-one-key-shouldnt-rule-them-all-threshold-signatures-for-the-rest-of-us/

Part 1 of a 3-part series. #cryptography #security #ECDSA #ThresholdSignatures

Скриншоты не победить, но скрейпинг можно удорожить: 4 слоя защиты изображений на UGC-платформе

У меня есть платформа для работы с метафорическими ассоциативными картами. Это инструмент психологов, коучей: колода картинок, вопросы, разговор. Звучит нишево, но суть задачи универсальна – авторский визуальный контент в вебе, который надо защитить от массового скачивания и пиратства. При этом контент загружают сами пользователи. Если вы делаете галерею, маркетплейс иллюстраций, образовательную платформу с визуалами или любой сервис, где картинки – это ценность, а не декорация, эта статья для вас. Я расскажу, как выстроил многослойную защиту изображений, не превращая при этом продукт в крепость, из которой неудобно пользоваться.

https://habr.com/ru/articles/1004580/

#WebCrypto_API #защита_изображений #водяные_знаки #UGC #Canvas_API #тайлинг #ECDSA #антипиратство #OffscreenCanvas #rate_limiting

Exploring the world of the artist known as ECDSA!

In the latest TechAptitude post we dive into the primary cryptographic algorithm used in many blockchain based systems including Bitcoin and Ethereum, Binance Smart Chain, and Avalanche - Elliptic Curve Digital Signature Algorithm (ECDSA).

We review ECDSA and how it secures cryptocurrencies like BitCoin and Ethereum.

https://open.substack.com/pub/techaptitude/p/ecdsa-cryptographys-role-in-securing?r=vn8b8&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true #Crypto #CryptoCurrencies #Cryptography #Ciphers #Security #PQC #ECDSA #BlockChain #BitCoin #Ethereum #TechAptitude #KeyPairs #EllipticCurve #CyberSecurity

The Ethereum Foundation wakes up and smells the PQC coffee!

The foundation has made post quantum security a priority and formed a dedicated team to address looming threats from quantum computing.

Keys areas they are working to address are:
1) Transaction signatures and accounts - existing ECDSA transaction signatures as quantum‑vulnerable.

2) Consensus and commitments: KZG and BLS‑based components are recognized as quantum‑vulnerable.

3) Virtual machine architecture: leanVM is positioned as the “cornerstone” of Ethereum’s PQ cryptography strategy, designed to support PQ signatures and ZK‑proof systems efficiently inside the protocol.

4) Ecosystem migration: The roadmap emphasizes backward compatibility so existing wallets, smart contracts, and infrastructure can continue functioning while new PQ standards roll in gradually.

https://www.coindesk.com/tech/2026/01/24/ethereum-foundation-makes-post-quantum-security-a-top-priority-as-new-team-forms #Cryptography #Ethereum #ETH #PQ #PQC #QuantumRisks #ECDSA #Security #QuantumComputing #Quantum

El lado del mal - Bitcoin vs Quantum Computers: Hora de pasar a Post-Quantum Cryptography https://elladodelmal.com/2025/12/bitcoin-vs-quantum-computers-hora-de.html #BitCoin #PQC #Criptografia #Hashing #ECDSA #SLHDSA #Criptomonedas #Blockchain #Quantum

Топологический аудит ECDSA: Практическая реализация с минимальными входными данными

Топологический аудит ECDSA: как найти уязвимости с одной подписью Традиционный анализ безопасности ECDSA требует сотен подписей для выявления уязвимостей. Но что делать, когда у вас есть только одна подпись из блокчейна? Мы разработали AuditCore — систему топологического аудита, которая анализирует безопасность ECDSA, используя лишь публичный ключ и одну реальную подпись. Система автоматически генерирует необходимое количество валидных подписей и проводит глубокий анализ пространства (u_r, u_z) как топологического тора. Ключевые возможности: Определение уязвимостей по топологическим инвариантам (числам Бетти) Расчет TVI Score — количественной метрики уязвимости Автоматическое обнаружение паттернов: фиксированный k, линейные зависимости, кластеры Генерация необходимого количества данных для статистически значимого анализа Система состоит из нескольких специализированных модулей: TopologicalAnalyzer для вычисления персистентных гомологий BettiAnalyzer для интерпретации топологических показателей CollisionEngine для поиска коллизий SignatureGenerator для создания валидных подписей TCON для оценки соответствия топологии тора AuditCore позволяет обнаруживать уязвимости, которые традиционные методы пропускают, включая слабые места в генераторах случайных чисел и системах, подобные той, что привела к компрометации ключей Sony PS3. Полная реализация доступна на GitHub: https://github.com/miroaleksej/AuditCore/tree/main/Scripts

https://habr.com/ru/articles/942190/

#криптография #cryptography #cryptoauditor #cryptoanalysis #topology #tor #криптоанализ #Криптоаудит #топологический_аудит #ecdsa

@Loucovey In what sense? As far as I know, current computers cannot break algorithms such as #RSA, #ECDSA, #AES, or protocols such as Diffie-Hellman / #ECDH.

@Loucovey In what sense? As far as I know, current computers cannot break algorithms such as #RSA, #ECDSA, #AES, or protocols such as Diffie-Hellman / #ECDH.

@Loucovey In what sense? As far as I know, current computers cannot break algorithms such as #RSA, #ECDSA, #AES, or protocols such as Diffie-Hellman / #ECDH.

@Loucovey In what sense? As far as I know, current computers cannot break algorithms such as #RSA, #ECDSA, #AES, or protocols such as Diffie-Hellman / #ECDH.

Сложение точек эллиптической кривой в числах, как на калькуляторе

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

https://habr.com/ru/articles/912658/

#эллиптические_кривые #алгоритмы #математика #умножение #криптография #диффихеллман #ecdsa #ecdh

Сложение точек эллиптической кривой в числах, как на калькуляторе

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

https://habr.com/ru/articles/912658/

#эллиптические_кривые #алгоритмы #математика #умножение #криптография #диффихеллман #ecdsa #ecdh

Сложение точек эллиптической кривой в числах, как на калькуляторе

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

https://habr.com/ru/articles/912658/

#эллиптические_кривые #алгоритмы #математика #умножение #криптография #диффихеллман #ecdsa #ecdh

Сложение точек эллиптической кривой в числах, как на калькуляторе

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

https://habr.com/ru/articles/912658/

#эллиптические_кривые #алгоритмы #математика #умножение #криптография #диффихеллман #ecdsa #ecdh

Реализация постквантовых алгоритмов на Java и Go

В последнее время в СМИ много публикаций о новых квантовых компьютерах, которые представляют угрозу для современной криптографии. Например, недавно Google сообщила о разработке квантового процессора Willow , который в специально сформулированной задаче превышает производительность самого мощного суперкомпьютера в септиллион раз (септиллион = 10 25 ). Хотя квантовая криптография быстро развивается, ей ещё далеко до того, чтобы угрожать современной криптографии. Более того, разработан ряд постквантовых алгоритмов и шифров, которые устойчивы к квантовым вычислениям.

https://habr.com/ru/companies/globalsign/articles/887178/

#Java #криптографического_алгоритм #Google #Willow #Dilithium #QPU #Heron #SHA256 #RSA #ECDSA #ECDH #MLKEM #MLDSA #SLHDSA #постквантовая_криптография #CRYSTALS

Реализация постквантовых алгоритмов на Java и Go

В последнее время в СМИ много публикаций о новых квантовых компьютерах, которые представляют угрозу для современной криптографии. Например, недавно Google сообщила о разработке квантового процессора Willow , который в специально сформулированной задаче превышает производительность самого мощного суперкомпьютера в септиллион раз (септиллион = 10 25 ). Хотя квантовая криптография быстро развивается, ей ещё далеко до того, чтобы угрожать современной криптографии. Более того, разработан ряд постквантовых алгоритмов и шифров, которые устойчивы к квантовым вычислениям.

https://habr.com/ru/companies/globalsign/articles/887178/

#Java #криптографического_алгоритм #Google #Willow #Dilithium #QPU #Heron #SHA256 #RSA #ECDSA #ECDH #MLKEM #MLDSA #SLHDSA #постквантовая_криптография #CRYSTALS

Реализация постквантовых алгоритмов на Java и Go

В последнее время в СМИ много публикаций о новых квантовых компьютерах, которые представляют угрозу для современной криптографии. Например, недавно Google сообщила о разработке квантового процессора Willow , который в специально сформулированной задаче превышает производительность самого мощного суперкомпьютера в септиллион раз (септиллион = 10 25 ). Хотя квантовая криптография быстро развивается, ей ещё далеко до того, чтобы угрожать современной криптографии. Более того, разработан ряд постквантовых алгоритмов и шифров, которые устойчивы к квантовым вычислениям.

https://habr.com/ru/companies/globalsign/articles/887178/

#Java #криптографического_алгоритм #Google #Willow #Dilithium #QPU #Heron #SHA256 #RSA #ECDSA #ECDH #MLKEM #MLDSA #SLHDSA #постквантовая_криптография #CRYSTALS

Реализация постквантовых алгоритмов на Java и Go

В последнее время в СМИ много публикаций о новых квантовых компьютерах, которые представляют угрозу для современной криптографии. Например, недавно Google сообщила о разработке квантового процессора Willow , который в специально сформулированной задаче превышает производительность самого мощного суперкомпьютера в септиллион раз (септиллион = 10 25 ). Хотя квантовая криптография быстро развивается, ей ещё далеко до того, чтобы угрожать современной криптографии. Более того, разработан ряд постквантовых алгоритмов и шифров, которые устойчивы к квантовым вычислениям.

https://habr.com/ru/companies/globalsign/articles/887178/

#Java #криптографического_алгоритм #Google #Willow #Dilithium #QPU #Heron #SHA256 #RSA #ECDSA #ECDH #MLKEM #MLDSA #SLHDSA #постквантовая_криптография #CRYSTALS

#Encryption methods: #sha256 #ECDH, #ECDSA and #RSA NOT Approved by ASD in Australia for beyond 2030. These four methods are used for virtually every Web connection that we create currently. The guidance comes from the Australian Signals Directorate (ASD) https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptography

#Encryption methods: #sha256 #ECDH, #ECDSA and #RSA NOT Approved by ASD in Australia for beyond 2030. These four methods are used for virtually every Web connection that we create currently. The guidance comes from the Australian Signals Directorate (ASD) https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptography

Don't dismiss the #Yubico security advisory, but don't panic either. My hot take, pending further analysis of the full 88-page report, is that at present the problem is limited to ECC signing functions and doesn't provide a practical attack surface for keys that remain in your physical possession, use non-cached KDF for PINs, and aren't connected to untrusted hardware.

1. Read https://www.yubico.com/support/security-advisories/ysa-2024-03/ to learn more about what's wrong, and the full 88-page technical report available from https://ninjalab.io/eucleak/.

2. Stop here if you don't use the #FIDO2, #OpenPGP, or #PIV functions of the card.

If you do have an affected firmware version AND are using elliptic curves for signing, there are some mitigations you can take.

1. Run KDF setup if you haven't already, and then regenerate your PIN numbers for all affected protocols on vulnerable keys. NB: I couldn't find this in the advisory, but it makes sense if you stop and think about it.

2. Add a PIN to your FIDO2 authentication on affected firmware versions.

3. Disable the "touch cache" feature on the key to limit the potential window of exposure window on untrusted hardware.

4. Switch all #ECDSA signing and attestation keys to use #RSA instead of an elliptic curve algorithm if possible. This is generally the default for most impacted functions, but may have been changed by advanced users or by organizational policy. NB: For OpenPGP, make sure you generate a revocation certificate for your signing key first before replacing the signature slot. This may impact other OpenPGP keys too if they were signed with the ECC key, so you might need to re-sign or regenerate your other keys as well.

5. If you rely on FIDO2, supplement your FIDO2 authentication with an additional factor if possible.

6. Revoke and replace keys that must use ECC algorithms for signing keys, use FIDO2 without an additional factor, are likely to be exposed to untrusted hardware, or that can't be used with a device PIN.

The only thing that really makes this vulnerability inconvenient is that the firmware of affected keys can't be replaced. I have seen no announcements about whether or not Yubico will be offering some kind of replacement program to affected customers, but users of RSA signature keys, the default Yubico attestation certificates, or the #YubiOTP protocol do not appear to be impacted at this time.

i want to know, which companies/agencies were doing this highest level common criteria certification evaluation for the #infineon library that had this side-channel. #eucleak #ecdsa

i want to know, which companies/agencies were doing this highest level common criteria certification evaluation for the #infineon library that had this side-channel. #eucleak #ecdsa

i want to know, which companies/agencies were doing this highest level common criteria certification evaluation for the #infineon library that had this side-channel. #eucleak #ecdsa

YubiKeys are vulnerable to cloning attacks thanks to newly discovered side channel - Enlarge (credit: Yubico)

The YubiKey 5, the most widely used h... - https://arstechnica.com/?p=2046777 #ellipticcurvedigitalsignaturealgorithm #two-factorauthentication #cryptography #sidechannels #encryption #security #biz⁢ #ecdsa #2fa

Lol. I was being a bit annoyed at the wording of the #ecdsa concern section in the #archwiki as it lacks neuance and largely just quotes You Know Who^tm as the source.

However it seems like #Wikipedia has almost an identical section on it's wikipage.

Turns out someone just copypasted the section from archwiki.

https://en.wikipedia.org/w/index.php?title=Elliptic_Curve_Digital_Signature_Algorithm&diff=prev&oldid=819880847

https://wiki.archlinux.org/index.php?title=SSH_keys&diff=prev&oldid=406036

#PuTTY #SSH client flaw allows recovery of #cryptographic #privatekeys
The vulnerability (CVE-2024-31497) was discovered by Fabian Bäumer and Marcus Brinkmann of the Ruhr University Bochum and is caused by how PuTTY generates #ECDSA nonces (temporary unique cryptographic numbers) for the NIST P-521 curve used for SSH authentication. The main repercussion of recovering the private key is that it allows unauthorized access to SSH servers or sign commits as the developer.
https://www.bleepingcomputer.com/news/security/putty-ssh-client-flaw-allows-recovery-of-cryptographic-private-keys/

#PuTTY #SSH client flaw allows recovery of #cryptographic #privatekeys
The vulnerability (CVE-2024-31497) was discovered by Fabian Bäumer and Marcus Brinkmann of the Ruhr University Bochum and is caused by how PuTTY generates #ECDSA nonces (temporary unique cryptographic numbers) for the NIST P-521 curve used for SSH authentication. The main repercussion of recovering the private key is that it allows unauthorized access to SSH servers or sign commits as the developer.
https://www.bleepingcomputer.com/news/security/putty-ssh-client-flaw-allows-recovery-of-cryptographic-private-keys/

#PuTTY #SSH client flaw allows recovery of #cryptographic #privatekeys
The vulnerability (CVE-2024-31497) was discovered by Fabian Bäumer and Marcus Brinkmann of the Ruhr University Bochum and is caused by how PuTTY generates #ECDSA nonces (temporary unique cryptographic numbers) for the NIST P-521 curve used for SSH authentication. The main repercussion of recovering the private key is that it allows unauthorized access to SSH servers or sign commits as the developer.
https://www.bleepingcomputer.com/news/security/putty-ssh-client-flaw-allows-recovery-of-cryptographic-private-keys/

#PuTTY #SSH client flaw allows recovery of #cryptographic #privatekeys
The vulnerability (CVE-2024-31497) was discovered by Fabian Bäumer and Marcus Brinkmann of the Ruhr University Bochum and is caused by how PuTTY generates #ECDSA nonces (temporary unique cryptographic numbers) for the NIST P-521 curve used for SSH authentication. The main repercussion of recovering the private key is that it allows unauthorized access to SSH servers or sign commits as the developer.
https://www.bleepingcomputer.com/news/security/putty-ssh-client-flaw-allows-recovery-of-cryptographic-private-keys/

#PuTTY #SSH client flaw allows recovery of #cryptographic #privatekeys
The vulnerability (CVE-2024-31497) was discovered by Fabian Bäumer and Marcus Brinkmann of the Ruhr University Bochum and is caused by how PuTTY generates #ECDSA nonces (temporary unique cryptographic numbers) for the NIST P-521 curve used for SSH authentication. The main repercussion of recovering the private key is that it allows unauthorized access to SSH servers or sign commits as the developer.
https://www.bleepingcomputer.com/news/security/putty-ssh-client-flaw-allows-recovery-of-cryptographic-private-keys/

Цифровые подписи в Ethereum: как с ними работать?

Всем привет! Что значит подписать сообщение? Что для этого нужно? В этой статье расскажу про механизм цифровых подписей в сети Ethereum: как работает, какие стандарты существуют и как их использовать.

https://habr.com/ru/companies/metalamp/articles/807559/

#ecdsa #EIP191 #EIP712 #цифровые_подписи #ethereum #sign_message

Let's Encrypt 簽發新的 Intermediate CA

Let's Encrypt 宣佈簽發新的 Intermediate CA：「New Intermediate Certificates」。

這次用 ISRG Root X1 簽了很多東西出來：

On Wednesday, March 13, 2024, Let’s Encr

https://blog.gslin.org/archives/2024/03/20/11703/lets-encrypt-%e7%b0%bd%e7%99%bc%e6%96%b0%e7%9a%84-intermediate-ca/

#Computer #Murmuring #Network #Privacy #Security #Service #authority #ca #certificate #ecdsa #intermediate #isrg #key #letsencrypt #p384 #pinning #privacy #root #rsa #security #x1 #x2

Let's Encrypt 簽發新的 Intermediate CA

Let's Encrypt 宣佈簽發新的 Intermediate CA：「New Intermediate Certificates」。

這次用 ISRG Root X1 簽了很多東西出來：

On Wednesday, March 13, 2024, Let’s Encr

https://blog.gslin.org/archives/2024/03/20/11703/lets-encrypt-%e7%b0%bd%e7%99%bc%e6%96%b0%e7%9a%84-intermediate-ca/

#Computer #Murmuring #Network #Privacy #Security #Service #authority #ca #certificate #ecdsa #intermediate #isrg #key #letsencrypt #p384 #pinning #privacy #root #rsa #security #x1 #x2

Let's Encrypt 簽發新的 Intermediate CA

Let's Encrypt 宣佈簽發新的 Intermediate CA：「New Intermediate Certificates」。

這次用 ISRG Root X1 簽了很多東西出來：

On Wednesday, March 13, 2024, Let’s Encr

https://blog.gslin.org/archives/2024/03/20/11703/lets-encrypt-%e7%b0%bd%e7%99%bc%e6%96%b0%e7%9a%84-intermediate-ca/

#Computer #Murmuring #Network #Privacy #Security #Service #authority #ca #certificate #ecdsa #intermediate #isrg #key #letsencrypt #p384 #pinning #privacy #root #rsa #security #x1 #x2

Let's Encrypt 簽發新的 Intermediate CA

Let's Encrypt 宣佈簽發新的 Intermediate CA：「New Intermediate Certificates」。

這次用 ISRG Root X1 簽了很多東西出來：

On Wednesday, March 13, 2024, Let’s Encr

https://blog.gslin.org/archives/2024/03/20/11703/lets-encrypt-%e7%b0%bd%e7%99%bc%e6%96%b0%e7%9a%84-intermediate-ca/

#Computer #Murmuring #Network #Privacy #Security #Service #authority #ca #certificate #ecdsa #intermediate #isrg #key #letsencrypt #p384 #pinning #privacy #root #rsa #security #x1 #x2

Let's Encrypt 簽發新的 Intermediate CA

Let's Encrypt 宣佈簽發新的 Intermediate CA：「New Intermediate Certificates」。

這次用 ISRG Root X1 簽了很多東西出來：

On Wednesday, March 13, 2024, Let’s Encr

https://blog.gslin.org/archives/2024/03/20/11703/lets-encrypt-%e7%b0%bd%e7%99%bc%e6%96%b0%e7%9a%84-intermediate-ca/

#Computer #Murmuring #Network #Privacy #Security #Service #authority #ca #certificate #ecdsa #intermediate #isrg #key #letsencrypt #p384 #pinning #privacy #root #rsa #security #x1 #x2

If you’re ever tasked with implementing a cryptography feature–whether a high-level protocol or a low-level primitive–you will have to take special care to ensure you’re not leaking secret information through side-channels.

The descriptions of algorithms you learn in a classroom or textbook are not sufficient for real-world use. (Yes, that means your toy RSA implementation based on GMP from your computer science 101 class isn’t production-ready. Don’t deploy it.)

But what are these elusive side-channels exactly, and how do you prevent them? And in cases where you cannot prevent them, how can you mitigate the risk to your users?

Contents

• Cryptographic Side-Channels
  • Timing Leaks
  • Power Usage
  • Electromagnetic Emissions
• Side-Channel Prevention and Mitigation
  • Prevention vs. Mitigation
  • What is Constant-Time?
  • Malicious Environments and Algorithmic Constant-Time
  • Mitigation with Blinding Techniques
• Design Patterns for Algorithmic Constant-Time Code
  • Constant-Time String Comparison
  • Alternative: “Double HMAC” String Comparison
  • Constant-Time Conditional Select
  • Constant-Time String Inequality Comparison
  • Constant-Time Integer Multiplication
  • Constant-Time Integer Division
  • Constant-Time Modular Inversion
  • Constant-Time Null-Byte Trimming
• Further Reading and Online Resources
• Errata

Cryptographic Side-Channels

The concept of a side-channel isn’t inherently cryptographic, as Taylor Hornby demonstrates, but a side-channel can be a game over vulnerability in a system meant to maintain confidentiality (even if only for its cryptography keys).

Cryptographic side-channels allow an attacker to learn secret data from your cryptography system. To accomplish this, the attacker doesn’t necessarily study the system’s output (i.e. ciphertext); instead, they observe some other measurement, such as how much time or power was spent performing an operation, or what kind of electromagnetic radiation was emitted.

Important: While being resistant to side-channels is a prerequisite for implementations to be secure, it isn’t in and of itself sufficient for security. The underlying design of the primitives, constructions, and high-level protocols needs to be secure first, and that requires a clear and specific threat model for what you’re building.

Constant-time ECDSA doesn’t help you if you reuse k-values like it’s going out of style, but variable-time ECDSA still leaks your secret key to anyone who cares to probe your response times. Secure cryptography is very demanding.

Timing Leaks

Timing side-channels leak secrets through how much time it takes for an operation to complete.

There are many different flavors of timing leakage, including:

• Fast-failing comparison functions (memcmp() in C)
• Cache-timing vulnerabilities (e.g. software AES)
• Memory access patterns
• Conditional branches controlled by secrets

The bad news about timing leaks is that they’re almost always visible to an attacker over the network (including over the Internet (PDF)).

The good news is that most of them can be prevented or mitigated in software.

Power Usage

Different algorithms or processor operations may require different amounts of power.

For example, squaring a large number may take less power than multiplying two different large numbers. This observation has led to the development of power analysis attacks against RSA.

Power analysis is especially relevant for embedded systems and smart cards, which are easier to extract a meaningful signal from than your desktop computer.

Some information leakage through power usage can be prevented through careful engineering (for example: BearSSL, which uses Montgomery multiplication instead of square-and-multiply).

But that’s not always an option, so generally these risks are mitigated.

Electromagnetic Emissions

Your computer is a reliable source of electromagnetic emissions (such as radio waves). Some of these emissions may reveal information about your cryptographic secrets, especially to an attacker with physical proximity to your device.

The good news is that research into EM emission side-channels isn’t as mature as side-channels through timing leaks or power usage. The bad news is that mitigations for breakthroughs will generally require hardware (e.g. electromagnetic shielding).

Side-Channel Prevention and Mitigation

Now that we’ve established a rough sense of some of the types of side-channels that are possible, we can begin to identify what causes them and aspire to prevent the leaks from happening–and where we can’t, to mitigate the risk to a reasonable level.

Note: To be clear, I didn’t cover all of the types of side-channels.

Prevention vs. Mitigation

Preventing a side-channel means eliminating the conditions that allow the information leak to occur in the first place. For timing leaks, this means making all algorithms constant-time.

There are entire classes of side-channel leaks that aren’t possible or practical to mitigate in software. When you encounter one, the best you can hope to do is mitigate the risk.

Ideally, you want to make the attack more expensive to pull off than the reward an attacker will gain from it.

What is Constant-Time?

When an implementation is said to be constant-time, what we mean is that the execution time of the code is not a function of its secret inputs.

Vulnerable AES uses table look-ups to implement the S-Box. Constant-time AES is either implemented in hardware, or is bitsliced.

Malicious Environments and Algorithmic Constant-Time

One of the greatest challenges with writing constant-time code is distinguishing between algorithmic constant-time and provably constant-time. The main difference between the two is that you cannot trust your compiler (especially a JIT compiler), which may attempt to optimize your code in a way that reintroduces the side-channel you aspired to remove.

A sufficiently advanced compiler optimization is indistinguishable from an adversary.

John Regehr, possibly with apologies to Arthur C. Clarke

For compiled languages, this is a tractable but expensive problem to solve: You simply have to formally verify everything from the source code to the compiler to the silicon chips that the code will be deployed on, and then audit your supply chain to prevent malicious tampering from going undetected.

For interpreted languages (e.g. PHP and JavaScript), this formal verification strategy isn’t really an option, unless you want to formally verify the runtime that interprets scripts and prove that the operations remain constant-time on top of all the other layers of distrust.

Is this level of paranoia really worth the effort?

For that reason, we’re going to assume that algorithmic constant-time is adequate for the duration of this blog post.

If your threat model prevents you from accepting this assumption, feel free to put in the extra effort yourself and tell me how it goes. After all, as a furry who writes blog posts in my spare time for fun, I don’t exactly have the budget for massive research projects in formal verification.

Mitigation with Blinding Techniques

The best mitigation for some side-channels is called blinding: Obfuscating the inputs with some random data, then deobfuscating the outputs with the same random data, such that your keys are not revealed.

Two well-known examples include RSA decryption and Elliptic Curve Diffie-Hellman. I’ll focus on the latter, since it’s not as widely covered in the literature (although several cryptographers I’ve talked with were somehow knowledgeable about it; I suspect gatekeeping is involved).

Blinded ECDH Key Exchange

In typical ECDH implementations, you will convert a point on a Weierstrass curve to a Jacobian coordinate system .

The exact conversion formula is (, ). The conversion almost makes intuitive sense.

Where does come from though?

It turns out, the choice for is totally arbitrary. Libraries typically set it equal to 1 (for best performance), but you can also set it to a random number. (You cannot set it to 0, however, for obvious reasons.)

Choosing a random number means the calculations performed over Jacobian coordinates will be obscured by a randomly chosen factor (and thus, if is only used once per scalar multiplication, the bitwise signal the attackers rely on will be lost).

I think it’s really cool how one small tweak to the runtime of an algorithm can make it significantly harder to attack.

Design Patterns for Algorithmic Constant-Time Code

Mitigation techniques are cool, but preventing side-channels is a better value-add for most software.

To that end, let’s look at some design patterns for constant-time software. Some of these are relatively common; others, not so much.

If you prefer TypeScript / JavaScirpt, check out Soatok’s constant-time-js library on Github / NPM.

Constant-Time String Comparison

Rather than using string comparison (== in most programming languages, memcmp() in C), you want to compare cryptographic secrets and/or calculated integrity checks with a secure compare algorithm, which looks like this:

1. Initialize a variable (let’s call it D) to zero.
2. For each byte of the two strings:
   1. Calculate (lefti XOR righti)
   2. Bitwise OR the current value of D with the result of the XOR, store the output in D
3. When the loop has concluded, D will be equal to 0 if and only if the two strings are equal.

In code form, it looks like this:

<?phpfunction ct_compare(string $left, string $right): bool{    $d = 0;    $length = mb_strlen($left, '8bit');    if (mb_strlen($right, '8bit') !== $length) {        return false; // Lengths differ    }    for ($i = 0; $i < $length; ++$i) {        $leftCharCode = unpack('C', $left[$i])[1];        $rightCharCode = unpack('C', $right[$i])[1];        $d |= ($leftCharCode ^ $rightCharCode);    }    return $d === 0;}

In this example, I’m using PHP’s unpack() function to avoid cache-timing leaks with ord() and chr(). Of course, you can simply use hash_equals() instead of writing it yourself (PHP 5.6.0+).

Alternative: “Double HMAC” String Comparison

If the previous algorithm won’t work (i.e. because you’re concerned your JIT compiler will optimize it away), there is a popular alternative to consider. It’s called “Double HMAC” because it was traditionally used with Encrypt-Then-HMAC schemes.

The algorithm looks like this:

1. Generate a random 256-bit key, K. (This can be cached between invocations, but it should be unpredictable.)
2. Calculate HMAC-SHA256(K, left).
3. Calculate HMAC-SHA256(K, right).
4. Return true if the outputs of step 2 and 3 are equal.

This is provably secure, so long as HMAC-SHA256 is a secure pseudo-random function and the key K is unknown to the attacker.

In code form, the Double HMAC compare function looks like this:

<?phpfunction hmac_compare(string $left, string $right): bool{    static $k = null;    if (!$k) $k = random_bytes(32);    return (        hash_hmac('sha256', $left, $k)            ===        hash_hmac('sha256', $right, $k)    );}

Constant-Time Conditional Select

I like to imagine a conversation between a cryptography engineer and a Zen Buddhist, that unfolds like so:

• CE: “I want to eliminate branching side-channels from my code.”
• ZB: “Then do not have branches in your code.”

And that is precisely what we intend to do with a constant-time conditional select: Eliminate branches by conditionally returning between one of two strings, without an IF statement.

This isn’t as tricky as it sounds. We’re going to use XOR and two’s complement to achieve this.

The algorithm looks like this:

1. Convert the selection bit (TRUE/FALSE) into a mask value (-1 for TRUE, 0 for FALSE). Bitwise, -1 looks like 111111111…1111111111, while 0 looks like 00000000…00000000.
2. Copy the right string into a buffer, call it tmp.
3. Calculate left XOR right, call it x.
4. Return (tmp XOR (x AND mask)).

Once again, in code this algorithm looks like this:

<?phpfunction ct_select(    bool $returnLeft,    string $left,    string $right): string {    $length = mb_strlen($left, '8bit');    if (mb_strlen($right, '8bit') !== $length) {        throw new Exception('ct_select() expects two strings of equal length');    }        // Mask byte    $mask = (-$returnLeft) & 0xff;    // X    $x = (string) ($left ^ $right);        // Output = Right XOR (X AND Mask)    $output = '';    for ($i = 0; $i < $length; $i++) {        $rightCharCode = unpack('C', $right[$i])[1];        $xCharCode = unpack('C', $x[$i])[1];        $output .= pack(            'C',            $rightCharCode ^ ($xCharCode & $mask)        );    }    return $output;}

You can test this code for yourself here. The function was designed to read intuitively like a ternary operator.

A Word of Caution on Cleverness

In some languages, it may seem tempting to use the bitwise trickery to swap out pointers instead of returning a new buffer. But do not fall for this Siren song.

If, instead of returning a new buffer, you just swap pointers, what you’ll end up doing is creating a timing leak through your memory access patterns. This can culminate in a timing vulnerability, but even if your data is too big to fit in a processor’s cache line (I dunno, Post-Quantum RSA keys?), there’s another risk to consider.

Virtual memory addresses are just beautiful lies. Where your data lives on the actual hardware memory is entirely up to the kernel. You can have two blobs with contiguous virtual memory addresses that live on separate memory pages, or even separate RAM chips (if you have multiple).

If you’re swapping pointers around, and they point to two different pieces of hardware, and one is slightly faster to read from than the other, you can introduce yet another timing attack through which pointer is being referenced by the processor.

If you’re swapping between X and Y before performing a calculation, where:

• X lives on RAM chip 1, which takes 3 ns to read
• Y lives on RAM chip 2, which takes 4 ns to read

…then the subsequent use of the swapped pointers reveals whether you’re operating on X or Y in the timing: It will take slightly longer to read from Y than from X.

The best way to mitigate this problem is to never design your software to have it in the first place. Don’t be clever on this one.

Constant-Time String Inequality Comparison

Sometimes you don’t just need to know if two strings are equal, you also need to know which one is larger than the other.

To accomplish this in constant-time, we need to maintain two state variables:

1. gt (initialized to 0, will be set to 1 at some point if left > right)
2. eq (initialized to 1, will be set to 0 at some point if left != right)

Endian-ness will dictate the direction our algorithm goes, but we’re going to perform two operations in each cycle:

1. gt should be bitwise ORed with (eq AND ((right – left) right shifted 8 times)
2. eq should be bitwise ANDed with ((right XOR left) – 1) right shifted 8 times

If right and left are ever different, eq will be set to 0.

If the first time they’re different the value for lefti is greater than the value for righti, then the subtraction will produce a negative number. Right shifting a negative number 8 places then bitwise ANDing the result with eq (which is only 1 until two bytes differ, and then 0 henceforth if they do) will result in a value for 1 with gt. Thus, if (righti – lefti) is negative, gt will be set to 1. Otherwise, it remains 0.

At the end of this loop, return (gt + gt + eq) – 1. This will result in the following possible values:

• left < right: -1
• left == right: 0
• left > right: 1

The arithmetic based on the possible values of gt and eq should be straightforward.

• Different (eq == 0) but not greater (gt == 0) means left < right, -1.
• Different (eq == 0) and greater (gt == 1) means left > right, 1.
• If eq == 1, no bytes ever differed, so left == right, 0.

A little endian implementation is as follows:

<?phpfunction str_compare(string $left, string $right): int{    $length = mb_strlen($left, '8bit');    if (mb_strlen($right, '8bit') !== $length) {        throw new Exception('ct_select() expects two strings of equal length');    }    $gt = 0;    $eq = 1;    $i = $length;    while ($i > 0) {        --$i;        $leftCharCode = unpack('C', $left[$i])[1];        $rightCharCode = unpack('C', $right[$i])[1];        $gt |= (($rightCharCode - $leftCharCode) >> 8) & $eq;        $eq &= (($rightCharCode ^ $leftCharCode) -1) >> 8;    }    return ($gt + $gt + $eq) - 1;}

Demo for this function is available here.

Constant-Time Integer Multiplication

Multiplying two integers is one of those arithmetic operations that should be constant-time. But on many older processors, it isn’t.

Fortunately, there is a workaround. It involves an algorithm called Ancient Egyptian Multiplication in some places or Peasant Multiplication in others.

Multiplying two numbers and this way looks like this:

1. Determine the number of operations you need to perform. Generally, this is either known ahead of time or .
2. Set to 0.
3. Until the operation count reaches zero:
   1. If the lowest bit of is set, add to .
   2. Left shift by 1.
   3. Right shfit by 1.
4. Return .

The main caveat here is that you want to use bitwise operators in step 3.1 to remove the conditional branch.

Rather than bundle example code in our blog post, please refer to the implementation in sodium_compat (a pure PHP polyfill for libsodium).

For big number libraries, implementing Karatsuba on top of this integer multiplying function should be faster than attempting to multiply bignums this way.

Constant-Time Integer Division

Although some cryptography algorithms call for integer division, division isn’t usually expected to be constant-time.

However, if you look up a division algorithm for unsigned integers with a remainder, you’ll likely encounter this algorithm, which is almost constant-time:

if D = 0 then error(DivisionByZeroException) endQ := 0                  -- Initialize quotient and remainder to zeroR := 0                     for i := n − 1 .. 0 do  -- Where n is number of bits in N  R := R << 1           -- Left-shift R by 1 bit  R(0) := N(i)          -- Set the least-significant bit of R equal to bit i of the numerator  if R ≥ D then    R := R − D    Q(i) := 1  endend

If we use the tricks we learned from implementing constant-time string inequality with constant-time conditional selection, we can implement this algorithm without timing leaks.

Our constant-time version of this algorithm looks like this:

if D = 0 then error(DivisionByZeroException) endQ := 0                  -- Initialize quotient and remainder to zeroR := 0                     for i := n − 1 .. 0 do  -- Where n is number of bits in N  R := R << 1           -- Left-shift R by 1 bit  R(0) := N(i)          -- Set the least-significant bit of R equal to bit i of the numerator  compared := ct_compare(R, D) -- Use constant-time inequality    -- if R > D  then compared ==  1, swap = 1  -- if R == D then compared ==  0, swap = 1  -- if R < D  then compared == -1, swap = 0  swap := (1 - ((compared >> 31) & 1))  -- R' = R - D  -- Q' = Q, Q[i] = 1  Rprime := R - D  Qprime := Q  Qprime(i) := 1 -- The i'th bit is set to 1  -- Replace (R with R', Q with Q') if swap == 1  R = ct_select(swap, Rprime, R)  Q = ct_select(swap, Qprime, Q)end

It’s approximately twice as slow as the original, but it’s constant-time.

Constant-Time Modular Inversion

Modular inversion is the calculation of for some prime . This is used in a lot of places, but especially in elliptic curve cryptography and RSA.

Daniel J. Bernstein and Bo-Yin Yang published a paper on fast constant-time GCD and Modular Inversion in 2019. The algorithm in question is somewhat straightforward to implement (although determining whether or not that implementation is safe is left as an exercise to the rest of us).

A simpler technique is to use Fermat’s Little Theorem: for some prime . This only works with prime fields, and is slower than a Binary GCD (which isn’t necessarily constant-time, as OpenSSL discovered).

BearSSL provides an implementation (and accompanying documentation) for a constant-time modular inversion algorithm based on Binary GCD.

(In the future, I may update this section of this blog post with an implementation in PHP, using the GMP extension.)

Constant-Time Null-Byte Trimming

Shortly after this guide first went online, security researchers published the Raccoon Attack, which used a timing leak in the number of leading 0 bytes in the pre-master secret–combined with a lattice attack to solve the hidden number problem–to break TLS-DH(E).

To solve this, you need two components:

1. A function that returns a slice of an array without timing leaks.
2. A function that counts the number of significant bytes (i.e. ignores leading zero bytes, counts from the first non-zero byte).

A timing-safe array resize function needs to do two things:

1. Touch every byte of the input array once.
2. Touch every byte of the output array at least once, linearly. The constant-time division algorithm is useful here (to calculate x mod n for the output array index).
3. Conditionally select between input[x] and the existing output[x_mod_n], based on whether x >= target size.

I’ve implemented this in my constant-time-js library:

• resize.ts
• trim.ts

Further Reading and Online Resources

If you’re at all interested in cryptographic side-channels, your hunger for knowledge probably won’t be sated by a single blog post. Here’s a collection of articles, papers, books, etc. worth reading.

• BearSSL’s Documentation on Constant-Time Code — A must-read for anyone interested in this topic
• Cryptographically Secure PHP Development — How to write secure cryptography in languages that cryptographers largely neglect
• CryptoCoding — A style guide for writing secure cryptography code in C (with example code!)
• CryptoGotchas — An overview of the common mistakes one can make when writing cryptography code (which is a much wider scope than side-channels)
• Meltdown and Spectre — Two vulnerabilities that placed side-channels in the scope of most of infosec that isn’t interested in cryptography
• Serious Cryptography — For anyone who lacks the background knowledge to fully understand what I’m talking about on this page

Errata

• 2020-08-27: The original version of this blog post incorrectly attributed Jacobian coordinate blinding to ECDSA hardening, rather than ECDH hardening. This error was brought to my attention by Thai Duong. Thanks Thai!
• 2020-08-27: Erin correctly pointed out that omitting memory access timing was a disservice to developers, who might not be aware of the risks involved. I’ve updated the post to call this risk out specifically (especially in the conditional select code, which some developers might try to implement with pointer swapping without knowing the risks involved). Thanks Erin!

I hope you find this guide to side-channels helpful.

Follow my blog for more Defense Against the Bark Arts posts in the future.

https://soatok.blog/2020/08/27/soatoks-guide-to-side-channel-attacks/

#asymmetricCryptography #constantTime #cryptography #ECDH #ECDSA #ellipticCurveCryptography #RSA #SecurityGuidance #sideChannels #symmetricCryptography