Podcasts about ecdsa

In this episode, Anna and Nico speak with Abhi Shelat and Matteo Frigo from Google about their work integrating zero-knowledge proofs into the Google Wallet. They discuss the technical decisions behind the Anonymous Credentials for ECDSA system, including the challenge of designing a proof system where proving must be efficient enough to run on the client device in a large-scale consumer application, and how they design a system using sumcheck and Ligero to overcome NTT issues. The conversation also touches on the process of standardization, the return of ZK to its privacy roots, and the broader significance of seeing advanced cryptography adopted by a major tech company outside the blockchain space. Links: Episode 303: A Dive into Binius with Jim Posen Anonymous credentials from ECDSA libZK: a zero-knowledge proof library European Digital Identity FFTW Doubly-Efficient zkSNARKs Without Trusted Setup Ligero: Lightweight Sublinear Arguments Without a Trusted Setup Everything provable is provable in zero-knowledge Circle STARKs Highlights of libZK, the Google Wallet ZKP Parallel prefix --------------- Register for ZK Hack Berlin happening 20 - 22 June! --------------- Boundless is a universal zero-knowledge protocol developed by RISC Zero, that lets anyone access abundant verifiable compute, regardless of the blockchain they are using. Learn more about Boundless at

I'm joined by guests Rob Hamilton & Vivek to go through the list.Housekeeping (00:01:18) Unleashed.chat rebrands to dataMachineUrgent Vulnerability Disclosures (00:01:52) Private key leak via malformed ECDSA input (00:09:12) ESP32 Security Concerns (00:21:32) Coinos revokes NWC connection secretsVivek's Corner (00:22:51) Invalid mining jobs by AntPool & friends during forksBitcoin • Software Releases & Project Updates (00:37:44) COLDCARD (00:52:47) Sparrow Wallet (00:54:33) Lark (00:55:03) Krux (00:56:37) Cove Wallet (00:59:09) Nunchuk Desktop (01:00:32) BTCPayServer (01:00:44) Bitcoin Keeper (01:01:25) BlueWallet (01:02:08) Bitcoin Safe (01:03:15) Bitkey App (01:04:05) libwally-core (01:06:00) Bisq2 (01:06:04) RoboSats (01:06:08) Boltz Exchange (01:06:10) Zaprite (01:06:13) Blockstream Explorer API (01:07:22) Mempal (01:07:29) Iris Wallet desktop (01:07:31) Utreexo (01:07:34) ESP Miner• Project Spotlight (01:07:38) Reorg Calculator (01:07:51) Bitcoin Core Config Generator (01:09:05) Bitcoin Core Snapshots (01:09:11) Boot Protocol (01:09:18) multisig-backup (01:09:58) Wallet backup (01:10:04) regtest-in-a-podVulnerability Disclosures (01:11:56) JavaScript injection attack (01:15:05) Malicious PyPI package 'set-utils' steals Ethereum private keys (01:16:57) OpenSSH vulnerabilities expose clients and servers to attacks (01:17:05) USB side-channel attacks (01:17:37) Cellebrite (01:17:49) Messengers vulnerabilities (01:17:56) GitVenom (01:18:10) Stablecoin payment firm Infini loses $50M in exploit (01:18:18) Five dollar wrench attacksAudience Questions (01:20:00) Comment on a flaw in Bitcoin Core regarding mining pools and their vulnerability against block withholding attacksNostr • Project spotlight (01:22:32) 24242.io (01:22:49) nostr.media (01:22:58) Frostr (01:23:33) nostr-double-ratchet (01:23:44) DVMCP (01:23:53) Samiz (01:24:00) Welshman (01:24:09) Norma (01:24:20) Wallet Relay (01:24:27) Nostr0 (01:24:35) nAuth Protocol (01:24:43) HostrBoosts (01:25:36) Shoutout to top boosters @sean, @pink monkey, @Anonymous, @martinbarilik, @Momo Tahmasbi & @jespada.Links & Contacts:Website: https://bitcoin.review/Substack: https://substack.bitcoin.review/Twitter: https://twitter.com/bitcoinreviewhqNVK Twitter: https://twitter.com/nvkTelegram: https://t.me/BitcoinReviewPodEmail: producer@coinkite.comNostr & LN: ⚡nvk@nvk.org (not an email!)Full show notes: https://bitcoin.review/podcast/episode-93

YouTube: https://youtu.be/hcdk3u2R5Mo Yesterday, I gave two short presentations on PQC (Post Quantum Cryptography), and next week, I'm in London to give a more focused talk on the subject. And so, it's great to see that Samsung is driving forward the adoption of PQC methods in their new S25 smartphone. There are two companies that have a core focus on creating trusted hardware for consumers: Apple and Samsung. Apple has always had a core focus on making sure they use the best cryptography to not only secure their devices but also to make them privacy-aware. Samsung, too, has strived for improved security but, at times, has made a few slip-ups along the way, but always patched around them. Now, Samsung Electronics has integrated PQC into their Galaxy S25 series of devices. The need for this is that NIST will deprecate all our existing public key methods in 2030, including: RSA for public key encryption; RSA, ECDSA and EdDSA for signatures; and ECDH for key exchange. NIST will then remove them in 2035 from the NIST FIPS 140 standard. Given that a smartphone will have a life of at least five years, it makes sense to build the hardware to support the migration. Along with this, we see the rise of “harvest now, decrypt later” threats, where network traffic could be captured now and then decrypted sometime in the future. The main integration at the current time involved ML-KEM (FIPS 203, aka Kyber) and ML-DSA (FIPS 204, aka Dilithium). With ML-KEM we replace key exchange and public key encryption methods, while ML-DSA provides us with digital signing: These methods will be the Samsung Knox Matrix for enhanced data protection — this includes end-to-encryption for back-ups and the recovery of data from the Samsung Cloud. Overall, Samsung devices, like Apple hardware, have a secure enclave to store private and secret keys, and where not even Samsung can get access to them. The usage of PQC will mean that Samsung devices will be able to communicate with other devices in the future and which are using PQC methods. This ensures not only current compatibility but also future compatibility. An important advancement of the industry is that Samsung will support PQC methods for their backup system to their Cloud. Conclusions Of course, the integration will not force applications and services to use PQC, and in most cases, it will still use our traditional methods, as devices that it connects to must support PQC. Thus, we will see a migration towards PQC, rather than a hard switch-over. In cryptography, this is often the case, as we can typically negotiate the cryptography methods that are used in the secure transmission or storage of data. Once all the required services and applications support PQC, our existing public key methods will likely be switched off.

* New Phishing Scam Uses Fake CAPTCHA Tests to Install Malware* Google Releases Open-Source Tool to Speed Up Android Security Patching* The Global Trail of Stolen Smartphones* Year-Long Attack Steals Credentials from Security Researchers and Hackers* Australia Leads the Way in Quantum-Resistant CryptographyNew Phishing Scam Uses Fake CAPTCHA Tests to Install Malwarehttps://au.pcmag.com/security/107245/this-captcha-test-can-trick-windows-users-into-installing-malwareA new phishing scam is targeting unsuspecting users with fake CAPTCHA tests. These malicious tests, disguised as legitimate security measures, are designed to trick victims into installing malware on their devices.How the Scam Works:* Fake CAPTCHA: Users encounter a fake CAPTCHA test on a malicious website.* Malicious Instructions: The CAPTCHA asks users to perform specific keystrokes, such as "Windows + R" followed by "Ctrl + V."* Malware Installation: These keystrokes execute a PowerShell script that downloads and installs the Lumma Stealer malware.* Data Theft: Once installed, the Lumma Stealer can steal sensitive information, including passwords, cookies, and cryptocurrency wallet details.The Growing Threat of Phishing Attacks:This latest phishing scam highlights the ongoing threat posed by cybercriminals who continuously evolve their tactics to target unsuspecting users. It's crucial to remain vigilant and exercise caution when encountering online requests, especially those involving unusual actions.Tips to Protect Yourself:Be Wary of Unusual CAPTCHAs, If a CAPTCHA test asks you to perform actions beyond simple image recognition, be suspicious. And avoid clicking on links in unsolicited emails or messages, even if they appear to come from a trusted source.Google Releases Open-Source Tool to Speed Up Android Security Patchinghttps://security.googleblog.com/2024/12/announcing-launch-of-vanir-open-source.htmlGoogle has released Vanir, a new open-source tool designed to streamline the process of identifying and applying security patches to Android devices.The Problem:The Android ecosystem relies on a complex update process where manufacturers must incorporate security fixes from Google and deploy them to individual devices. This process is time-consuming and labor-intensive, often leaving devices vulnerable for longer periods.Vanir's Solution:Vanir uses static code analysis to directly compare a device's code against known vulnerable code patterns. This approach avoids relying on unreliable metadata like version numbers and focuses on the actual code itself.Benefits of Vanir:* Faster Patch Identification: Vanir automates the identification of missing security patches, significantly reducing the time it takes for manufacturers.* Improved Accuracy: Vanir boasts a 97% accuracy rate, minimizing false alarms and wasted effort.* Scalability: Vanir can be applied across diverse Android ecosystems and can be easily adapted to other platforms with minor modifications.* Open Source: By making Vanir open source, Google encourages collaboration and wider adoption within the security community.Impact:Vanir is expected to significantly improve the security posture of Android devices by enabling faster and more efficient deployment of critical security patches. This will ultimately benefit all Android users by reducing their exposure to vulnerabilities.Availability:Vanir is available now on GitHub under the BSD-3 license. The tool can be used as a standalone application or integrated into existing build systems.The Global Trail of Stolen Smartphoneshttps://www.dailymail.co.uk/news/article-14165053/How-stolen-phone-ends-Chinas-Silicon-Valley.htmlA Dark Journey from London Streets to Chinese MarketsThe theft of mobile phones in major cities like London has become a significant global issue, with stolen devices often ending up thousands of miles away in China.The Theft and Smuggling Process:* Street Theft: Phone snatchers, often operating in gangs, target unsuspecting victims in busy areas.* Handoff to Brokers: Stolen phones are quickly passed on to brokers, who may be involved in other criminal activities.* Securing the Device: To prevent tracking, the phones are placed in Faraday cages to block signals.* Shipping to China: The phones are shipped to China, often through intricate smuggling routes.* Repairs and Resale: In China, stolen phones are either sold as second-hand devices or disassembled for parts. Valuable components like gold, silver, and lithium-ion batteries are extracted.The Impact on Victims:Beyond the financial loss, victims of phone theft may also face privacy and security risks. Stolen phones can be used to access personal information, financial accounts, and social media profiles.Combating the Problem:Law enforcement agencies, technology companies, and governments are working together to combat phone theft and the global black market. Some strategies include:* Improved Tracking Technologies: Phone manufacturers are implementing advanced tracking and security features to deter theft and facilitate recovery.* International Cooperation: Law enforcement agencies are collaborating across borders to disrupt criminal networks involved in phone theft and smuggling.* Public Awareness Campaigns: Educating the public about the risks of phone theft and how to protect themselves.While significant progress has been made, the global trade in stolen phones remains a complex issue. By understanding the methods used by criminals and the international supply chain, we can work towards more effective prevention and recovery strategies.Year-Long Attack Steals Credentials from Security Researchers and Hackershttps://securitylabs.datadoghq.com/articles/mut-1244-targeting-offensive-actors/Over 390,000 WordPress credentials and sensitive data stolen in a large-scale campaign targeting cybersecurity professionals.A sophisticated cyberespionage campaign spanning over a year has compromised hundreds of systems belonging to security researchers, penetration testers, and potentially even malicious actors. Datadog Security Labs discovered the campaign, which is believed to be carried out by a threat actor tracked as MUT-1244.Fake Exploits and Phishing Lured VictimsThe attackers used a two-pronged approach:* Trojanized Repositories: They created fake repositories on GitHub containing malicious code disguised as proof-of-concept exploits for known vulnerabilities. Security professionals searching for exploit code unknowingly downloaded and executed the malware.* Phishing Emails: Phishing emails tricked victims into installing fake kernel updates that were actually malware.Stolen Data Included SSH Keys and AWS CredentialsThe malware targeted valuable data, including:* WordPress credentials (over 390,000 stolen)* SSH private keys* AWS access keys* Command historyAttackers Exploited Trust Within Security CommunityThe use of fake repositories on trusted platforms like GitHub allowed the attackers to exploit trust within the cybersecurity community. Additionally, some of the stolen credentials likely belonged to attackers who were using a tool called "yawpp" to validate stolen credentials. This suggests the attackers were targeting both legitimate security professionals and malicious actors.Hundreds Still at Risk as Campaign ContinuesResearchers believe hundreds of systems remain compromised, and the campaign is still ongoing. Security professionals and researchers are advised to be cautious when downloading code from untrusted sources and to be wary of unsolicited emails, even those seemingly related to security updates.Australia Leads the Way in Quantum-Resistant Cryptographyhttps://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptographyAustralia's Cyber Security Agency Accelerates Transition to Post-Quantum CryptographyThe Australian Signals Directorate (ASD) has announced plans to phase out traditional cryptographic algorithms like SHA-256, RSA, ECDSA, and ECDH in high-assurance cryptographic equipment by 2030. This move aims to proactively address the potential threat posed by quantum computing advances, which could render current encryption methods obsolete.The Quantum Threat:Quantum computers, once fully realized, have the potential to break current cryptographic standards, compromising sensitive data and systems. To mitigate this risk, the US National Institute of Standards and Technology (NIST) has developed new quantum-resistant algorithms.Australia's Proactive Approach:While NIST has set a 2035 deadline for transitioning to quantum-resistant cryptography, Australia is taking a more aggressive stance, aiming to complete the transition five years earlier for high-assurance systems. This proactive approach demonstrates Australia's commitment to cybersecurity and its recognition of the potential impact of quantum computing.Challenges of the Transition:The transition to post-quantum cryptography presents significant challenges, including:* Technical Complexity: Implementing new cryptographic algorithms requires careful planning and technical expertise.* Interoperability: Ensuring compatibility with existing systems and standards is crucial.* Security Risks: A poorly executed transition could introduce new vulnerabilities.The Road Ahead:As quantum computing technology continues to advance, it is essential for organizations to stay informed about the latest developments and to plan for a smooth transition to quantum-resistant cryptography. By taking proactive steps to adopt new standards, organizations can protect their sensitive data and systems from future threats. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit edwinkwan.substack.com

Alfred Menezes is a Professor at the University of Waterloo in Ontario.  In 2001, he won the Hall Medal from the Institute of Combinatorics and its Applications.  Alfred is the lead author of the Handbook of Applied Cryptography, and  which has been cited over 25,000 times. He has published many high impact papers, especially in areas of public key encryption and elliptic curve cryptography, and was the co-inventor of the ECDSA signature method. His website for online courses is https://cryptography101.ca. The "Cryptography101: Building Blocks" and "Cryptography 101: Deployments" courses are lectures from the undergraduate "Applied Cryptography" that he has taught at Waterloo since 2000. The former includes a five-lecture introduction to elliptic curve cryptography. He also has a course on "Kyber and Dilithium", and soon an intro to "Lattice-based cryptography".   Video recording: https://www.youtube.com/watch?v=l5GWFAewQ80

The cybersecurity world is changing, and where the signature methods of RSA, ECDSA and EdDSA are likely to be replaced by FIPS 204 (aka ML-DSA Module-Lattice-Based Digital Signature Standard— Dilithium) and FIPS 205 (aka SLH-DSA (Stateless Hash-based Digital Signature Standard — SPHINCS+) https://medium.com/@billatnapier/so-what-is-a-prehash-and-what-has-it-to-do-with-post-quantum-signatures-bf7812cfa203

Considerations in paying down tech debt, make Rust work on bare metal, ECDSA side-channel in Yubikeys, trade-offs in deploying SSO quickly, and more! Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw-298

Considerations in paying down tech debt, make Rust work on bare metal, ECDSA side-channel in Yubikeys, trade-offs in deploying SSO quickly, and more! Show Notes: https://securityweekly.com/asw-298

Considerations in paying down tech debt, make Rust work on bare metal, ECDSA side-channel in Yubikeys, trade-offs in deploying SSO quickly, and more! Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw-298

Considerations in paying down tech debt, make Rust work on bare metal, ECDSA side-channel in Yubikeys, trade-offs in deploying SSO quickly, and more! Show Notes: https://securityweekly.com/asw-298

Enjoying the content? Let us know your feedback!In this episode we're diving into an important topic that concerns one of the most trusted hardware security tokens on the market—the YubiKey 5 series.We'll discuss a recently discovered vulnerability affecting YubiKeys and go over what it means for the broader world of authentication and cryptographic security. To help you fully understand the issue, I'll also provide a quick primer on key concepts like digital signatures, elliptic curves, and the cryptographic algorithm known as ECDSA. With that said, this episode is an update as well as a main topic  and all in all it will give you the tools you need to stay informed and protected.- https://www.yubico.com: Yubico Advisories- https://ninjalab.io: The research Be sure to subscribe! If you like the content. Follow me @iayusuf or read my blog at https://yusufonsecurity.comYou will find a list of all previous episodes in there too.

Dark Skippy is a new attack that in theory, makes it much easier for a malicious person to steal your coins. Listen in to learn about some of the ins and outs here, as well as mitigation and the path forward for the industry from @utxoclub , @LLFOURN & @robin_linus .  Why air gapping is not the be all end all Dark Skippy in context with other attacks Security while signing transactions, and security while generating keys RFC6979 Deterministic nonce generation Updating PSBT to help mitigate this attack Summary The conversation discusses the ‘Dark Skippy' attack, a new method for leaking secret keys from a malicious signing device. The attack takes advantage of the nonces used in the Schnorr and ECDSA signature schemes. The new attack vector can potentially extract private keys and seed words from hardware wallets. The attack targets the nonce generation process during key generation and signing. The previous versions of this attack were inefficient, but Dark Skippy improves upon them. The contributors explain how the attack came about and its implications for hardware wallet security. They also discuss the RFC6979 deterministic nonce generation and the concept of anti-klepto signing protocols as mitigations against the attack.  While Dark Skippy is a sophisticated attack, it requires a high level of expertise and is not currently seen in the wild. The discussion highlights the importance of secure boot, upgrading the Partially Signed Bitcoin Transaction (PSBT) process, and improving the randomness of upfront key generation as potential mitigations.  However, it is emphasized that current reputable hardware wallets still provide a high level of security, and there is no immediate action required for users. Takeaways Dark Skippy is a new attack that leaks secret keys from a malicious signing device. The attack exploits the nonces used in the Schnorr and ECDSA signature schemes. Previous versions of this attack were inefficient, but Dark Skippy improves upon them. Mitigations against the attack include the RFC6979 deterministic nonce generation and anti-klepto signing protocols. Dark Skippy is a sophisticated attack that targets the nonce generation process during key generation and signing. Mitigations for Dark Skippy include implementing secure boot, upgrading the PSBT process, and improving the randomness of upfront key generation. Reputable hardware wallets currently provide a high level of security, and there is no immediate action required for users. The discussion highlights the importance of ongoing research and development to enhance the security of hardware wallets and protect against potential future attacks. Timestamps: (00:00) - Intro (00:45) - What is ‘Dark Skippy'? (04:39) - Is it an old attack vector? Bitcoin's security evolving with time (12:41) - Sponsor (15:22) - What is a nonce?, RFC6979 Deterministic nonce generation (22:55) - Common ways of people losing their Bitcoin (31:08) - Sponsor (32:07) - Anti-klepto signing protocols; ways to mitigate risks of losing coins (39:51) - Updating PSBT to help mitigate this attack (43:26) - The role of Multisig in preventing the attack (49:57) - Other attack vectors in malicious actor's toolkit (56:49) - Summarizing the steps to improve the ecosystem security (1:00:18) - Closing thoughts Links:  https://darkskippy.com/  https://frostsnap.com/  https://x.com/LLFOURN  https://x.com/robin_linus  https://x.com/utxoclub  https://x.com/utxoclub/status/1820520960476561825  Sponsors: CoinKite.com (code LIVERA) mempool.space/accelerator  Stephan Livera links: Follow me on X: @stephanlivera Subscribe to the podcast Subscribe to Substack

Mark “Murch” Erhardt and Mike Schmidt are joined by Ethan Heilman and Gloria Zhao to discuss ⁠Newsletter #301⁠. News Consensus-enforced lamport signatures on top of ECDSA signatures (1:00) Bitcoin Core PR Review Club Index TxOrphanage by wtxid, allow entries with same txid (31:04) Releases and release candidates Libsecp256k1 v0.5.0 (51:15) LND v0.18.0-beta.rc1 (52:12) Notable code and documentation changes Bitcoin Core #28970 (26:33) Bitcoin Core #28016 (53:05) Bitcoin Core #29623 (57:00)

My guest today is Cameron Robertson, founder of Arx. Arx is an NFC chip with a ECDSA private key. On this episode, Cameron and I dive into the devices and protocols at the intersection of NFC and blockchain. We discuss tamper resistance, signing APIs, and the interaction patterns available in today's mobile device ecosystem. It was great learning more about Arx from Cameron. This episode was recorded in person at EthDenver. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks and you alone are responsible for doing your research and making your own decisions. Links Hosted by @nicholas Arx

A conversation with Matt Luongo, the founder of Thesis.co and Threshold Network (aka tBTC).Full show notes: solfate.com/podcast/40Watch this episode on YouTube: youtube.com/watch?v=A05AtK7WX1IFollow the @SolfatePod show on Twitter for updates. Thanks for listening frens :)Notes from the showIn this conversation, Matt Luongo discusses Threshold Network and tBTC, a cross-chain bridge for Bitcoin. He explains how Threshold Network combines the capabilities of Keep and NuCypher to enable threshold cryptography and custody of ECDSA keys off-chain. Matt also highlights the role of Bitcoin's scripting language in tBTC and the challenges of bridging Bitcoin to other chains, including Solana. He emphasizes the importance of trust models and settlement times in the tBTC ecosystem. Finally, Matt shares the availability of tBTC on Solana and the potential for expanding Threshold Network to support decentralized custodial escrow systems for various assets.TakeawaysThreshold Network combines Keep and NuCypher to enable threshold cryptography and custody of ECDSA keys off-chain.tBTC uses Bitcoin's scripting language to create a bridge between Bitcoin and other chains.Settlement times for tBTC range from one to two and a half hours, depending on the amount being bridged.tBTC is available on Solana, allowing users to purchase and trade the token on decentralized exchanges.Threshold Network has the potential to expand beyond Bitcoin and support decentralized custodial escrow systems for various assets.Find Matt and Threshold Network onlineFollow Matt on twitter - @mhluongoFind the Threshold Network on twitter - @TheTNetworkVisit the Threshold Network website - threshold.networkVisit the Thesis.co website - thesis.coFollow us aroundNicktwitter: @nickfrostygithub: github.com/nickfrostywebsite: https://nick.afJamestwitter: @jamesrp13github: github.com/jamesrp13Solfate Podcasttwitter: @SolfatePodmore podcast episodes: solfate.com/podcast

My guests today are DC Posch and Nalin Bhardwaj, co-founders of Daimo. Daimo is a stablecoin focused iOS wallet built with Passkeys and AA Smart Accounts. On this episode, DC, Nalin, and I discuss their new p256Verifier contract, which is an audited Solidity implementation of p256r1 verification. We discuss the ins-and-outs of gas optimized onchain p256 verification, compare their contract to the FreshCryptoLib implementation, and consider the limitations of precomputation. We cover EIP-7212, which DC and Nalin co-authored alongside the team from Clave, and discuss Daimo's exciting proposal for progressive precompiles, also known as precompile shadowing, which would allow precompiles to elegantly replace the p256Verifier, on chains where it is adopted. It was fantastic learning from DC and Nalin who are experts working at the intersection of WebAuthn cryptography and blockchain. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks and you alone are responsible for doing your research and making your own decisions. If you value Web3 Galaxy Brain and would like to support the show, please send me a tweet or DM saying why you listen and what makes Web3 Galaxy Brain special for you. I'll post the best testimonies to the show's website. Thank you! Links Hosted by @nnnnicholas Sign up for the Daimo beta Daimo Daimo Github DC Posch Nalin Bhardwaj EthUniversity Hack Lodge Solidity Summit p256Verifier and Github and Daimo's blog Progressive precompiles (aka Precompile shadowing) FreshCryptoLib WebAuthn Halo2 WebAuthn Circom ZK Sync Era's p256 precompile Awesome WebAuthn Dogan_Eth's State of Verifying p256 Veridise audit Chapters (00:00:00) Intro (00:01:37) How DC and Nalin met: EthUniversity and Hack Lodge (00:03:40) Decentralization and permissionlessness (00:05:57) What is Daimo (00:08:30) Advantages of Smart Contract Accounts (00:12:55) Passkeys and Enclave Keys (00:16:25) Trusted execution environments and firmware updates (00:19:55) Apple binaries and reproducible APKs (00:24:30) Self-custody UX (00:25:58) Why p256 (secp256r1)? (00:28:20) ECDSA vs ZK (00:31:10) Renaud Dubois & FreshCryptoLib's p256 implementation vs Daimo's p256Verifier (00:36:50) Wycheproof test vectors (00:38:00) CPU style optimization for EVM cryptography (00:39:40) Precomputation, or not (00:44:10) EIP-7212 (00:49:05) Progressive Precompiles (aka Precompile shadowing) (00:54:00) EVM equivalence and p256 (01:00:05) Veridise audit (01:02:00) Daimo's forthcoming Base64 encoder (01:03:40) Daimo cross-chain stablecoin wallets (01:06:00) Getting Daimo

We explore how the NIST curve parameter seeds were generated, as best we can, with returning champion Steve Weis!“At the point where we find an intelligible English string that generates theNIST P-curve seeds, nobody serious is going to take the seed provenance concerns seriously anymore.”Transcript: https://securitycryptographywhatever.com/2023/10/12/the-nist-curvesLinks:- Steve's post: https://saweis.net/posts/nist-curve-seed-origins.html- ANSI X9.62 ECDSA: https://safecurves.cr.yp.to/grouper.ieee.org/groups/1363/private/x9-62-09-20-98.pdf / FIPS 186-2 https://csrc.nist.gov/files/pubs/fips/186-2/final/docs/fips186-2.pdf- “A RIDDLE WRAPPED IN AN ENIGMA”: https://eprint.iacr.org/2015/1018.pdf- https://arstechnica.com/information-technology/2015/01/nsa-official-support-of-backdoored-dual_ec_drbg-was-regrettable/- https://www.muckrock.com/foi/united-states-of-america-10/origin-of-fips-186-4-elliptic-curves-over-prime-field-seed-parameters-national-institute-of-standards-and-technology-78756/- https://www.muckrock.com/foi/united-states-of-america-10/origin-of-fips-186-4-elliptic-curves-over-prime-field-seed-parameters-national-security-agency-78755/- Filippo's bounty: https://words.filippo.io/dispatches/seeds-bounty/- Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters - NIST 800-186 with Curve25519 and friends- RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier- https://www.rfc-editor.org/rfc/rfc4492#section-6- https://blog.cryptographyengineering.com/2017/12/19/the-strange-story-of-extended-random/- https://en.wikipedia.org/wiki/Bullrun_(decryption_program)- https://en.wikipedia.org/wiki/BSAFE- https://sockpuppet.org/blog/2015/08/04/is-extended-random-malicious/"Security Cryptography Whatever" is hosted by Deirdre Connolly (@durumcrustulum), Thomas Ptacek (@tqbf), and David Adrian (@davidcadrian)

My guest today is Jose Aguinaga. Jose is Head of Digital Custody Services at SEBA Bank in Switzerland. He was previously Head of Engineering at HOPR. Jose is also the creator of passkeys.is and mpc.is, two valuable educational resources that describe and demonstrate passkeys and multi-party computation, respectively. On this episode, Jose and I go deep on elliptic curve cryptography, ECDSA, passkeys, homomorphic encryption, distributed key generation, account abstraction smart wallets and much more. If you're interested in the frontier of self custody smart wallet user experience, this episode is for you. It was a pleasure talking to Jose who is knowledgable, humble, and generous. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks and you alone are responsible for doing your research and making your own decisions. Links passkeys.is mpc.is Elliptic-curve cryptography ECDSA EdDSA WebAuthn guide Web3 Authentication W3C Passkeys Dev Hierarchical Deterministic Wallets Sui Fireblocks passkeys.dev video demo Homomorphic encryption DeCompute conference Lukas Schor Safe Know Nothing Labs WebAuthn Halo2 Github Sui Sismo Fireblocks Defining Crypto Custody in 2023 by Jose Aguinaga Chapters (00:00:00) Intro (00:01:18) Interview start (00:02:27) Jose's cryptography origin story (00:09:15) What is Elliptic curve cryptography? (00:13:45) What is ECDSA? (00:20:20) What are Passkeys? (00:25:10) What is WebAuthn? (00:28:35) Passkeys (secp256r1) vs EOAs (secp256k1) (00:31:30) Is the secp256r1 compromised? (00:39:50) What happens when creating a passkey? (00:43:55) Passkey UX gotchas & cloud keychain sync (00:53:45) Advantages of passkeys (00:57:15) Passkeys as Smart Wallet signers (01:01:00) Hierarchical deterministic passkeys? (01:03:25) Cross-origin passkeys (01:11:20) Public key registries (01:13:14) largeBlob in Safari 17 (01:15:40) Understanding passkey signatures in DER and CBOR formats (01:20:10) p-384 support (01:21:30) MPC: Multi-party computation, homomorphism, Paillier cryptosystems (01:25:40) DKG: Distributed key generation (01:29:30) Signing an intent with an MPC DKG (01:32:20) Threshold signature scheme (01:35:00) Silence Labs' Decompute MPC for blockchain applications conference (01:37:15) MPC signing vs smart contract passkey signature verification for Account Abstraction applications (01:39:40) Lit Protocol (01:44:40) MPC based AA permissions (01:48:40) Risks of MPC based smart wallet signing: censorship (01:51:20) AA Permissions UX (02:00:28) Know Nothing Labs' Halo2 (zk) based signing (02:04:30) ZKSync's native 4337 (02:05:52) Outro

In research, the publishing of high-quality papers is often critical for the development of a research career: “I am an academic. It's publish or perish.” Daniel J Bernstien. But often we measure the work in terms of quality rather than quantity. One high-quality research paper is probably worth more than the millions of papers published in predatory journals. A great researcher should be able to measure the quality of their work by the known impact and contribution of their research papers, and not by citation count or journal impact factor. In fact, review papers often contribute little to the development of new methods, but are some of the most highly cited papers. A research paper thus has a life. Authors might have a dream that their work is going to fundamentally change a given field, but it ends up never being read much and withers. Overall, most papers just bob along with a few citations in a year, and where you are lucky if you get more than 10 citations. An academic often follow the impact of their papers on Google Scholar, and which can give you an idea of whether their work is rising or on the wain. If you are interested, here's mine showing a nice exponential rise over the past few years: Some papers might rocket with many initial citations, and where researchers cite them heavily, but then either the research area just dies off with a lack of interest, or problems are found with it. Isogenies within post-quantum methods is one example of this, and where a single crack on SIDH (Supersinglar Isogeny Diffie-Hellman) stopped some of the advancements in the field [here]: Up to that point, isogenies were the poster child and the great hope for competing with lattice methods. While they were still slow, researchers were gearing up their research to address many of their performance weakneses. They were much loved, as they used elliptic curves, but one paper stalled the isogeny steam train. I do believe they will return strong, but it will take a while to recover from such a serious crack. Cryptography is often about reputation, and a single crack can bring the whole method down. Other papers, though, can be slow burners. The core papers in ECC (Elliptic Curve Cryptography), for example, did not take off for a few years after the work was published. When Neal Koblitz published his paper on “Elliptic curve cryptosystems” in 1987, it was hardly cited, and few people picked up the potential to replace RSA signatures. In 1997 (10 years after the publication of the paper), it is still only achieved 41 citations. But things really took off around 2005, and especially when Satoshi Nakamoto adopted ECC for Bitcoin around 2009. It now sits at nearly 400 citations per year, and where ECDSA and EdDSA have made a significant impact in replacing our cumbersome RSA methods: Test-of-Time (ToT) Award Now Chris Peikert, Brent Waters, and Vinod Vaikuntanathan (Via-kun-tan-athan) have been awarded the International Association for Cryptologic Research (IACR) Test-of-Time (ToT) Award for a paper entitled “A Framework for Efficient and Composable Oblivious Transfer” and presented at the Crypto 2008 conference [here][1]: Overall, the Test-of-Time Awards is awarded to papers published over 15 years ago, with the three IACR general conferences (Eurocrypt, Crypto and Asiacrypt). The developed framework integrates “universal composability” and which provides strong security properties. Basically, a protocol P1 is secure if another protocol (P2) emulates P1, and where it is not possible to tell the two apart. It introduced a simple method of “dual-mode cryptosystem”. The work has been fundamental in creating Oblivious Transfer protocols, and which are used in Multi-Party Computation (MPC). A great advancement of the paper is in the usage of Learning with Errors (LWE) — and which is now used within lattice cryptography methods. The paper has since laid a foundation for lattice cryptography. As with the ECC method, the paper was a slow-burner [here] with only 11 citations in 2008, but rose to more than 10 times that number: MPC So, let's see if we can build a model where we can securely distribute value and then get our nodes to perform the result of a calculation. None of the nodes should be able to compute the result without the help of others, and where Trent is trusted to distribute the inputs, watch the broadcasts, and then gather the results. For this, we can use Shamir secret shares, and where a value can be split into t-from-n shares and where we need t shares to rebuild our value. So, we could distribute a 2-from-3 to Bob, Alice and Eve, and they Bob and Alice, or Alice and Eve, could rebuild the value back again. So let's say we have two values: x and y, and we want to compute x×y. We then initially start with n parties, and where we define a threshold of t (the minimum number of shares required to rebuild any value. Initially, Trent (the trusted dealer) splits the input values of x and y into shares: Sharesx=x1,x2,…xn Sharesy=y1,y2,…yn Next, Trent sends one share of each to each of the nodes, such as xi and yi to node i. Each node then must gather at least t shares for the nodes, and then aim to add to its own share. Each node is then able to rebuild the values of x and y, and then compute x×y. Trent then receives all the results back and makes a judgement on the consensus. If we have 12 nodes, then if there are at least eight nodes that are fair, the result will be the correct one. Here is the code [here]: package mainimport ( "fmt" "github.com/codahale/sss" "os" "strconv" "encoding/hex")func mult(subset1 map[byte][]byte, subset2 map[byte][]byte) int { a_reconstructed := string(sss.Combine(subset1)) b_reconstructed := string(sss.Combine(subset2)) a,_ := strconv.Atoi(a_reconstructed) b,_ := strconv.Atoi(b_reconstructed) res:=a*b; return(res)}func add(subset1 map[byte][]byte, subset2 map[byte][]byte) int { a_reconstructed := string(sss.Combine(subset1)) b_reconstructed := string(sss.Combine(subset2)) a,_ := strconv.Atoi(a_reconstructed) b,_ := strconv.Atoi(b_reconstructed) res:=a+b; return(res)}func sub(subset1 map[byte][]byte, subset2 map[byte][]byte) int { a_reconstructed := string(sss.Combine(subset1)) b_reconstructed := string(sss.Combine(subset2)) a,_ := strconv.Atoi(a_reconstructed) b,_ := strconv.Atoi(b_reconstructed) res:=a-b; return(res)}func get_shares(shares map[byte][]byte , k byte) map[byte][]byte { subset := make(map[byte][]byte, k) for x, y := range shares { fmt.Printf("Share:t%dt%s ",x,hex.EncodeToString(y)) subset[x] = y if len(subset) == int(k) { break } } fmt.Printf("n") return(subset)}func main() { a:= "10" b:="11" n1:=5 k1:=3 argCount := len(os.Args[1:]) if (argCount>0) {a = (os.Args[1])} if (argCount>1) {b = (os.Args[2])} if (argCount>2) {k1,_ = strconv.Atoi(os.Args[3])} if (argCount>3) {n1,_ = strconv.Atoi(os.Args[4])} n := byte(n1) k := byte(k1) fmt.Printf("a:t%stb: %snn",a,b) fmt.Printf("Policy. Any %d from %dnn",k1,n1) if (k1>n1) { fmt.Printf("Cannot do this, as k greater than n") os.Exit(0) } shares1, _:= sss.Split(n, k, []byte(a)) shares2, _:= sss.Split(n, k, []byte(b)) a_subset:=get_shares(shares1,k) b_subset:=get_shares(shares2,k) res1:=mult(a_subset, b_subset) res2:=add(a_subset, b_subset) res3:=sub(a_subset, b_subset) fmt.Printf("na*b= %dn",res1) fmt.Printf("a+b= %dn",res2) fmt.Printf("a-b= %dn",res3)} A sample run is [here]: a: 10 b: 11Policy. Any 3 from 5Share: 5 fe87 Share: 1 8bd2 Share: 2 16c7 Share: 2 e47a Share: 3 db58 Share: 4 1a9b a*b= 110a+b= 21a-b= -1 and: a: 9999 b: 9998Policy. Any 3 from 6Share: 1 968ada76 Share: 2 44fc9b0c Share: 3 eb4f7843 Share: 4 6d4bf67a Share: 5 1cbaf095 Share: 6 3ef251e3 a*b= 99970002a+b= 19997a-b= 1 Conclusions The paper by Peikert, Vaikuntanathan, and Waters laid the ground for some many areas, including MPC and lattice-based cryptography. After 15 years since it has been published, it has been referenced over 821 times, and is a highly recommended read. And, so, don't measure the initial impact of a paper by the number of citations it receives after a year or two — as its time may yet be to come. For ECRs … have faith in your work … if you keep your focus, your work will get noticed. If not, you perhaps have the wrong focus or in the wrong field. References [1] Peikert, Chris, Vinod Vaikuntanathan, and Brent Waters. “A framework for efficient and composable oblivious transfer.” Annual international cryptology conference. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008. [2] Koblitz, N. (1987). Elliptic curve cryptosystems. Mathematics of computation, 48(177), 203–209.

And, so, we are moving into one of the greatest changes that we ever see on the Internet, and where we will translate from our existing public key infrastructures towards Post Quantum Cryptography (PQC) methods. At the present time, NIST has approved one key exchange/public key encryption method (Kyber) and three digital signature methods (Dilithium, Falcon and SPHINCS+). The focus will now be on seamless integration, and where we will likely use hybrid methods initially and where we include our existing ECDH method with Kyber, and mix either RSA, ECDSA or EdDSA digital sigatures with Dilithum. Key exchange is (relatively) straightforward Overall, Kyber is fairly easy to create a hybrid key exchange method with ECDH, and where we would transmit both the ECC public key and the Kyber public key in the same packet. In fact, Google are already testing its integration in Chrome. With this, our existing key sizes are [here]: Type Public key size (B) Secret key size (B) Ciphertext size (B)------------------------------------------------------------------------ P256_HKDF_SHA256 65 32 65P384_HKDF_SHA384 97 48 97P521_HKDF_SHA512 133 66 133X25519_HKDF_SHA256 32 32 32X448_HKDF_SHA512 56 56 56 Thus, for P256, we have a 32-byte private key (256-bits) and a 65-byte public key (520 bits). Kyber 512 increase the key size of 1,632 bytes for the private key, and 800 bytes (6,400 bits) for the public key: Type Public key size (B) Secret key size (B) Ciphertext size (B)------------------------------------------------------------------------ Kyber512 800 1,632 768Kyber738 1,184 2,400 1,088Kyber1024 1,568 3,168 1,568 Thus, to use a hybrid key exchange method, we would include the ECC public key and the Kyber512 public key and thus have a packet which contains 832 bytes. This is smaller than the 1,500 byte limit for an IP packet and thus requires only one packet to send the public key from Bob to Alice (and vice-versa). A Hybrid method is defined here: https://asecuritysite.com/pqc/circl_hybrid and a test run is: Method: Kyber512-X25519 Public Key (pk) = 3BF9B5BB236AD036BA65B1B532E11927E20269D3CE74009E6C085F0D901F5CC9 (first 32 bytes)Private key (sk) = B96B644DE170BA19266AF32BFA4B3B22A4917888A2EE785C701B7252D6308573 (first 32 bytes)Cipher text (ct) = 0E54F37E171768318B45FD27FBDB08B33CD2204142C4B925BB395DA93AE26EA7 (first 32 bytes)Shared key (Bob): C0B27940D588EE1D0F8348F169BA04A48E0E7FA7DE5B8A091D5D1B59E70D577EEAC4180B076595B2EFCCE96E2271EEA3B20228FC3FD5B63114D32E9D20D9A2F2Shared key (Alice): C0B27940D588EE1D0F8348F169BA04A48E0E7FA7DE5B8A091D5D1B59E70D577EEAC4180B076595B2EFCCE96E2271EEA3B20228FC3FD5B63114D32E9D20D9A2F2Length of Public Key (pk) = 832 bytes Length of Secret Key (sk) = 1664 bytesLength of Cipher text (ct) = 800 bytes Digital Signatures and PKI is not so easy But, what will happen with the next part of the process, and where we need to digitally sign something with a private key and then prove with the public key? This is an important element in HTTPs, and where ECDH is used to exchange the symmetric key, and then digital signatures are used to verify the identity of the server. For this, we use digital certificates (X.509), and which contain the public key of the entity and which has been signed by a trusted entity (Trent). Well, at the present time, it is not quite clear yet, and a new IETF draft perhaps gives some insights [here]: The draft outlines how we could include two public keys in the same certificate: such as an ECC or RSA public key and a PQC public key. Unfortunately, it has been given a “Tombstone notice”, which means it will not progress. The reason for this is that it adds a PQC key — no matter if the host actually wants (or uses) it. Along with this, it does not give a mechanism for coping with two signatures on a method (with a traditional one and a PQC one), and where it is not possible to detect where one of the signatures has been removed — a stripping attack. Public key sizes for Dilithum Like it or not, the days of small public key sizes are coming to an end. In ECC, for NIST P256, we have a 32-byte (256 bit) private key, and a 64-byte (512-bit) public key. For Ed25519, we use Curve 25519, and which reduces the public key to ust 32 bytes (256 bits). For RSA 2K, we have a 256-byte private key (2,048 bits), and a 256-byte public key (2,048 bits). The equivalent security for Dililithum is Dililithum2, and which gives a much larger private key of 2,528 bytes (20,224 bits) and a public key of 1,312 bytes (10,496 bits). The Dilithium public key is thus over 20 times larger than the ECC key. This could be a major overhead in communication systems, and where more than one data packet would have to be sent in order to transmit the public key. Method Public key size Private key size Signature size Security level------------------------------------------------------------------------------------------------------Crystals Dilithium 2 (Lattice) 1,312 2,528 2,420 1 (128-bit) LatticeCrystals Dilithium 3 1,952 4,000 3,293 3 (192-bit) LatticeCrystals Dilithium 5 2,592 4,864 4,595 5 (256-bit) LatticeFalcon 512 (Lattice) 897 1,281 690 1 (128-bit) LatticeFalcon 1024 1,793 2,305 1,330 5 (256-bit) LatticeSphincs SHA256-128f Simple 32 64 17,088 1 (128-bit) Hash-basedSphincs SHA256-192f Simple 48 96 35,664 3 (192-bit) Hash-basedSphincs SHA256-256f Simple 64 128 49,856 5 (256-bit) Hash-basedRSA-2048 256 256 256ECC 256-bit 64 32 256 A hybrid scheme is defined here: https://asecuritysite.com/pqc/circl_dil2 For our existing signatures, we have: Method Public key size (B) Private key size (B) Signature size (B) Security level------------------------------------------------------------------------------------------------------Ed25519 32 32 64 1 (128-bit) EdDSAEd448 57 57 112 3 (192-bit) EdDSAECDSA 64 32 48 1 (128-bit) ECDSARSA-2048 256 256 256 1 (128-bit) RSA And in using a hybrid approach, we increase the signature size of 64 bytes or Ed25519 to 2,484 bytes — a 38-fold increase in size: Method Public key size Private key size Signature size Security level------------------------------------------------------------------------------------------------------Crystals Dilithium2-X25519 2,560 1,344 2,484 1 (128-bit) LatticeCrystals Dilithium3-X25519 4,057 2,009 3,407 3 (192-bit) LatticeCrystals Dilithium 2 (Lattice) 1,312 2,528 2,420 1 (128-bit) LatticeCrystals Dilithium 3 1,952 4,000 3,293 3 (192-bit) LatticeCrystals Dilithium 5 2,592 4,864 4,595 5 (256-bit) LatticeFalcon 512 (Lattice) 897 1,281 690 1 (128-bit) LatticeFalcon 1024 1,793 2,305 1,330 5 (256-bit) LatticeSphincs SHA256-128f Simple 32 64 17,088 1 (128-bit) Hash-basedSphincs SHA256-192f Simple 48 96 35,664 3 (192-bit) Hash-basedSphincs SHA256-256f Simple 64 128 49,856 5 (256-bit) Hash-based And, so, what about using SPHINCS+? That has a 32-byte public key. The downside is that Sphincs SHA256–128f requires a 17,088-byte signature. This would also overload the communication channel and require over 11 packets to send a single signature to prove the identity of a Web site. It is highly unlikely that SPHINCS+ will be used to replace RSA and ECC signatures in ECDH, but where it would be used in applications that did not have a communications channel. Conclusions And, so, the double public key draft has been sent back, and we are awaiting the next iteration. Learn more about PQC here: https://asecuritysite.com/pqc

In cybersecurity, the teaching of Cloud security is often weak. So, here are my Top 100 things about encryption in the Cloud. I've focused on AWS, but Azure is likely to also be applicable. Keys are created in the AWS KMS (Key Management Store). In Azure, this is named KeyVault. The cost of using a key in KMS is around $1/month (prorated hourly). When a key is disabled, it is not charged. With AWS KMS, we use a shared customer HSM (Hardware Security Module), and with AWS CloudHSM it is dedidated to one customer. For data at rest, with file storage, we can integrate encryption with Amazon EBS (Elastic Block Storage) and Amazon S3. Amazon EBS drives are encrypted with AES-256 with XTS mode. For AWS-managed keys, a unique key is used for every object within S3 buckets. Amazon S3 uses server-side encryption to store encrypted data. The customer can use client-side encryption to encrypt data before it is stored in the AWS infrastructure. AWS uses 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) for its symmetric key encryption. In AWS S3, by default, all the objects are encrypted. A customer can use client-side encryption to encrypt data before it goes into the AWS infrastructure. For data at rest, for databases, we can integrate encryption with Amazon RDS (AWS's relational database service) and Amazon Redshift (AWS's data warehousing). For data at rest, we can integrate encryption into ElastiCache (AWS's content caching service), AWS Lambda (AWS's serverless computing service), and Amazon SageMake (AWS's machine learning service). Keys are tokenized and have an ARN (Amazon Resource Names) and alias. An example ARN for a key is arn:aws:kms:us-east-1:103269750866:key/de30e8e6-c753–4a2c-881a-53c761242644, and an example alias is “Bill's Key”. Both of these should be unique in the user's account. To define a KMS key, we can either use its key ID, its key ARN, its alias name, or alias ARN. You can link keys to other AWS Accounts. For this, we specify in the form of “arn:aws:iam::[AWS ID]:root”, and where AWS ID is the ID of the other AWS account. To enhance security, we can use AWS CloudHSM (Hardware Security Module). For simpler and less costly solutions, we typically use AWS KMS (Key Management Solution). For CloudHSM, we pay per hour, but for KMS, we just pay for the usage of the keys. The application of the keys is restricted to defined services. Key identifiers and policies are defined with a JSON key-value pair for data objects. Each key should have a unique GUID, such as “de30e8e6-c753–4a2c-881a-53c761242644”. Users are identified and roles are identified with an ARN, such as : “arn:aws:iam::222222:root”. With the usage of keys we have Key Administrative Permission and a Key Usage policies. There is an explicit denial on a policy if there is not a specific allow defined in a policy. For key permissions, we have fields of “Sid” (the descriptive name of the policy), “Effect” (typically “Allow”), Principal (the ARN of the user/group), “Action” (such as Create, Disable and Delete) and “Resource”. A wildcard (“*”) allows or disallows all. To enable a user of “root” access to everything with a key would be : “Sid”: “Enable IAM User Permissions”, “Effect”: “Allow”,“Principal”: {“AWS”: “arn:aws:iam::22222222:root”},“Action”: “kms:*”, “Resource”: “*”}. The main operations within the KMS are to encrypt/decrpyt data, sign/verify signatures, export data keys, and generate/verify MACs (Message Authentication Codes). Key are either AWS managed (such as for the Lambda service), Customer managed keys (these are created and managed by the customer). Custom key stores are where the customer has complete control over the keys). The main use of keys are for EC2 (Compute), EBS (Elastic Block Storage) and S3 (Storage). AES symmetric keys or an RSA key pair are used to encrypt and decrypt. RSA uses 2K, 3K or 4K keys, and with either “RSA PCKS1 v1.5” or “RSA PSS” padding. RSA PCKS1 v1.5 padding is susceptible to Bleichenbacher's attack, so it should only be used for legacy applications, and for all others, we should use RSA PSS. For RSA, we can use a hashing method of SHA-256, SHA-384 or SHA-512. In RSA, we encrypt with the public key and decrypt with the private key. For signatures, we can use either RSA or ECC signing. For RSA, we have 2K, 3K, or 4K keys, whereas ECC signing uses NIST P256, NIST P384, NIST P521, and SECG P256k1 (as used in Bitcoin and Ethereum). For MACs (Message Authentication Codes), Bob and Alice have the same shared secret key and can authenticate the hash version of a message. In the KMS, we can have HMAC-224, HMAC-256, HMAC-384 and HMAC-512. KMS uses hardware security modules (HSMs) with FIPS 140–2 and which cannot be accessed by AWS employees (or any other customer). Keys will never appear in an AWS disk or backup, and only existing the memory of the HSM. They are only loaded when used. Encryption keys can be restricted to one region of the world (unless defined by the user). With symmetric keys, the key never appears outside the HSM, and for asymmetric keys (public key encryption), the private key stays inside the HSM, and only the public key is exported outside. AWS CloudWatch shows how and when the encryption keys are being used. The minimum time that can be set for a key to be deleted is seven days (and up to 30 days maximum). An organisation can also create its own HSM with the CloudHSM cluster. When a key is then created in KMS, it is then stored in the cluster. The usage of encryption keys should be limited to a minimal set of service requirements. If possible, separate key managers and key users. With a key management (KEY_ADMINISTRATOR) role, we typically have the rights to create, revoke, put, get, list and disable keys. The key management role will typically not be able to encrypt and decrypt. For a key user (KEY_WORKER) role, we cannot create or delete keys and typically focus on tasks such as encrypting and decrypting. Hae a rule of minimum access rights, and simplify user access by defining key administration and usage roles. Users are then added to these roles. Avoid manual updates to keys and use key rotation. The system keeps track of keys that are rotated and can use previously defined ones. The default time to rotate keys is once every year. Key rotation shows up in the CloudWatch and CloudTrail logs. KMS complies with PCI DSS Level 1, FIPS 140–2, FedRAMP, and HIPAA. AWS KMS is matched to FIPS 140–2 Level 2. AWS CloudHSM complies with FIPS 140–2 Level 3 validated HSMs. AWS CloudHSM costs around $1.45 per hour to run, and the costs end when it is disabled or deleted. The CloudHSM is backed-up every 24 hours, and where we can cluster the HSMs into a single logical HSM. CloudHSM can be replicated in AWS regions. AWS KSM is limited to the popular encryption methods, whereas the CloudHSM can implement a wider range of methods. The CloudHSM can support methods such as 3DES with AWS Payment Cryptography. This complies with payment card industry (PCI) standards, such as PCI PIN, PCI P2PE, and PCI DSS. In the CloudHSM for payments, we can generate CVV, CVV2 and ARQC values, and where sensitive details never exist outside the HSM in an unprotected form. With the CloudHSM, we have a command line interface where we can issue commands, and is named CloudHSM CLI. Within the CloudHSM CLI, we can use the genSymKey command to generate symmetric key within the HSM, such as where -t is a key type (31 is AES), -s is a key size (32 bytes) and -l is the label: genSymKey -t 31 -s 32 -l aes256 With genSymKey the key types are: 16 (Generic Secret), 18 (RC4), 21 (Triple DES), and 31 (AES). Within the CloudHSM CLI, we can use the genRSAKeyPair command to generate an RSA key pair, such as where -m is the modulus and -e is the public exponent: genRSAKeyPair -m 2048 -e 65537 -l mykey AWS CloudHSM is integrated with AWS CloudTrail, and where we can track user, role, or an AWS service within AWS CloudHSM. With AWS Payments Cryptography, the 2KEY TDES is Two-key Triple DES and has a 112-bit equivalent key size. The Pin Encryption Key (PEK) is used to encryption PIN values and uses a KEY TDES key. This can store PINs in a secure way, and then decrypt them when required. S3 buckets can be encrypted either with Amazon S3-managed keys (SSE-S3) or AWS Key Management Service (AWS KMS) keys. There is no cost to use SSE keys. For symmetric key encryption, AWS uses envelope encryption, and where a random key is used to encrypt data, and then the key is encrypted with the user's key. AWS should not be able to access the key used for the encryption. The default in creating an encryption key is for it only be to used in a single region, but this can be changed to multi-region, and where the key will be replicated across more than one region. In AWS, a region is a geographical area, and which is split into isolated locations. US-East-1 (N.Virginia) and US-East-2 (Ohio) are different regions, while us-east-1a, us-east-1b and us-east-1c are in the same region. A single region key the US-East-1 region would replicate across eu-east-1a, eu-east-1b and eu-east-1c, and not to eu-east-2a, eu-east-2b and eu-east-2c. When creating a key, you can either create in the KMS, import a key (BYOK — bring your own key), create in the AWS CloudHSM, or create in an external key store (HYOK — hold you own key). For keys stored on-premise we can use an external key store (XKS) — this can be defined as Hold Your Own Keys (HYOKs), and where and where no entity in AWS will able to read any of the encrypted data. [here]. You can BYOK (bring your own key) with KMS, and import keys. KMS will keep a copy of this key. With XKS, we need a proxy URI endpoint, with the proxy credentials of an access key ID, and secret access key. To export keys from AWS CloudHSM, we can encrypt them with an AES key. This is known as key wrapping, as defined in RFC 5648 (for padding with zeros) or RFC 3394 (without padding). A strong password should always be used for key wrapping. AWS encryption operations can either be conducted from the command line or within API, such as with Python, Node.js or Golang. With KMS, the maximum data size is 4,096 bytes for a symmetric key, 190 bytes for RSA 2048 OAEP SHA-256, 318 bytes for RSA 3072 OAEP SHA-256, ad 446 bytes for RSA 4096 OAEP SHA-256. An example command to encrypt a file for 1.txt with symmetric key encryption is: aws kms encryp --key-id alias/MySymKey --plaintext fileb://1.txt --query CiphertextBlob --output text > 1.out To decrypt a file with symmetric key encryption, an example with 1.enc is: aws kms decrypt --key-id alias/BillsNewKey --output text --query Plaintext --ciphertext-blob fileb://1.enc > 2.out In Python, to integrate with KMS, we use the Boto3 library. The standard output of encrypted content is in byte format. If we need to have a text version of ciphertext, we typically use Base64 format. The base64 command can be used to convert byte format in Base64, such as with: $ base64 -i 1.out — decode > 1.enc The xxd command in the command line allows the cipher text to be dumped to a hex output and can then be edited. We can then convert it back to a binary output with: An example piece of Python code for encrypting a plaintext message with the symmetric key in Python is: ciphertext = kms_client.encrypt(KeyId=alias,Plaintext=bytes(secret, encoding='utf8') An example piece of Python code to decrypt some cipher text (in Base64 format) is: plain_text = kms_client.decrypt(KeyId=alias,CiphertextBlob=bytes(base64.b64decode(ciphertext))) To generate an HMAC signature for a message in the command line, we have the form of: aws kms generate-mac --key-id alias/MyHMACKey --message fileb://1.txt --mac-algorithm HMAC_SHA_256 --query Mac > 4.out To verify an HMAC signature for a message in the command line, we have the form of: aws kms verify-mac -key-id alias/MyHMACKey -message fileb://1.txt -mac-algorithm HMAC_SHA_256 -mac fileb://4.mac To create an ECDSA signature in the command line, we have the form of: aws kms sign -key-id alias/MyPublicKeyForSigning -message fileb://1.txt -signing-algorithm ECDSA_SHA_256 -query Signature > 1.out To verify an ECDSA signature in the command line, we have the form of: aws kms verify -key-id alias/MyPublicKeyForSigning -message fileb://1.txt -signature fileb://1.sig -signing-algorithm ECDSA_SHA_256 To encrypt data using RSA in the command line, we have the form of: aws kms encrypt -key-id alias/PublicKeyForDemo -plaintext fileb://1.txt -query CiphertextBlob -output text -encryption-algorithm RSAES_OAEP_SHA_1 > 1.out To decrypt data using RSA in the command line, we have the form of: aws kms decryptb -key-id alias/PublicKeyForDemo -output text -query Plaintext -ciphertext-blob fileb://1.enc -encryption-algorithm RSAES_OAEP_SHA_1 > 2.out To sign data using RSA in the command line, we have the form of: aws kms sign --key-id alias/MyRSAKey --message fileb://1.txt --signing-algorithm RSASSA_PSS_SHA_256 --query Signature --output text > 1.out To verify data using RSA in the command line, we have the form of: aws kms verify --key-id alias/MyRSAKey --message fileb://1.txt — signature fileb://1.sig --signing-algorithm RSASSA_PSS_SHA_256 You cannot encrypt data with Elliptic Curve keys. Only RSA and AES can do that. Elliptic Curve keys are used to sign data. If you delete an encryption key, you will not be able to decrypt any ciphertext that uses it. We can store our secrets, such as application passwords, in the secrets manager. An example of a secret name of “my-secret-passphrase” and a secret string of “Qwery123” we can have: aws secretsmanager create-secret --name my-secret-passphrase --secret-string Qwerty123 In China regions, along with RSA and ECDSA, you can use SM2 KMS signing keys. In China Regions, we can use SM2PKE to encrypt data with asymmetric key encryption. Find out more here: https://asecuritysite.com/aws

Here are my 100 interesting things to learn about cryptography: For a 128-bit encryption key, there are 340 billion billion billion billion possible keys. [Calc: 2**128/(1e9**4)] For a 256-bit encryption key, there are 115,792 billion billion billion billion billion billion billion billion possible keys. [Calc: 2**256/(1e9**8)] To crack a 128-bit encryption with brute force using a cracker running at 1 Teracracks/second, will take — on average — 5 million million million years to crack. Tera is 1,000 billion. [Calc: 2**128/100e9/2/60/60/24/365/(1e6**3)] For a 256-bit key this is 1,835 million million million million million million million million million years. For the brute force cracking of a 35-bit key symmetric key (such as AES), you only need to pay for the boiling of a teaspoon of energy. For a 50-bit key, you just need to have enough money to pay to boil the water for a shower. For a 90-bit symmetric key, you would need the energy to boil a sea, and for a 105-bit symmetric key, you need the energy to boil and ocean. For a 128-bit key, there just isn't enough water on the planet to boil for that. Ref: here. With symmetric key encryption, anything below 72 bits is relatively inexpensive to crack with brute force. One of the first symmetric key encryption methods was the LUCIFER cipher and was created by Horst Feistel at IBM. It was further developed into the DES encryption method. Many, at the time of the adoption of DES, felt that its 56-bit key was too small to be secure and that the NSA had a role in limiting them. With a block cipher, we only have to deal with a fixed size of blocks. DES and 3DES use a 64-bit (eight-byte) block size, and AES uses a 128-bit block size (16 bytes). With symmetric key methods, we either have block ciphers, such as DES, AES CBC and AES ECB, or stream ciphers, such as ChaCha20 and RC4. In order to enhance security, AES has a number of rounds where parts of the key are applied. With 128-bit AES we have 10 rounds, and 14 rounds for 256-bit AES. In AES, we use an S-box to scramble the bytes, and which is applied for each round. When decrypting, we have the inverse of the S-box used in the encrypting process. A salt/nonce or Initialisation Vector (IV) is used with an encryption key in order to change the ciphertext for the same given input. Stream ciphers are generally much faster than block cipers, and can generally be processed in parallel. With the Diffie-Hellman method. Bob creates x and shares g^x (mod p), and Alice creates y, and shares g^y (mod p). The shared key is g^{xy} (mod p). Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method). Adi Shamir defines a secret share method, and which defines a mathematical equation with the sharing of (x,y), and where a constant value in the equation is the secret. With Shamir Secret Shares (SSS), for a quadratic equation of y=x²+5x+6, the secret is 6. We can share three points at x=1, x=2 and y=3, and which gives y=12, y=20, and y=20, respectively. With the points of (1,12), (2,20), and (3,20), we can recover the value of 6. Adi Shamir broke the Merkle-Hellman knapsack method at a live event at a rump session of a conference. With secret shares, with the highest polynomial power of n, we need n+1 points to come together to regenerate the secret. For example, y=2x+5 needs two points to come together, while y=x²+15x+4 needs three points. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled “Cryptographic Communications System and Method”. In public key encryption, we use the public key to encrypt data and the private key to decrypt it. In digital signing, we use the private key to sign a hash and create a digital signature, and then the associated public key to verify the signature. Len Adleman — the “A” in the RSA method — thought that the RSA paper would be one of the least significant papers he would ever publish. The RSA method came to Ron Rivest while he slept on a couch. Martin Gardner published information on the RSA method in his Scientific American article. Initially, there were 4,000 requests for the paper (which rose to 7,000), and it took until December 1977 for them to be posted. The security of RSA is based on the multiplication of two random prime numbers (p and q) to give a public modulus (N). The difficulty of RSA is the difficulty in factorizing this modulus. Once factorized, it is easy to decrypt a ciphertext that has been encrypted using the related modulus. In RSA, we have a public key of (e,N) and a private key of (d,N). e is the public exponent and d is the private exponent. The public exponent is normally set at 65,537. The binary value of 65,537 is 10000000000000001 — this number is efficient in producing ciphertext in RSA. In RSA, the ciphertext is computed from a message of M as C=M^e (mod N), and is decrypted with M=C^d (mod N). We compute the the private exponent (d) from the inverse of the public exponent (e) modulus PHI, and where PHI is (p-1)*(q-1). If we can determine p and q, we can compute PHI. Anything below a 738-bit public modulus is relatively inexpensive to crack for RSA. To crack 2K RSA at the current time, we would need the energy to boil ever ocean on the planet to break it. RSA requires padding is required for security. A popular method has been PCKS#1v1.5 — but this is not provably secure and is susceptible to Bleichenbacher's attack. An improved method is Optimal Asymmetric Encryption Padding (OAEP) and was defined by Bellare and Rogaway and standardized in PKCS#1 v2. The main entity contained in a digital certificate is the public key of a named entity. This is either an RSA or an Elliptic Curve key. A digital certificate is signed with the private key of a trusted entity — Trent. The public key of Trent is then used to prove the integrity and trust of the associated public key. For an elliptic curve of y²=x³+ax+b (mod p), not every (x,y) point is possible. The total number of points is defined as the order (n). ECC (Elliptic Curve Cryptography) was invented by Neal Koblitz and Victor S. Miller in 1985. Elliptic curve cryptography algorithms did not take off until 2004. In ECC, the public key is a point on the elliptic curve. For secp256k1, we have a 256-bit private key and a 512-bit (x,y) point for the public key. A “04” in the public key is an uncompressed public key, and “02” and “03” are compressed versions with only the x-co-ordinate and whether the y coordinate is odd or even. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass (“Vier-strass”) curve. The prime number used with secp256k1 is 2²⁵⁶-2³²-2⁹-2⁸-2⁷-2⁶-2⁴-1. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a “04”. A compressed secp256k1 public key only stores the x-co-ordinate value and whether the y coordinate is odd or even. It starts with a “02” if the y-co-ordinate is even; otherwise, it starts with a “03”. In computing the public key in ECC of a.G, we use the Montgomery multiplication method and which was created by Peter Montgomery in 1985, in a paper entitled, “Modular Multiplication without Trial Division.” Elliptic Curve methods use two basic operations: point address (P+Q) and point doubling (2.P). These can be combined to provide the scalar operation of a.G. In 1999, Don Johnson Alfred Menezes published a classic paper on “The Elliptic Curve Digital Signature Algorithm (ECDSA)”. It was based on the DSA (Digital Signature Algorithm) — created by David W. Kravitz in a patent which was assigned to the US. ECDSA is a digital signature method and requires a random nonce value (k), and which should never be reused or repeated. ECDSA is an elliptic curve conversion of the DSA signature method. Digital signatures are defined in FIPS (Federal Information Processing Standard) 186–5. NIST approved the Rijndael method (led by Joan Daemen and Vincent Rijmen) for Advanced Encryption Standard (AES). Other contenders included Serpent (led by Ross Anderson), TwoFish (led by Bruce Schneier), MARS (led by IBM), and RC6 (led by Ron Rivest). ChaCha20 is a stream cipher that is based on Salsa20 and developed by Daniel J. Bernstein. MD5 has a 128-bit hash, SHA-1 has 160 bits and SHA-256 has 256-bits. It is relatively easy to create a hash collision with MD5. Google showed that it was possible to create a signature collision for a document with SHA-1. It is highly unlikely to get a hash collision for SHA-256. In 2015, NIST defined SHA-3 as a standard, and which was built on the Keccak hashing family — and which used a different method to SHA-2. The Keccak hash family uses a sponge function and was created by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche and standardized by NIST in August 2015 as SHA-3. Hash functions such as MD5, SHA-1 and SHA-256 have a fixed hash length, whereas an eXtendable-Output Function (XOF) produces a bit string that can be of any length. Examples are SHAKE128, SHAKE256, BLAKE2XB and BLAKE2XS. BLAKE 3 is the fastest cryptographically secure hashing method and was created by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox-O'Hearn. Hashing methods can be slowed down with a number of rounds. These slower hashing methods include Bcrypt, PBKDF2 and scrypt. Argon 2 uses methods to try and break GPU cracking, such as using a given amount of memory and defining the CPU utlization. To speed up the operation of the SHA-3 hash, the team reduced the security of the method and reduce the number of rounds. The result is the 12 Kangaroo's hashing method. The number of rounds was reduced from 24 to 12 (with a security level of around 128 bits). Integrated Encryption Scheme (IES) is a hybrid encryption scheme which allows Alice to get Bob's public key and then generate an encryption key based on this public key, and she will use her private key to recover the symmetric. With ECIES, we use elliptic curve methods for the public key part. A MAC (Message Authentication Code) uses a symmetric key to sign a hash, and where Bob and Alice share the same secret key. The most popular method is HMAC (hash-based message authentication code). The AES block cipher can be converted into a stream cipher using modes such as GCM (Galois Counter Mode) and CCM (counter with cipher block chaining message authentication code; counter with CBC-MAC). A MAC is added to a symmetric key method in order to stop the ciphertext from being attacked by flipping bits. GCM does not have a MAC, and is thus susceptible to this attack. CCM is more secure, as it contains a MAC. With symmetric key encryption, we must remove the encryption keys in the reverse order they were applied. Commutative encryption overcomes this by allowing the keys to be removed in any order. It is estimated that Bitcoin miners consume 17.05 GW of electrical power per day and 149.46 TWh per year. A KDF (Key Derivation Function) is used to convert a passphrase or secret into an encryption key. The most popular methods are HKDF, PBKDF2 and Bcrypt. RSA, ECC and Discrete Log methods will all be cracked by quantum computers using Shor's algorithm Lattice methods represent bit values as polynomial values, such as 1001 is x³+1 as a polynomial. Taher Elgamal — the sole inventor of the ElGamal encryption method — and Paul Koche were the creators of SSL, and developed it for the Netscape browser. David Chaum is considered as a founder of electronic payments and, in 1983, created ECASH, along with publishing a paper on “Blind signatures for untraceable payments”. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment. Blockchains can either be permissioned (requiring rights to access the blockchain) or permissionless (open to anyone to use). Bitcoin and Ethereum are the two most popular permissionless blockchains, and Hyperledger is the most popular permissioned ledger. In 1992, Eric Hughes, Timothy May, and John Gilmore set up the cypherpunk movement and defined, “We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.” In Bitcoin and Ethereum, a private key (x) is converted to a public key with x.G, and where G is the base point on the secp256k1 curve. Ethereum was first conceived in 2013 by Vitalik Buterin, Gavin Wood, Charles Hoskinson, Anthony Di Iorio and Joseph Lubin. It introduced smaller blocks, improved proof of work, and smart contracts. NI-ZKPs involves a prover (Peggy), a verifier (Victor) and a witness (Wendy) and were first defined by Manuel Blum, Paul Feldman, and Silvio Micali in their paper entitled “Non-interactive zero-knowledge and its applications”. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge). Bitcoin and Ethereum are pseudo-anonymised, and where the sender and recipient of a transaction, and its value, can be traced. Privacy coins enable anonymous transactions. These include Zcash and Monero. In 1992, David Chaum and Torben Pryds Pedersen published “Wallet databases with observers,” and outlined a method of shielding the details of a monetary transaction. In 1992, Adi Shamir (the “S” in RSA) published a paper on “How to share a secret” in the Communications of the ACM. This supported the splitting of a secret into a number of shares (n) and where a threshold value (t) could be defined for the minimum number of shares that need to be brought back together to reveal the secret. These are known as Shamir Secret Shares (SSS). In 1991, Torbin P Pedersen published a paper entitled “Non-interactive and information-theoretic secure verifiable secret sharing” — and which is now known as Pedersen Commitment. This is where we produce our commitment and then show the message that matches the commitment. Distributed Key Generation (DKG) methods allow a private key to be shared by a number of trusted nodes. These nodes can then sign for a part of the ECDSA signature by producing a partial signature with these shares of the key. Not all blockchains use ECDSA. The IOTA blockchain uses the EdDSA signature, and which uses Curve 25519. This is a more lightweight signature version and has better support for signature aggregation. It uses Twisted Edwards Curves. The core signing method used in EdDSA is based on the Schnorr signature scheme and which was created by Claus Schnorr in 1989. This was patented as a “Method for identifying subscribers and for generating and verifying electronic signatures in a data exchange system”. The patent ran out in 2008. Curve 25519 uses the prime number of 2²⁵⁵-19 and was created by Daniel J. Bernstein. Peter Shor defined that elliptic curve methods can be broken with quantum computers. To overcome the cracking of the ECDSA signature from quantum computers, NIST are standardising a number of methods. At present, this focuses on CRYSTALS-Dilithium, and which is a lattice cryptography method. Bulletproofs were created in 2017 by Stanford's Applied Cryptography Group (ACG). They define a zero-knowledge proof as where a value can be checked to see it lies within a given range. The name “bulletproofs” is defined as they are short, like a bullet, and with bulletproof security assumptions. Homomorphic encryption methods allow for the processing of encrypted values using arithmetic operations. A public key is used to encrypt the data, and which can then be processed using an arithmetic circuit on the encrypted data. The owner of the associated private key can then decrypt the result. Some traditional public key methods enable partial homomorphic encryption. RSA and ElGamal allow for multiplication and division, whilst Pailier allows for homomorphic addition and subtraction. Full homomorphic encryption (FHE) supports all of the arithmetic operations and includes Fan-Vercauteren (FV) and BFV (Brakerski/Fan-Vercauteren) for integer operations and HEAAN (Homomorphic Encryption for Arithmetic of Approximate Numbers) for floating point operations. Most of the Full Homomorphic encryption methods use lattice cryptography. Some blockchain applications use Barreto-Lynn-Scott (BLS) curves which are pairing-friendly. They can be used to implement Bilinear groups and which are a triplet of groups (G1, G2 and GT), so that we can implement a function e() such that e(g1^x,g2^y)=gT^{xy}. Pairing-based cryptography is used in ZKPs. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477. An accumulator can be used for zero-knowledge proof of knowledge, such as using a BLS curve to create to add and remove proof of knowledge. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers. With a Verifiable Delay Function (VDF), we can prove that a given amount of work has been done by a prover (Peggy). A verifier (Victor) can then send the prover a proof value and compute a result which verifies the work has been done, with the verifier not needing to do the work but can still prove the work has been done. A Physical Unclonable Functions (PUFs) is a one-way function which creates a unique signature pattern based on the inherent delays within the wires and transistors. This can be used to link a device to an NFT.

So, here's my Top 100 snippets of knowledge for blockchain: Blockchains use public key methods to integrate digital trust. Bob signs for a transaction with his private key, and Alice proves this with Bob's public key. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled “Cryptographic Communications System and Method”. Blockchains can either be permissioned (requiring rights to access the blockchain) or permissionless (open to anyone to use). Bitcoin and Ethereum are the two most popular permissionless blockchains, and Hyperledger is the most popular permissioned ledger. Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method). David Chaum is considered as founders of electronic payments, and, in 1983, created ECASH, along with publishing a paper on “Blind signatures for untraceable payments”. Miners gather transactions on a regular basis, and these are added to a block and where each block has a Merkle hash. The first block on a blockchain does not have any previous blocks — and is named the genesis block. Blocks are bound in a chain, and where the previous, current and next block hashes are bound into the block. This makes the transactions in the block immutable. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment. Craig Steven Wright has claimed that he is Satoshi Nakamoto, but this claim has never been verified. Most blockchains use elliptic curve cryptography — a method which was created independently by Neal Koblitz and Victor S. Miller in 1985. Elliptic curve cryptography algorithms did not take off until 2004. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass (“Vier-strass”) curve. The prime number used with secp256k1 is ²²⁵⁶−²³²−²⁹−²⁸−²⁷−²⁶−²⁴−1. Satoshi published a 9-page paper entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” White Paper on 31 Oct 31, 2008. In 1997, Adam Black introduce the concept of Proof of Work of Hashcash in a paper entitled, “Hashcash — a denial of service countermeasure.” This work was used by Satoshi in his whitepaper. Satoshi focused on: a decentralized system, and a consensus model and addressed areas of double-spend, Sybil attacks and Eve-in-the-middle. The Sybil attack is where an adversary can take over the general consensus of a network — and leads to a 51% attack, and where the adversary manages to control 51% or more of the consensus infrastructure. Satoshi used UK spelling in his correspondence, such as using the spelling of “honour”. The first Bitcoin block was minted on 3 Jan 2009 and contained a message of “Chancellor on brink of second bailout for banks” (the headline from The Times, as published in London on that day). On 12 Jan 2009, Satoshi sent the first Bitcoin transaction of 50 BTC to Hal Finney [here]. A new block is created every 7–10 minutes on Bitcoin. In Aug 2023, the total Bitcoin blockchain size is 502 GB. As of Aug 2023, the top three cryptocurrencies are Bitcoin, Ether, and Tether. Bitcoin has a capitalization of $512 billion, Ether with $222 billion, and Tether at $83 billion. The total cryptocurrency capitalisation is $1.17 trillion. The original block size was 1MB for Bitcoin, but recently upgraded to support a 1.5MB block — and has around 3,000 transactions. Currently the block sizes are more than 1.7MB. Bitcoin uses a gossip protocol — named the Lightning Protocol — to propagate transactions. A Bitcoin wallet is created from a random seed value. This seed value is then used to create the 256-bit secp256k1 private key. A wallet seed can be converted into a mnemonic format using BIP39, and which uses 12 common words. This is a deterministic key, and which allows the regeneration of the original key in the correct form. BIP39 allows for the conversion of the key to a number of languages, including English, French and Italian. A private key in a wallet is stored in a Wif format, and which is a Base58 version of the 256-bit private key. The main source code for the Bitcoin blockchain is held at https://github.com/bitcoin, and is known as Bitcoin core. This is used to create nodes, store coins, and transactions with other nodes on the Bitcoin network. A 256-bit private key has 115,792 billion billion billion billion billion billion billion billion different keys. A public Bitcoin ID uses Base58 and has a limited character set of ‘123456789ABCDEFGHJKLMN PQRSTUVWXYZabcdefghijkmno pqrstuvwxyz', where we delete ‘0' (zero), ‘l' (lowercase ‘l'), and ‘I' (capital I) — as this can be interpreted as another character. In Bitcoin and Ethereum, a private key (x) is converted to a public key with x.G, and where G is the base point on the secp256k1 curve. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a “04”. A compressed secp256k1 public key only stores the x-co-ordinate value and whether the y coordinate is odd or even. It starts with a “02” if the y-co-ordinate is even, otherwise it starts with a “03”. In 1992, Eric Hughes, Timothy May, and John Gilmore set up the cypherpunk movement and defined, “We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.” In Ethereum, the public key is used as the identity of a user (a.G), and is defined as a hexademical value. In Bitcoin, the public ID is created from a SHA256 hash of the public key, and then a RIPEMD160 of this, and then covered to Base58. In computing the public key in ECC of a.G, we use the Montgomery multiplication method and which was created by Peter Montgomery in 1985, in a paper entitled, “Modular Multiplication without Trial Division.” Elliptic Curve methods use two basic operations: point address (P+G) and point doubling (2.P). These can be combined to provide the scalar operation of a.G. In 1999, Don Johnson Alfred Menezes published a classic paper on “The Elliptic Curve Digital Signature Algorithm (ECDSA)”. It was based on the DSA (Digital Signature Algorithm) — created by David W. Kravitz in a patent which was assigned to the US. The core signature used in Bitcoin and Ethereum is ECDSA (Elliptic Curve Digital Signature Algorithm), and which uses a random nonce for each signature. The nonce value should never repeat or be revealed. Ethereum was first conceived in 2013 by Vitalik Buterin, Gavin Wood, Charles Hoskinson, Anthony Di Iorio and Joseph Lubin. It introduced smaller blocks, an improved proof of work, and smart contracts. Bitcoin is seen as a first-generation blockchain, and Ethereum as a second-generation. These have been followed by third-generation blockchains, such as IOTA, Cardano and Polkadot — and which have improved consensus mechanisms. Bitcoin uses a consensus mechanism which is based on Proof-of-Work, and where miners focus on finding a block hash that has a number of leading “0”s. The difficulty of the mining is defined by the hashing rate. At the current time, this is around 424 million TH/s. There are around 733,000 unique Bitcoin addresses being used. Satoshi defined a reward to miners for finding the required hash. This was initially set at 50 BTC, but was set to half at regular intervals. On 11 January 2021, it dropped from 12.5 BTC to 6.2 BTC. Bitcoin currently consumes around 16.27 GWatts of power each year to produce a consensus — equivalent to the power consumed by a small country. In creating bitcoins, Satoshi created a P2PKH (Pay to Public Key Hash) address. These addresses are used to identify the wallet to be paid and links to the public key of the owner. These addresses start with a ‘1'. In order to support the sending of bitcoins to and from multiple addresses, Bitcoin was upgraded with SegWit (defined in BIP141). The wallet address then integrates the pay-to-witness public key hash (Pay to script hash — P2SH). These addresses start with a ‘3'. Ethereum uses miners to undertake work for changing a state and running a smart contract. They are paid in “gas” or Ether and which relates to the amount of computation conducted. This limits denial of service attacks on the network and focuses developers on creating efficient code. Ethereum supports the creation of cryptocurrency assets with ERC20 tokens — and which are FT (Fungible Tokens). For normal crypto tokens (ERC-20) we use, there is a finite number of these, and each of these is the same. Ethereum creates NFTs (Non-Fungible Tokens) with ERC721 tokens. We mint these each time and each is unique. Solidity is the programming language used in Ethereum, while Hyperledger can use Golang, Node.js and Java. For Ethereum, we compile Solidity code into EVM (Ethereum Virtual Machine) code. This is executed on the blockchain. Blockchain uses the SHA-256 hash for transaction integrity. Ethereum uses the Keccak hash is used to define the integrity of a transaction. This is based on SHA-3, and differs slightly from Keccak. The Keccak hash family uses a sponge function and was created by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, and standardized by NIST in August 2015 as SHA-3. The DAO is a decentralized autonomous organization (DAO) for the Ethereum blockchain and was launched in 2016. In 2016, DAO raised $150 million through a token sale but was hacked and funds were stolen. This resulted in a forking of the blockchain: Ethereum and Ethereum Classic. Non-interactive Zero Knowledge Proofs (NI-ZKP) allow an entity to prove that they have knowledge of something — without revealing it. A typical secret is the ownership of a private key. NI-ZKPs involve a prover (Peggy), a verifier (Victor) and a witness (Wendy) and were first defined by Manuel Blum, Paul Feldman, and Silvio Micali in their paper entitled, “Non-interactive zero-knowledge and its applications”. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge). Bitcoin and Ethereum are pseudo-anonymised, and where the sender and recipient of a transaction, and its value, can be traced. Privacy coins enable anonymous transactions. These include Zcash and Monero. In 1992, David Chaum and Torben Pryds Pedersen published “Wallet databases with observers,” and outlined a method of shielding the details of a monetary transaction. In 1992, Adi Shamir (the “S” in RSA) published a paper on “How to share a secret” in the Communications of the ACM. This supported the splitting of a secret into a number of shares (n) and where a threshold value (t) could be defined for the minimum number of shares that need to be brought back together to reveal the secret. These are known as Shamir Secret Shares (SSS). In 1991, Torbin P Pedersen published a paper entitled “Non-interactive and information-theoretic secure verifiable secret sharing” — and which is now known as Pedersen Commitment. This is where we produce our commitment and then show the message that matches the commitment. Distributed Key Generation (DKG) methods allow a private key to be shared by a number of trusted nodes. These nodes can then sign for a part of the ECDSA signature by producing a partial signature with these shares of the key. Not all blockchains use ECDSA. The IOTA blockchain uses the EdDSA signature, and which uses Curve 25519. This is a more lightweight signature version, and has better support for signature aggregation. It uses Twisted Edwards Curves. The core signing method used in EdDSA is based on the Schnorr signature scheme and which was created by Claus Schnorr in 1989. This was patented as, a “Method for identifying subscribers and for generating and verifying electronic signatures in a data exchange system”. The patent ran out in 2008. Curve 25519 uses the prime number of ²²⁵⁵-19 and was created by Daniel J. Bernstein. Peter Shor defined that elliptic curve methods can be broken with quantum computers. To overcome the cracking of the ECDSA signature from quantum computers, NIST are standardising a number of methods. At present, this focuses on CRYSTALS-Dilithium, and which is a lattice cryptography method. Bulletproofs were created in 2017 by Stanford's Applied Cryptography Group (ACG). They define a zero-knowledge proof as where a value can be checked to see it lies within a given range. The name of “bulletproofs” is defined as they are short, like a bullet, and with bulletproof security assumptions. While Bitcoin can take up to 7–10 minutes to mine a new block and create a consensus, newer blockchains, such as IOTA, can give an almost instantaneous consensus. Banks around the world are investigating CBDC (Central Bank Digital Currency) and which is not a cryptocurrency but a way to quickly define a consensus on a transaction. Homomorphic encryption methods allow for the processing of encrypted values using arithmetic operations. A public key is used to encrypt the data, and which can then be processed using an arithmetic circuit on the encrypted data. The owner of the associated private key can then decrypt the result. Some traditional public key methods enable partial homomorphic encryption. RSA and ElGamal allow for multiplication and division, whilst Pailier allows for homomorphic addition and subtraction. Full homomorphic encryption (FHE) supports all of the arithmetic operations and includes Fan-Vercauteren (FV) and BFV (Brakerski/Fan-Vercauteren) for integer operations and HEAAN (Homomorphic Encryption for Arithmetic of Approximate Numbers) for floating point operations. Most of the Full Homomorphic encryption methods use lattice cryptography. Some blockchain applications use Barreto-Lynn-Scott (BLS) curves which are pairing friendly. They can be used to implement Bilinear groups and which are a triplet of groups (G1, G2 and GT), so that we can implement a function e() such that e(g1^x,g2^y)=gT^{xy}. Pairing-based cryptography is used in ZKPs. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477. An accumulator can be used for zero-knowledge proof of knowledge, such as using a BLS curve to create to add and remove proof of knowledge. Open Zeppelin is an open-source Solidity library that supports a wide range of functions that integrate into smart contracts in Ethereum. This includes AES encryption, Base64 integration and Elliptic Curve operations. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers. Solidity programs can be compiled with Remix at remix.ethereum.org. The main Ethereum network is Ethereum Mainnet. We can test smart contracts on Ethereum test networks. Current networks include sepolia.etherscan.io and goerli.net. Ether can be mined for test applications from a faucet, such as faucet.metamask.io. This normally requires some proof of work to gain the Ether — in order to protect against a Denial of Service against the Faucet. The private key can be revealed from two ECDSA signatures which use the same random nonce value. Polkadot is a blockchain which allows blockchains to exchange messages and perform transactions. The proof of work method of creating is now not preference because of the energy that it typically uses. Many systems now focus on proof of stack (PoS). A time-lock puzzle/Proof of Work involves performing a computing task which has a given cost and which cannot be cheated again. This typically involves continual hashing or continual squaring. The Chia blockchain network uses both Proof of Space (PoS) and Proof of Time (PoT). The PoS method makes use of the under-allocation of hard-disk space. With a Verifiable Delay Function (VDF), we can prove that a given amount of work has been done by a prover (Peggy). A verifier (Victor) can then send the prover a proof value and compute a result which verifies the work has been done, with the verifier not needing to do the work but can still prove the work has been done. A Physical Unclonable Functions (PUFs) is a one-way function which creates a unique signature pattern based on the inherent delays within the wireless and transistors. This can be used to link a device to an NFT. In Blockchain applications, we can use Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) — DLEQ. With this — in discrete logarithms — we have

Kerckhoff's principle defines that “a Cryptographic system should be designed to be secure, even if all its details, except for the key, are publicly known”, but there aren't too many other rules defined. So here are my 100 Basic Rules of Cryptography (and Secure Programming). First, my Top 10: Cryptography is both an art and a science. Cryptography needs to be both theoretical and practical — one without the other leaves gaps. The maths is not actually that difficult — it is just the way that researchers talk about it that is a problem. Know your knowledge gaps — and plug them. Your university education is unlikely to have properly set you up for the serious world of cryptography. Crypto is cryptography and not cryptocurrency. Few methods are perfect — know the limits of any method you use. Don't cook your own crypto! How many times do you have to say this to yourself? Security-by-obfuscation never works that well. Confidentiality, Integrity and Assurance are different things and require different methods. Don't merge them all together into one thing. And the rest: Digital certificates and PKI (Public Key Infrastructure) are two of the least understood areas of cybersecurity — don't expect many people to understand them. For public key encryption, you encrypt with Alice's public key, and she decrypts with her private key. For public key signatures, you sign a hash of the message with your private key, and Alice proves your public key. Your baseline hack is always brute force. Know how many dollars it would cost the NSA to crack something. Machine code can reveal your secrets. A hack of one key should not lead to the loss of all the previous keys. A key should only exist for the time it was meant to exist for. Use session keys wherever possible, and watch out for long-term keys. Your role is typically to protect the user and not reveal things to the NSA. Listen to experts, and be a teacher to others. Be open with your knowledge, and don't pretend you know something that you don't. Try and understand the basics of the maths involved — otherwise, you are trusting others. Understand entropy, and know how to calculate it and prove it with experiments. Run entropy calculations before pushing related code to production. Don't use a method unless it has been peer-reviewed and published. Understand the strengths and weaknesses of your methods. No method is perfect —but at least know what problems it might cause and try and mitigate against these. Know why you have chosen X over Y, and be able to defend the reason to others. The maths may be sound, but human is typically the main weakness. Everything will work fine until it doesn't. Test for out-of-band conditions as much for good conditions. Zero is not your friend in cryptography, so always know what it will do to your system. Don't just catch exceptions; action them. Do not allow to progress unless everything checks out okay. Log good and bad. Catch good things, along with bad things. Monitor your security logs for exceptions and bad operations. Remove debugging code from your production version. Keep up to date with the latest research. Beware of backdoors in methods and code. Side channels are smart ways to reveal the 1s and 0s, and every bit discovered reduces the security level by two and makes it so much less expensive to crack. Every bit drops the price tag for a crack by a half. The core security of your system is likely to depend on the generation of random oracles (seed values). Make sure they are generated so they do not repeat within a given time and cannot be brute forced by the NSA. If you can use real randomisation and not pseudo-randomness. If you generate pseudo-randomness, take the randomness from several sources. Continually review your code, and get external experts to review it. Don't push your code in production until you have tested it — fully! Check the code in the libraries you use, and perhaps, don't use them if there are no open-source repositories. If you can, open source your libraries. Watch out for version updates on your code, and try and lock a given (known) version to your code. Encrypt anything that looks like PII (Personally Identifiable Information) at rest and over the air. Remember that running memory can reveal keys and cryptographic artefacts, so know the risk. Learn a new method every day, and don't get stuck with the same old crypto! Quantum computers will happen one day and will disrupt our life, so start thinking about the impact they might have. Revealing your private keys is like giving someone the keys to your castle, so know where they are and restrict access to them. Only give access to private keys to those you most trust to use them properly. Air your development environment from your production environment, and don't let private keys propagate. The best systems use zero trust. No rights to anything unless they can be proven. You will — at times — need to revoke your public keys. Be aware of the processes involved and of the embarrassment it will cause. Educate the board on the importance of good crypto! Encourage your team to undertake academic study, and get them to reserve a few hours a week for independent study of new methods. Read classic research papers, and don't dismiss methods because they are not currently used. Collaborate with an academic team which has complementary skills to your own team. If you lack theoretical knowledge in your team, get external experts to come in for a chat. Once a private key is destroyed, any data encrypted with it is also likely to be destroyed. Limit the copies of a secret key. If you can, keep your keys in an HSM (Hardware Security Module). Cryptography in the Cloud pushes you to the limits and will often enhance the methods you use. Back up those secret keys, but make sure they are well-wrapped before putting them in a place that others can access. Learn about the garbage collector and how your program deals with data when running. Leave the coding of the maths in papers to experts. Don't trust auditors to prove the security of your system. Generally, auditors are likely to have little understanding of the methods you will use — get experts to review your methods. Beware of Denial of Service (DoS) on your code — such as continual exception handling. Most systems boil down to one single thing that defines the overall security — know what this is. If you are interested in the X method, go and contact the person that created it — you will often be surprised how open many researchers are in sharing their ideas. Watch those CVE updates like a hawk — it can be a race between you and your adversary. On Cloud-based systems, log everything about your keys. In the Cloud, only allow keys to be used for the purpose they should be used for, and don't use them generally. Limit access to keys for services and roles. Reduce the impact of a stolen or lost secret key. Never encrypt large-scale data infrastructures with the same secret key — try to use envelope encryption. Passwords are dead — replace with cryptographic signing methods. Your enemy can be within. Watch out for key stealing and deletion. Tell your incident response team about the difference between losing encrypted data and non-encrypted data. Scan your network for secret keys placed in locations where they should not be stored. Know what the acronyms mean and not just what they stand for. Know why we use message authentication codes (MACs). If you need to generate an encryption key from a password or secret, pick a good KDF (Key Derivation Function), and know the cost to crack it. Rainbow tables aren't much of a threat anymore, so make use your use a good salt value. Everything below 72 bits of entropy is likely to be crackable by the NSA — unless a slow method is used for the processing with the key. Nonce/salt values should start at 96 bits. Never use anything less. RC4 has been cracked … get over it. Stream ciphers can often be broken — make sure you never reuse your salt value. DES and 3DES are mainly uncracked, but DES only uses a 56-bit key, so never use it Compared with ECC, RSA requires a good deal more processing and has larger key sizes, but it is still great. ECDSA suffers from nonce reuse attacks. For digital signatures, you should delete the nonce value after the signature has been created, but for symmetric key and hashing, you need to store it. In ECC, the public key is a point on the elliptic curve. For secp256k1, we have a 256-bit private key and a 512-bit (x,y) point for the public key. A “04” in the public key is an uncompressed public key, and “02” and “03” are compressed versions with only the x-co-ordinate and whether the y coordinate is odd or even. Consider writing papers — it is a great way to develop your writing and abstraction skills. Don't sit back with the status quo — try to continually improve privacy and security. Have a risk register and maintain it. Don't be shy, and don't hide things. Have someone to check your code — on a regular basis. Remember Moore's Law … computing power is increasing every year, so know that something that is safe now might not be in 10 years. Know how long something needs to be kept secure and secure for that age (and a lot more). And there you go … 100 rules of cryptography

Digital signatures are the foundation of our digital trust. With this, Bob has a key pair: a private key and a public key. In order to provide his identity, he signs a hash of a message with his private key, and then Alice proves this with his public key. Currently, we mainly use RSA, ECDSA and EdDSA for our signature methods, and where DSA signatures (which use discrete logs) have been dropped for their creation. For example, ECDSA is used with Bitcoin and Ethereum, and RSA is often used to identify Web sites. EdDSA is now on the rise, and is part of the FIPS-186–5 standard. Unforunately, we will need to replace these methods — as quantum computers can crack them. The other area that needs to be replaced is key exchange and public key encryption. These days we typically use ECDH (Elliptic Curve Diffie Hellman) for key exchange, and RSA for public key encryption. These will have to be replaced with quantum-robust methods — Post Quantum Cryptography (PQC). Goodbye RSA and ECC, and Hello to PQC And, so, using Shor's algorithm, quantum computers will be able to crack RSA, discrete logs and ECC (Elliptic Curve Cryptography), and so we need to remove RSA, ECDSA and EdDSA and replace them with methods that are quantum robust. For this, NIST has been running a competition for the last few years, and where CRYSTALS-Dilithium and SPHINCS+ were selected as the winners for PQC digital signatures. There are no other candidates that are being assessed from the previous round. Overall, Dilithium is a lattice-based method, while SPHINCS+ uses a hash-based signature method. But what if these methods are cracked? Well, it happened to two of the finalists for the NIST competition: Rainbow and SIKE, and where the methods were cracked in the final round of the competition. For KEM (Key Exchange Mechanisms) to replace ECDH (Elliptic Curve Diffie Hellman) and Public Key Encryption (PKE) to replace RSA, NIST has standardized CRYSTALS-Kyber, and is still assessing BIKE, Classic McEliece, HQC, and SIKE. Additional Signatures: Round 1 And, so, NIST is on the look-out for alternatives for Dilithium and has set up a new competition [here]: In the first round, we have: Code-based Signatures: CROSS (Codes and Restricted Objects Signature Scheme); Enhanced pqsigRM; FuLeeca; LESS (Linear Equivalence Signature Scheme) and MEDS (Matrix Equivalence Digital Signature Wave). Isogenies: SQIsign. Lattice based: EagleSign; EHTv3 and EHTv4; HAETAE; HAWK; HuFu (Hash-and-Sign Signatures From Powerful Gadgets); Raccoon; and SQUIRRELS (Square Unstructured Integer Euclidean Lattice Signature). MPC in the head: MIRA; MiRitH (MinRank in the Head); MQOM (MQ on my Mind); PERK; RYDE; and SDitH (Syndrome Decoding in the Head). Multivariate Signatures (Oil and Vinegar): 3WISE; Biscuit; DME-Sign; HPPC (Hidden Product of Polynomial Composition); MAYO; PROV (PRovable unbalanced Oil and Vinegar); QR-UOV; SNOVA; TUOV (Triangular Unbalanced Oil and Vinegar); UOV (Unbalanced Oil and Vinegar); and VOX. Symmetric-based Signatures: AIMer; Ascon-Sign; FAEST; and SPHINCS-alpha. Doing a quick count, we have: Multivariate: 11; Lattice: 7; Code-based: 5; MPC-in-the-head: 5; Symmetric-based: 4; and Isogenies: 1. So, multivariate seems to be leading the way, with lattice methods being popular too. But poor old isogenies only has one contender. This may be due to the crack on an isogeny-based method (Supersingular Isogeny Key Encapsulation SIKE), or that isogenies are better suited to key exchange techniques. And so, let's look at the basic methods and some previous examples. Multivariate — Unbalanced Oil and Vinegar (UOV) With multivariate cryptography, we have n variables within polynomial equations. For example, if we have four variables (w,x,y,z) and an order of two, we could have [here]: w²+4wx+3x²+2wy−4wz+2wx+6xz=387 Generally, this is a hard problem to solve, so we want to make it easy if we know a secret. In this case, I know that the solution is w=7,x=4,y=5, and z=6. Oil and Vinegar Makes A Hard Problem Easy Fixing The Hole In The Internet in a Post Quantum World medium.com   Lattice To understand lattice cryptography, you need to understand polynomials, as our bit values are converted into polynomials. Our operations are then conducted with polynomial multiplies and addition, and taken with a (mod p) operation (and where p will be the maximum value we generate for the polynomial values). The Magic of Lattice and The Eye of a Falcon To understand lattice cryptography, you need to understand polynomials, as our bit values are converted into… medium.com   Code-based This method was created in 1978 with the McEliece cryptosystem but has barely been used in real applications. The McEliece method uses linear codes that are used in error-correcting codes and involves matrix-vector multiplication. An example of a linear code is Hamming code [here]. McEliece and Rust: Edging Slowly To A NIST Standard for PQC We live in a world that is dominated by large (and faceless) corporations, but it is individuals who have often built… medium.com   MPC-in-the-head These methods use non-interactive zero-knowledge proofs of knowledge and MPC (Multiparty Computation). With MPC we can split a problem into a number of computing elements, and these can be worked on in order to produce the result, and where none of the elements can see the working out at intermediate stages. The great advantage of this method is that we only use symmetric key methods (block ciphers and hashing functions). Let's Go For A Post-Quantum Picnic And then there were three: CRYSTALS Dilithium, Falcon and Rainbow. These are the finalists for the NIST standard for… medium.com   Symmetric These methods uses standard cryptographic methods such as symmetric key encryption and hashes. Typically they use AES and SHA3 — and which are quantum robust. Isogenies If we have two elliptic curves (E1 and E2), we can create a function that maps a point (P) on E1 to a point Q on E2. This function is known as an isogeny. If we can map this function, every point on E1 can be mapped to E2. Our secret key is then the isogeny and the public key is the elliptic curve. For key exchange, Bob and Alice mix their isogeny and the other side's curve to generate a secret curve. Isogenies? The End Game for Public Key Encryption? Well, we are now at the final stage of NIST's post-quantum cryptography standardization, and which started in 2016: medium.com   Conclusions Exciting times are ahead as the methods go up and against each. In the last competition, some of the methods fell because of a problem with their parameters (Rainbow — UOV) or because of a core weakness (isogenies). But, this time, they are all likely to come back strong and (hopefully) compete well against the lattice methods.

Blog: https://medium.com/asecuritysite-when-bob-met-alice/a-bluffers-guide-to-symmetric-key-encryption-modes-f7882881f6d Symmetric key encryption involves a single key to encrypt and decrypt and where Bob and Alice can use the same encryption key. The two most popular symmetric key methods are AES — Advanced Encryption Standard — and ChaCha20. Along with this, we either have a block cipher or a stream cipher. With a block cipher, we process a number of bytes at a time with our ciphering process. With AES, we have a 128-bit block size, and thus process 16 bytes for each block. For a stream cipher, we generate a pseudo infinitely long key stream from a passphrase or random value, and then just XOR this with the plaintext. The size of the key stream is match to the number of bytes in the plaintext. To decrypt, we just generate the same key stream, and XOR it with the ciphertext to recover the plaintext. I am often surprised by how little care many companies have in their encryption process and do not review the fundamental weaknesses of using symmetric key encryption. For many, it is a tick-box approach, where an auditor just asks if they are using encryption or not. It should not be, and there are many weaknesses that need to be taken into account. So, here's the bluffer's guide to modes in AES: ECB (Electronic Code Book). This is the fastest mode and should NEVER be used, as there is no salt (IV) used in the ciphering process. This mode is only used for academic purposes to show what can go wrong if salt is not added to the encryption process. With this, the ciphertext will always be the same for the same plaintext, and it is possible to easily crack by looking at patterns in the data. All of the other modes have a salt (IV or nonce) value: CTR (Counter). This is an excellent mode which has a counter for each block, and then converts to a stream cipher. It is nearly as fast as ECB, and can be processed in parallel. It can be played back in a different session and can have little in the way to integrity check, and where Eve can flip bits and change the plaintext from the ciphertext. We need all the ciphertext before we can use the plaintext. A demo of breaking CTR is: https://billatnapier.medium.com/can-i-break-aes-encryption-yes-31bdf539aba0 GCM (Galois/Counter Mode). This is almost the same as CTR and is a stream cipher, but slower than CTR (but still relatively fast overall. It has the advantage of adding additional data, such as for a session ID, and thus protects against playback. GCM (Galois/Counter Mode). The main change from CTR is to add a MAC, and so the bit-flipping method would be near impossible to implement. This mode implements AEAD (Authenticated Encryption with Additional Data), and is useful in defending against playback attacks. It can suffer from nonce reuse, though. CBC (Cipher Block Chain). This is a block mode which thus requires padding before encryption and after decryption. While achieving the same speeds as ECB for a small amount of data, it slows down with larger amounts — because of the block-chaining process. It is seen to be a little cumbersome and has a few issues with security. CCM (counter with cipher block chaining message authentication code; counter with CBC-MAC). This is a stream cipher mode and has a similar performance to CBC. It integrates better integrity checks with a MAC (message authentication code). ChaCha20. It is not AES — which can be a good thing. Along with this, it is a stream cipher (and so fast in its operation). It is typically not as fast at CTR and GCM, but faster than CBC. Overall, AES tends to be accelerated for its processing on x64/x86 chips, but not for ChaCha20. As with AES GCM mode, ChaCha20 implements AEAD (Authenticated Encryption with Additional Data) and is useful in defending against playback attacks. There are other modes, such as OFB (Output Feedback) and CFB (Cipher Feedback), but these are not used that much. For this in the finance industry, you might also be using 3DES, and which has not been broken, but is much slower than AES and ChaCha20. Here are some performance tests [here]: Generally, the stream ciphers can struggle against nonce reuse, and if the same nonce is used, it can be possible to break AES by XOR'ing cipher streams. And to show the breaking of the integrity of AES: Can You Trust AES Encryption? In this article, I will not break the AES method (as it has yet to be broken), but breach its integrity. This is… billatnapier.medium.com   But, it's NIST defined! There is no guarantee that because NIST defines something as a standard that it will be secure, as it all depends on the implementation. ECDSA and EdDSA are NIST standards but have been easily broken in the past with poor implementations. We have seen that CTR mode is weak against bit-flipping, and where GCM creates a MAC to defend against this. While it is nearly impossible to flip the bits of the cipher and of the MAC, and for them to tie-up, it is certainly possible to recreate a valid MAC and replace it, when a nonce is reused. So, companies who take security seriously should understand their risks, and test accordingly. Those involved in areas of high risk, such as dealing with financial data and PII, should understand the risks in the methods they implement and not just tick a box to say that they have encrypted the data. I have seen many examples of companies ploughing on with the same old encryption methods — even though they have significant weaknesses.

Blog: https://billatnapier.medium.com/cryptography-fundamentals-elgamal-encryption-and-signature-2de5f16b1127  ElGamal methods: https://asecuritysite.com/elgamal  Introduction In research, we build on the shoulders of giants, and Taher Elgamal is one of the giants of cybersecurity. His work on Netscape led to the creation of SSL, and for which much of our Web security is still built on. Along with this, he published this paper in 1985 [here]: It was true classic, and has been reference over 12,500 times. Within the paper, Tahir outlined an encryption methods and a digital signature method. His ‘base' was to take John Napier's logarithm, and make them discrete. This discrete element meant that we only dealt with positive integer values, and where we worked within a finite field. This field was defined by a prime number (p). While the core ElGamal encryption method was overtaken in its usage by RSA, and then by ECC (Elliptic Curve Cryptography), the signature method was adopted as the Digital Signature Standard (DSS) by NIST. This has since scaled into ECC to become ECDSA, and which is used by Bitcoin and Ethereum. Tahir studied electrical engineering in the late 1970s at Stanford University. It was there he met Marty Hellman and who helped him spark an interesting in cryptography. He received his PhD in 1984 and it was Marty introduced him to Paul Kocker at Netscape Communications. Together, Paul and Tahir worked on a method to implement end-to-end encryption, and published SSL 3.0 in November 1996: Examples are at: https://asecuritysite.com/elgamal The ElGamal Method Befre we start we need to look at some of the basics of logarithms and where: {g^a}^b is g^{ab} and: g^a . g^b = g^{a+b} To make these discrete to add (mod p) in our operations and where p is a prime number. This constrains our integrates with a finite field, between 0 and p-1. In the ElGamal method, Initially, Bob creates his public key by selecting a g value and a prime number (p) and then selecting a private key (x). He then computes Y which is: Y=g^x (mod p) His public key is (Y,g,p) and he will send this to Alice. Alice then creates a message (M) and selects a random value (k). She then computes a and b: a=g^k (mod p) b=y^k.M (mod p) Bob then receives these (a and b), and then uses his private key (x) to decrypt the values and discover the message: M=b/(a^x) (mod p) With the divide by (a^x) we basically take the inverse of (a^x) mod p, and then multiply. The operation works because: ElGamal and Signatures With ElGamal signing, Alice has a public key (y,g,p) and a private key of a. She then takes a message m and creates a signature (r,s). This signature can then be checked by Bob.  With ElGamal, Alice selects a generator (g), prime number of p and a private key of a. Her public key is then (y,g,p) and where y is: y=g^a (modp) To sign a message (m) we generate a secret random number (k) and we must make sure: gcd(k,p−1)=1 Next we compute: r=g^k (mod p) Next we compute: k^{−1} (mod p−1) and then: s=k^{−1}(h(m)−ar) (modp−1) The signature is then (r,s). Bob verifies the signature by computing two values: v1=y^r.r^s (mod p) and: v2=g^{h(m)} (mod p) If v1 is equal to v2 the signature has been verified. The proof is given here: https://asecuritysite.com/elgamal/el_sig2 While, ElGamal signing is not used these days, its method were applied into the Digital Signature Algorithm (DSA), and which was since been coverted into the Elliptic Curve Digital Signature Algorithm (ECDSA) method. Converting from discrete logs to elliptic curves In discrete logs we convert from: Y=g^a (mod p) to Y=a.G and where we have a exponential for discrete logs we have: Y = {g^a}^ b is equivalent to: Y=a.b.G and for a multiplication we have Y=g^a.g^b (mod p) = g^{a+b} (mod p) In elliptic curves we convert the multiplication to a point addition: Y = a.G + b.G = (a+b) G Converting from John Napier's Logarithms to Elliptic Curve Methods Around ten years ago, discrete log and RSA methods were riding right. But both of these methods have struggled with…medium.com This exponential becomes point multiplication, and multiply/division becomes point addition/subtraction. ElGamal and ECC But, Elliptic Curve Cryptography (ECC) methods are just everywhere just now. With ECC, we take points on a defined curve — such as Curve 25519 — and then perform point addition and subtraction. So how can we convert the ElGamal method into ECC? First, Alice first creates a private key (a) — and which is a random scalar value — and a public key (aP) — and which is a point on the elliptic curve. P is the base point on a curve. Alice's public key will then be: A=aP If Bob wants to send Alice an encrypted message (M), he creates a random value (k) and uses her public key (A) to produce a cipher message of: K=kP and then the next with: C=kA+M and where M is matched to a point on the elliptic curve. Now Alice receives (K) and (C), and computes: S=aK and then computes the message with: M=C−S As C and S will be points on the elliptic curve, this will be done with a point subtraction operation. Overall this will recover the original message as: C−S=kA+M−aK=kaP+M−akP=M The following is come Go code to implement this [taken from here]: package mainimport ( "fmt" "os" "go.dedis.ch/kyber" "go.dedis.ch/kyber/group/edwards25519" "go.dedis.ch/kyber/util/random")func ElEncrypt(group kyber.Group, pubkey kyber.Point, message []byte) ( K, C kyber.Point, remainder []byte) { // Embed the message (or as much of it as will fit) into a curve point. M := group.Point().Embed(message, random.New()) fmt.Printf("Message point:t%sn" , M.String()) max := group.Point().EmbedLen() if max > len(message) { max = len(message) } remainder = message[max:] // ElGamal-encrypt the point to produce ciphertext (K,C). k := group.Scalar().Pick(random.New()) // ephemeral private key K = group.Point().Mul(k, nil) // ephemeral DH public key S := group.Point().Mul(k, pubkey) // ephemeral DH shared secret C = S.Add(S, M) // message blinded with secret return}func ElDencrypt(group kyber.Group, prikey kyber.Scalar, K, C kyber.Point) ( message []byte, err error) { // ElGamal-decrypt the ciphertext (K,C) to reproduce the message. S := group.Point().Mul(prikey, K) // regenerate shared secret M := group.Point().Sub(C, S) // use to un-blind the message message, err = M.Data() // extract the embedded data return}func main() { M:="Testing" argCount := len(os.Args[1:]) if (argCount>0) {M= string(os.Args[1])} suite := edwards25519.NewBlakeSHA256Ed25519() // Alice's key pair (a,A) a := suite.Scalar().Pick(suite.RandomStream()) A := suite.Point().Mul(a, nil) fmt.Printf("Private key (Alice):t%sn" ,a.String()) fmt.Printf("Public key (Alice):t%sn" , A.String()) fmt.Printf("nn--- Now Bob will cipher the message for Alicen") fmt.Printf("Bob's message:t%sn",M) m := []byte(M) K, C, _ := ElEncrypt(suite, A, m) fmt.Printf("nBob cipher (K):t%sn" , K.String()) fmt.Printf("Bob cipher (C):t%sn" , C.String()) fmt.Printf("nn--- Now Alice will decipher the ciphertext (K,C) with her private key (a)n") M_decrypted, err := ElDencrypt(suite, a, K, C) if err != nil { fmt.Println("Error: " + err.Error()) } fmt.Printf("nOutput:t%s",string(M_decrypted))} A sample run is: Private key (Alice): 7182fa86214b1672f36113d139b2f84ca6acbbf1dbe2202e2ad99665e4fdac00Public key (Alice): 31dfde321f1f56228feeacaeff9550c3d489ee5fd3e4e9d2e48fd41cfd9f09f6--- Now Bob will cipher the message for AliceBob's message: Testing 123Message point: 0b54657374696e6720313233aca5a2888970256a3bb93cde2898f95fcdfd96efBob cipher (K): c794b9c278298dc3abd64b0e3af62a2f7390c6c51c13a491930dea6b2dbc6ce4Bob cipher (C): 27ac77843effff5b723abe990e7175ba0c7659da0f5aec98421f0a89b78f2d82--- Now Alice will decipher the ciphertext (K,C) with her private key (a)Output: Testing 123 And there you go, ElGamal using ECC: https://asecuritysite.com/elgamal/go_elgamal_ecc Partical Homomorphic Encryption with ElGamal With ElGamal public key encryption we have a public key of (Y,g,p) and a private key of (x). The cipher has two elements (a and b). With this, Bob selects a private key of x and the calculates Y= g^x (modp) for his public key. We can use it for partial homomorphic encryption, and where we can multiply the ciphered values. With this we encrypt two integers, and then multiply the ciphered values, and then decrypt the result. https://asecuritysite.com/homomorphic/go_el_homo https://asecuritysite.com/elgamal/elgamal_ps2 g^a . g^b = g^{a+b} Other applications There are many other applications of the ElGamal method, including Authenticated Encryption and in Zero Knowledge Proofs. The days of using discrete logarithms are past, and most of the implementations use elliptic curve methods now. And, so, unlike many others, Tahir did not patent his method, and this allowed others to use it freely. 

Related blog: https://medium.com/asecuritysite-when-bob-met-alice/tokens-jwt-and-google-tink-c6b915d387e8 And: https://billatnapier.medium.com/hmac-or-public-key-signing-of-jwts-64084aff10ef  Introduction My Top 20 important things about JWTs: JWT is a JSON Web Token and is pronounced “jot”. JSON objects support human-readable text and are used in many applications, such as with NoSQL databases. You should not trust a JWT unless it is cryptographically signed. For authorization, a captured JWT can be replayed and “played back” to provide a malicious entry or rights into a system. JWTs should never be trusted before their issue date and their not-before date and never trusted after their expiry. JWTs have been defined as an RFC standard with RFC7519. The format is URL friendly and is Base64URL encoded. A JWT token has three main parameters separated by a period (“.”), and which are the header, the payload and the signature. The header is typically not encrypted and defines the signature algorithm (“alg”) and the type (“typ”). The payload is typically not encrypted and uses a Base64 format. The payload can typically be seen by anyone who captures it. “ey” is a typical field starting part of a parameter in the header and body of a token as ‘{“‘ encoded in Base64 is “ey==”. You can tell if a token is not encrypted with an “ey” as the start of the header and body parameters. The registered claims of a token are iss (Issuer), sub (Subject), aud (Audience), iat (Issued At), exp (Expires), nbf (Not Before), and jti (JWT ID). The claim fields are not mandatory and just a starting point for defining claims. A claim is asserted about a subject, and where we have a claim name and a claim value in a JSON format. With an HMAC signature, the issuer and validator must share the same secret symmetric key. If you use HMAC to sign the tokens, a breached secret key will compromise the signing infrastructure. The two main public key signing methods are RSA and ECDSA. The time of a token is represented as the number of seconds from 1 January 1970 (UTC). Each day of a JWT token is represented by 86,400 seconds. An unsecured JWT does not have encryption or a signature. This is bad! it is represented in the header parameter with an “alg” of “none” and an empty string for the JWS Signature value. A JWT can be encrypted (but this is optional). For public key methods, we can use either RSA and AES, or we can use a wrapped key. And a debate I've had with many development teams: What's a token? So, what's a token? Well, it is basically a way to encapsulate data in a well-defined format that has a signature from the issuer. For this, we either sign using HMAC (HMAC-256, HMAC-384 or HMAC-512), RSA signing or ECC signing. The HMAC method requires the use of a secret symmetric key, whilst RSA and ECC use public key encryption. The problem with HMAC is that if someone discovers the secret key, they could sign valid tokens. For enhanced security, we typically use public key encryption, where we sign with a private key and then validate with the public key. In this case, we will use Google Tink to create JWTs (JSON Web Tokens) and which are signed with elliptic curve cryptography. For this, we will use either NIST P-256 (ES256), NIST P-384 (ES384) or NIST P512 (ES512) for the curves. Overall, we do not generally encrypt the payload in JWT, so it can typically be viewed if the token is captured. JWT format A JWT token splits into three files: header, payload and signature (Figure 1). Figure 1: JWT format The header parameter The header contains the formation required to interpret the rest of the token. Typical fields are “alg” and “kid”, and these represent the algorithm you use (such as “ES256”) and the ID, representively. The default type (“type”) will be “JWT”. Other possible fields include “jwk” (JSON Web key), “cty” (Content type), and “x5u” (X.509 URL). An example header for a token that uses ES384 signatures and with an ID of “s5qe-Q” is: {"alg":"ES384", "kid":"s5qe-Q"} The payload parameter The payload is defined in JSON format with a key-pair setting. For a token, we have standard claim fields of iss (Issuer), sub (Subject), aud (Audience), iat (Issued At), exp (Expires At), nbf (Not Before), and jti (JWT ID). The claim fields are not mandatory and are just a starting point — and where a developer can add any field that they want. An example field is: {"aud":"qwerty", "exp":1690754794, "iss":"ASecuritySite", "jti":"123456", "sub":"hello"} The time is defined in the number of seconds past 1 January 1970 UTC. In this case, 1690754794 represents Sunday 30 Jun 22:06:34: The token signing parameter There are two ways to sign a token: with an HMAC signature or with a public key signature. With HMAC, we create a shared symmetric key between the issuer and the validator. For public key encryption, we use either RSA or ECDSA. For these, we create a signature by signing the data in the token with the private key of the creator of the token, and then the client can prove this with the associated public key. For public key signing, the main signing methods are: ES256. ECDSA using NIST P256 with SHA-256. ES384. ECDSA using NIST P384 with SHA-384. ES512. ECDSA using NIST P512 with SHA-512. RS256. RSASSA-PKCS1-v1_5 with the SHA-256 hash. and for HMAC: HS256. HMAC with SHA-256. HS384. HMAC with SHA-384. HS512. HMAC with SHA-512. In public key signing, we have a key pair to sign the token: And with HMAC, we share a secret signing key: Encrypting the payload A JWT can be encrypted, but this is optional. For public key methods, we can use either RSA and AES or a wrapped AES key. An “alg” method of “RSA1_5” will use 2,048-bit RSA encryption with RSAES-PKCS1-v1_5, “A128KW” will use 128-bit Key Wapping and “A256KW” uses 256-bit Key Wapping. With key wrapping, the private key is encrypted with a secret key. Both the issuer and verifier will know this secrete key. For symmetric key methods, we can use “A128CBC-HS256” (AES-CBC) and “A256CBC-HS512” (HMAC SHA-2). It is possible to also use ECDH-ES (Elliptic Curve Static) for key exchange methods An example token An example token is: eyJhbGciOiJFUzI1NiIsICJraWQiOiJ3WHd6dVEifQ.eyJhdWQiOiJxd2VydHkiLCAiZXhwIjoxNjkwNzU0Nzk0LCAiaXNzIjoiQVNlY3VyaXR5U2l0ZSIsICJqdGkiOiIxMjM0NTYiLCAic3ViIjoiaGVsbG8ifQ.cAXunJHLRrqFfJStJTFlwkUTze6K8EpwOui9abDeiSBcR5WeOEpXCSUQBnS_VdVnLsmVV2AWUX0kOTqIWERcMQ We then have: Header: eyJhbGciOiJFUzI1NiIsICJraWQiOiJ3WHd6dVEifQ Payload: eyJhdWQiOiJxd2VydHkiLCAiZXhwIjoxNjkwNzU0Nzk0LCAiaXNzIjoiQVNlY3VyaXR5U2l0ZSIsICJqdGkiOiIxMjM0NTYiLCAic3ViIjoiaGVsbG8ifQ Signature: cAXunJHLRrqFfJStJTFlwkUTze6K8EpwOui9abDeiSBcR5WeOEpXCSUQBnS_VdVnLsmVV2AWUX0kOTqIWERcMQ These are in Base64 format, and we can easily decode the header as: {"alg":"ES256", "kid":"wXwzuQ"} and the payload as: {"aud":"qwerty", "exp":1690754794, "iss":"ASecuritySite", "jti":"123456", "sub":"hello"} The signature value will be in a byte array format. Sample code With Google Tink, we can create a token with the fields using: expiresAt := time.Now().Add(time.Hour) subject:= "CSN09112" audience := "Sales" issurer := "ASecuritySite" jwtid := "123456" rawJWT, _ := jwt.NewRawJWT(&jwt.RawJWTOptions{ Subject: &subject, Audience: &audience, Issuer: &issurer, ExpiresAt: &expiresAt, JWTID: &jwtid, }) Next we will generate an ECC private key using either NIST P256, NIST P-384 or NIST P-512. In the following, we create a private key (priv) and which will be used to sign the token: priv,_ =keyset.NewHandle(jwt.ES256Template()signer, _ := jwt.NewSigner(priv)token, _ := signer.SignAndEncode(rawJWT) We can then create the public key from the private key, and validate the token with this key: pub, _:= priv.Public()verifier, _ := jwt.NewVerifier(pub) The full code is [here]: package mainimport ( "fmt" "time" "os" "strconv" "github.com/google/tink/go/jwt" "github.com/google/tink/go/keyset" "github.com/google/tink/go/insecurecleartextkeyset")func main () { priv, _ := keyset.NewHandle(jwt.ES256Template()) expiresAt := time.Now().Add(time.Hour) subject:= "CSN09112" audience := "Sales" issurer := "ASecuritySite" jwtid := "123456" t:=0 argCount := len(os.Args[1:]) if (argCount>0) {subject= string(os.Args[1])} if (argCount>1) {audience= string(os.Args[2])} if (argCount>2) {issurer= string(os.Args[3])} if (argCount>3) {jwtid= string(os.Args[4])} if (argCount>4) {t,_ = strconv.Atoi(os.Args[5])} switch t { case 1: priv,_ =keyset.NewHandle(jwt.ES256Template()) case 2: priv,_ =keyset.NewHandle(jwt.ES384Template()) case 3: priv,_ =keyset.NewHandle(jwt.ES512Template()) } pub, _:= priv.Public() rawJWT, _ := jwt.NewRawJWT(&jwt.RawJWTOptions{ Subject: &subject, Audience: &audience, Issuer: &issurer, ExpiresAt: &expiresAt, JWTID: &jwtid, }) signer, _ := jwt.NewSigner(priv) token, _ := signer.SignAndEncode(rawJWT) verifier, _ := jwt.NewVerifier(pub) validator, _ := jwt.NewValidator(&jwt.ValidatorOpts{ExpectedAudience: &audience,ExpectedIssuer: &issurer}) verifiedJWT, _:= verifier.VerifyAndDecode(token, validator) id,_:=verifiedJWT.JWTID() sub,_:=verifiedJWT.Subject() aud,_:=verifiedJWT.Audiences() iss,_:=verifiedJWT.Issuer() at,_:=verifiedJWT.IssuedAt() ex,_:=verifiedJWT.ExpiresAt() fmt.Printf("Public key:t%sn",priv) fmt.Printf("Public key:t%snn",pub) fmt.Printf("Token:t%snn",token) fmt.Printf("Subject:t%sn",sub) fmt.Printf("Audience:t%sn",aud) fmt.Printf("Issuer:tt%sn",iss) fmt.Printf("JWT ID:tt%sn",id) fmt.Printf("Issued at:t%sn",at) fmt.Printf("Expire at:t%sn",ex) fmt.Printf("nnAdditional key datan") exportedPriv := &keyset.MemReaderWriter{} insecurecleartextkeyset.Write(priv, exportedPriv) fmt.Printf("Private key: %snn", exportedPriv) exportedPub := &keyset.MemReaderWriter{} insecurecleartextkeyset.Write(pub, exportedPub) fmt.Printf("Public key: %snn", exportedPub)} A sample run proves the process [here]: Public key: primary_key_id:1926408156 key_info:{type_url:"type.googleapis.com/google.crypto.tink.JwtEcdsaPrivateKey" status:ENABLED key_id:1926408156 output_prefix_type:TINK}Public key: primary_key_id:1926408156 key_info:{type_url:"type.googleapis.com/google.crypto.tink.JwtEcdsaPublicKey" status:ENABLED key_id:1926408156 output_prefix_type:TINK}Token: eyJhbGciOiJFUzI1NiIsICJraWQiOiJjdEtuM0EifQ.eyJhdWQiOiJxd2VydHkiLCAiZXhwIjoxNjkwNzUxNTI0LCAiaXNzIjoiQVNlY3VyaXR5U2l0ZSIsICJqdGkiOiIxMjM0NTYiLCAic3ViIjoiaGVsbG8ifQ.qfui2u9hBpEgiQQeeWNJtSanyl4rbYkViIZJxVmBvCsP72ovcT20qC35YbQOh7Q8cCqA37Fk8OXWSQ-geg6E-QSubject: helloAudience: [qwerty]Issuer: ASecuritySiteJWT ID: 123456Issued at: 0001-01-01 00:00:00 +0000 UTCExpire at: 2023-07-30 21:12:04 +0000 GMTAdditional key dataPrivate key: .{primary_key_id:1926408156 key:{key_data:{type_url:"type.googleapis.com/google.crypto.tink.JwtEcdsaPrivateKey" value:"x12Fx10x01x1a xcdPtIx03)xb0xf7H9'x1ex94txaaax99xf8ڍvxcfxd6|x1ax1aV6H!xdax00" xc2Ï¥xfaDx16xb2xfaxd7x00xfexbaxe4xf3xed%x03x9a^x1dx9fx93_xf3x1fxd9Wx90x8aâXx1a pxf7,_}x13xffx84x9cxc6jxdaͯxc7x1b.xb2|x19ØŽxfbxa9jx05xb3NFxc4x7fxcc" key_material_type:ASYMMETRIC_PRIVATE} status:ENABLED key_id:1926408156 output_prefix_type:TINK} .nil.}Public key: .{primary_key_id:1926408156 key:{key_data:{type_url:"type.googleapis.com/google.crypto.tink.JwtEcdsaPublicKey" value:"x10x01x1a xcdPtIx03)xb0xf7H9'x1ex94txaaax99xf8ڍvxcfxd6|x1ax1aV6H!xdax00" xc2Ï¥xfaDx16xb2xfaxd7x00xfexbaxe4xf3xed%x03x9a^x1dx9fx93_xf3x1fxd9Wx90x8aâX" key_material_type:ASYMMETRIC_PUBLIC} status:ENABLED key_id:1926408156 output_prefix_type:TINK} .nil.} Conclusions There are many risks in using JWTs, especially in capturing a token and playing it back. The expiry date should thus be set so that it would limit the impact of any malicious use. Using public key encryption to sign JWTs is a good method, as the authenticity of the token can be proven with the associated public key. With an HMAC method, we need to share a secret key, which could cause a data breach. And, finally, which signature method should you pick? Find out here:

Mark “Murch” Erhardt and Mike Schmidt are joined by Greg Sanders and Bastien Teinturier to discuss Newsletter #261. News Simplified LN closing protocol (1:03) LN Summit notes (10:48) Selected Q&A from Bitcoin Stack Exchange How can I manually (on paper) calculate a Bitcoin public key from a private key? (57:18) Why are there 17 native segwit versions? (59:43) Does `0 OP_CSV` force the spending transaction to signal BIP125 replaceability? (1:03:04) How do route hints affect pathfinding? (1:08:23) What does it mean that the security of 256-bit ECDSA, and therefore Bitcoin keys, is 128 bits? (1:12:26) Releases and release candidates HWI 2.3.0 (1:15:09) LDK 0.0.116 (1:16:37) Notable code and documentation changes Bitcoin Core GUI #740 (1:17:18)

Related blog: https://medium.com/asecuritysite-when-bob-met-alice/mathematics-in-the-blood-the-lenstra-family-bf188c686e74 Introduction I know it's a strange question to pose, but which family has most advanced the Internet and Cybersecurity? Well, the Lenstra family has a strong claim to that title. From their Dutch roots, they have contributed so much to our modern world — both from a theoretical and a practical point of view. I suppose there's something in the nature of the Dutch that not only wants to solve real problems, but do it in a scientific way. That approach is also the beating heart of academic research — to take major problems and solve them through collaborative efforts, and where each researcher breaks solves part of the puzzle. The Internet — and in fact our modern world — has been created through the coming together of all the amazing work of researchers over many decades. Meet the Cryptography and Problem-Solving Brothers My grandfather was an electrician, and my father was one too. I suppose electrical things are in my blood. It was where I started my career, and I have always had a love for everything that relates to electrons. I must admit I gave myself a little too many electrical shocks when I was a child, as the temptation to take things apart just seemed too strong for me. And, it still amazes me that we often just take electricity — and all its applications in our modern world — for granted. Where would we be without our control of electricity and all things electrical? You certainly wouldn't be reading this article, now. So, sometimes, there's something in our blood that defines our future careers. And for the Lenstra family that was certainly the case, and from their Dutch roots, Hendrik, Arjen, Andries and Jan Karel have become important mathematicians. One of the most famous of the brothers for those who have studied networking is the mighty Jan Karel Lenstra (J.K. Lenstra) and whose many major breakthroughs include scheduling, local searches and the travelling salesman problem. We can thus all thank Jan for his work on routing problems, and which led to the creation of routing protocols on the Internet: The solving of the routing problem on the Internet, allowed the Internet to scale to levels that we see now, and where we have almost instant access to information from any part of the planet. We can thank J.K. Lenstra for providing that foundation. Arjen followed a cryptography focus for his work, including many classic papers such as those related to the factorization of polynomials and a famous paper entitled “Ron was wrong. White is right” [here]: But, Arjen's most cited paper included his brother (Hendrik W. Lenstra Jr.) as a co-author [3]: And, in these days of Microsoft Word and LaTeX, don't you just love the pen markup on the paper? The brothers also collaborated on another classic paper — and which included the mighty J.M Pollard [2]: Lenstra–Lenstra–Lovász (LLL) When the two brothers worked together they created some of their best work, and it was the classic Factorizing Polynomials with Rational Coefficients paper [3] that led to the Lenstra–Lenstra–Lovász (LLL) method [paper]. The paper also included mighty Laszlo Lovász [here] (who has an h-index of 109): This will use this method — defined as Lenstra–Lenstra–Lovász (LLL) — to crack the signature, and discover the private key used to digitally sign the message. This will search for the private key that has been used to sign a message with ECDSA. In this case we will generate two signatures, and then search for a private key. One of the most common signatures is ECDSA (Elliptic Curve Digital Signature Algorithm) and which is used with Bitcoin and Ethereum. With this, Bob creates a random private key (priv), and then a public key from: Next, in order to create a signature for a message of M, he creates a random number (k) and generates the signature of: The signature is then (r,s) and where r is the x-co-ordinate of the point kG. H(M) is the SHA-256 hash of the message (M), and converted into an integer value. If the k value is revealed for any of the signatures, an intruder can determine the private key using: This works because: and so: and for priv: We can then use the code [here] to implement a searching method based on LLL: import ecdsaimport randomimport libnumimport olllimport hashlibimport sys# https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/ G = ecdsa.NIST256p.generatororder = G.order()print ("Curve detail")print (G.curve())print ("Order:",order)print ("Gx:",G.x())print ("Gy:",G.y())priv = random.randrange(1,order) Public_key = ecdsa.ecdsa.Public_key(G, G * priv)Private_key = ecdsa.ecdsa.Private_key(Public_key, priv) k1 = random.randrange(1, pow(2,127))k2 = random.randrange(1, pow(2,127))msg1="Hello"msg2="Hello1"if (len(sys.argv)>1): msg1=(sys.argv[1])if (len(sys.argv)>2): msg2=(sys.argv[2])m1 = int(hashlib.sha256(msg1.encode()).hexdigest(),base=16)m2 = int(hashlib.sha256(msg2.encode()).hexdigest(),base=16) sig1 = Private_key.sign(m1, k1)sig2 = Private_key.sign(m2, k2)print ("nMessage 1: ",msg1)print ("Message 2: ",msg2)print ("nSig 1 r,s: ",sig1.r,sig1.s)print ("Sig 2 r,s: ",sig2.r,sig2.s)print ("nk1: ",k1)print ("k2: ",k2)print ("Private key: ",priv)r1 = sig1.rs1_inv = libnum.invmod(sig1.s, order)r2 = sig2.rs2_inv = libnum.invmod(sig2.s, order) matrix = [[order, 0, 0, 0], [0, order, 0, 0],[r1*s1_inv, r2*s2_inv, (2**128) / order, 0],[m1*s1_inv, m2*s2_inv, 0, 2**128]] search_matrix = olll.reduction(matrix, 0.75)r1_inv = libnum.invmod(sig1.r, order)s1 = sig1.s for search_row in search_matrix: possible_k1 = search_row[0] try_private_key = (r1_inv * ((possible_k1 * s1) - m1)) % order if ecdsa.ecdsa.Public_key(G, G * try_private_key) == Public_key: print("nThe private key has been found") print (try_private_key) A sample run is [here]: Curve detailCurveFp(p=115792089210356248762697446949407573530086143415290314195533631308867097853951, a=-3, b=41058363725152142129326129780047268409114441015993725554835256314039467401291, h=1)Order: 115792089210356248762697446949407573529996955224135760342422259061068512044369Gx: 48439561293906451759052585252797914202762949526041747995844080717082404635286Gy: 36134250956749795798585127919587881956611106672985015071877198253568414405109Message 1: helloMessage 2: goodbyeSig 1 r,s: 115147473306387600780958700123813228515236063210926878166205132442387398405974 78422551211706787416844282162734821752165856246967039833155909830188362436931Sig 2 r,s: 72928835934664146344187979593177679887058837944881110039604237325952057142506 34831214671095490475430891005520988929988430486970993941519827388518136205821k1: 2238116107289725910464212774221939217k2: 23155266189808659522258191324208917771Private key: 3126769432554995310932591745910468237140199425344791317304188208833915624553 It is a truly fantastic paper, and well worth a read. In December 2019, a team led by Paul Zimmermann of INRIA announced the factorization of the largest ever RSA modulus (RSA-240): RSA-240 = 124620366781718784065835044608106590434820374651678805754818788883289666801188210855036039570272508747509864768438458621054865537970253930571891217684318286362846948405301614416430468066875699415246993185704183030512549594371372159029236099RSA-240 = 509435952285839914555051023580843714132648382024111473186660296521821206469746700620316443478873837606252372049619334517 × 244624208838318150567813139024002896653802092578931401452041221336558477095178155258218897735030590669041302045908071447 The factorization involved factorizing a 795-bit integer into its prime number factors. It caused industry experts to define that RSA would only be safe with at least 2,048-bit keys. Actually it was Arjen, in the 1990s, who was the first to crack the early RSA challenges, and managed to factorize 330 (100 decimal digits), 364, 426 and 430 bit modulus values [here]: Factorizing with elliptic curves Hendrik W. Lenstra Jr. became a Professor at the University of Amsterdam in 1979, and then, in 1987, he appointed to the University of California, Berkeley. One of his most famous PhD students is Daniel J. Bernstein [here], who is famous for producing standards such as Curve 25119, ChaCha20 and Poly1305. In the year Hendrik was appointed to Berkley, he outlined a method to factorize integrations using elliptic curve methods [1]: The security of several public key methods rely on the difficulty in factorizing a modulus created from the multiplication of large prime numbers. RSA is a good example of this, and where we take two large prime numbers (p and q), and multiply them to create a modulus (N). The difficulty is then to be able to find p and q, if we know N. The two core methods we can use for this factorization are the general number field sieve (GNFS) method and ECM (Elliptic Curve Method). ECM With his method, we define the moving from a point P on an elliptic curve to 2P. For this we find the tangent to the point P and use this to find 2P. This tangent will be defined with a slope (s) and with a gradient in the form of a/b. For this we must find the modular inverse of b. If we cannot find the modular inverse of b, a factor of N is gcd(N,b), and where gcd() is the greatest common denominator. If our curve is y²=x³+ax+b, the slope (s) will be: as defined in differentiation. In detail, we first pick a random point P=(x0,y0) on an elliptic curve of: We also select a random value of A and then calculate: For two points on the curve: P=(Px,Py) and Q=(Qx,Qy) , the slope of the line between them will be: With this we have s in the form of a/b (modN) . Next we define: and using: If Px=Qx and Py=−Qy, we define as 0 [Identity], else we calculate R=P+P=2P=(Rx,−Ry): Here are some test runs: N=15 (Factor: 3 and 5 Try! N=6,161 (Factors: 61 x 101) Try! N=32,128 (Factors: 2 x 2 x 2 x 2 x 2 x 2 x 2 x 251) Try! N=53,421 (Factor: 3 x 17,807) Try! N=55,440 (Factors: 2 x 2 x 2 x 2 x 3 x 3 x 5 x 7 x 11) Try! N=999,999 (Factor: 3 x 3 x 3 x 7 x 11 x 13 x 37) Try! N=10,000,000 (Factor: 2 x 2 x 2 x 2 x 2 x 2 x 2 x 5 x 5 x 5 x 5 x 5 x 5 x 5) Try! N=100,001 (Factor: 11 x 9091) Try! N=455,839 (Factor: 559 x 761) Try! N=3,789,829 (Factor: 3209 x 1181) Try! N=7,388,399 (Factor: 3571 x 2069) Try! N=392,524,199 (Factor: 431 x 919 x 991) Try! An outline of the code used is [code]: #!/usr/local/bin/python# -*- coding: utf-8 -*-import mathimport random import sys#y^2=x^3+ax+b mod n prime=[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271 ]# ax+by=gcd(a,b). This function returns [gcd(a,b),x,y]. Source Wikipediadef extended_gcd(a,b): x,y,lastx,lasty=0,1,1,0 while b!=0: q=a/b a,b=b,a%b x,lastx=(lastx-q*x,x) y,lasty=(lasty-q*y,y) if a>=1 return [Ret,d]def ellipticFactor(N,m,times=5): for i in xrange(times): E,P=randomCurve(N); Q,d=mulPoint(E,P,m) if d!=1 : return d return Nfirst=Truen=455839if (len(sys.argv)>1): n=int(sys.argv[1])print n,'=',for p in prime: while n%p==0: if (first==True): print p, first=False else: print 'x',p, n/=pm=int(math.factorial(2000))while n!=1: k=ellipticFactor(n,m) n/=k if (first==True): print k, first=False else: print 'x',k, Conclusions And, so, there's something in the Dutch approach to solving real problems, and in using a scientific approach, and the Lenstra have highlight that as well as any other. And for the factorizing of integers, the great public key methods of the past, may not scale well into the 2020s, especially as factorization becomes more powerful, and is actually beating Moore's Law. If you are interested, here are other methods for factorization: Difference of squares. Diffsq. This factorizes using the difference of squares method. Factors of integers. Factors. Determine factors of an integer. Pollard's ρ method (Factoring integers). Pollard. The Pollard ρ method factorises integers. Simplify ap (modN) Go. Simplify the a^p (modN) operation. Smooth numbers. Go. Outline of smooth numbers. Quadratic residue (mod p). Go. Outline of quadratic residue (mod p). Quadratic residue (mod N) and where N=pq. Go. Outline of quadratic residue (mod N) with N made-up of two prime numbers. Dixon. Go. Dixon Method. References [1] Lenstra Jr, H. W. (1987). Factoring integers with elliptic curves. Annals of mathematics, 649–673. [2] Lenstra, A. K., Lenstra, H. W., & Lovász, L. (1982). Factoring polynomials with rational coefficients. Mathematische annalen, 261(ARTICLE), 515–534. [3] Lenstra, A. K., Lenstra, H. W., Manasse, M. S., & Pollard, J. M. (1993). The number field sieve. In The development of the number field sieve (pp. 11–42). Springer, Berlin, Heidelberg.

Cybersecurity Cloud Lesson 1 rule book in key management for companies: Your encryption keys are the keys to your castle. So protect them with your life! Your enemy is you! The main threat is insiders, so beware of yourself and others in your company. Beware of those that you trust and who you partner with. They can be your enemies, too. For sensitive data, try not to let Amazon or Microsoft manage your keys. Put your private keys in an HSM (Hardware Security Module). A shared HSM is fine, but if you have funds, create your own Cloud HSM. If you are audited for your keys, you may need an on-premise HSM to link to your Cloud instance. Create meaningful tags for your keys that make sense for everyone. Don't tag them as “Key1”, “Key2”, and so on. Give them meaning, “Main Active Directory Single Sign-on Key for Sales in Europe”. Add words that allow you to search for keys easily. Log the usage of your keys everywhere and link to people, roles, services and applications. Log, log and log some more. Watch out for those keys being deleted … it is one of the easiest hacks for a disgruntled employee to perform. Watch out for key wrapping from your insiders and your key exports. See Point 1. Use a tiered alerting system which escalates the severity of the key usage, but make sure you keep those logs. Use envelope encryption. Test, test, and test some more. Audit, audit, and audit. On a daily basis, if nescessary. Test those encrypted backups. We all make mistakes. If you delete a key, please say, as we have 60 days to undelete it. Use key rotation wherever possible. Just because ECDSA and EdDSA sound all fancy and brand new doesn't mean that RSA is not an option. RSA is still your friend. Forget about those doom sayers on quantum cracking. MD5 and SHA-1 should never, ever, be seen. Beware of DevOpSec. They can be sloppy with their keys. Tell them off for doing risky things! I had better stop here. So, finally, put a large poster on the wall that says, “no key, means no data!”, “the enemy is within and around you!”, “A breach of the trust infrastructure is one of the most expensive cybersecurity threats to resolve”, “A single key breached, and this company could be finished!”. Sorry for being so coarse in places, but handling keys is a serious business.

We live in a legacy world of money. Our transactions are often still based on moving paper money around, and we have basically scaled this into a digital world. At the core of this is the lack of any real cryptographic trust in digitally signing transactions. For this, the Bank of England is now discussing a CBDC (Central Bank Digital Currency) [2]: And before you reach for Ethereum smart contracts and ERC tokens, there's a catch. This is not actually a cryptocurrency, but an electronic payment system. Basically, it will basically be a digital currency, and thus link these coins to a digital wallet which is held by a trusted payment entity (such as a bank or payment provider). The overall proposed architecture is to use a central bank ledger, which validates transactions. This would not contain any personal data on users and integrate at an API level. Access to this API for users would be through intermediaries — trusted and regulated payment providers. Users would not be able to interact with the core ledger without using an intermediary. Figure 1: Platform model [2] CBDC model To transfer funds in a traditional way, Alice contacts her bank and enables a transfer to Bob's bank. The transaction basically involves account numbers and sort codes and is transferred through a trusted payment gateway. This is identified with the purple line in Figure 2. In the CBDC model, Bob and Alice will own a digital wallet in their bank, and where Alice can move digital tokens from her wallet to Bob's. Overall, Bob and Alice can move money between their bank account and their digital wallet. The moving of their funds into the digital wallet gives lesser control of funds than the maintenance of bank accounts. Figure 2: Traditional payment v cryptographic payment In a traditional cryptocurrency system, Bob and Alice have a public blockchain wallet that contains their private key. In Ethereum, we transfer ERC20 tokens using a digital wallet. This digital wallet contains the private key to sign off the transaction. A smart contract then maintains a table of the owners of each of the ERC20 tokens issued. This relates to the wallet identifier as a hexadecimal address. This is identified as the red line in Figure 3. Figure 3: Cryptocurrency transaction using ERC20 tokens (red line) The state-of-the-art There are several existing models for a CBDC, including Project Hamilton, and which is a collaboration between the Federal Reserve Bank of Boston (Boston Fed) and MIT [1]: The targets are for a minimum of 100,000 transactions per second and for 99% of all transactions to be completed within five seconds. There should be no loss of funds in the event of a data outage, and privacy is a fundamental part of the design. An important element of the design is the use of intermediaries and custody. In terms of trust, we have intermediaries — such as banks, and payment service providers — and which are custodians of the digital wallet. But there is the opportunity for customers to own their own digital wallets — as with an Ethereum wallet. The model can then be “direct” — customer-to-central bank, or “two-tier” — central bank to intermediatory (Figure 4). Figure 4: Two-tier model — central bank to intermediatory The proposed method decouples fund checks with transaction validations. Funds are stored as a 32-byte hash value with an Unspent funds Hash Set (UHS) — Figure 5. The transaction has a similar format to Bitcoin. Figure 5: Unspent funds Hash Set (UHS) Economic concerns The speed of the transactions and the ease of access to digital currency could enable economic risks Reduced lending opportunities As the digital coins are moved to a wallet, they will thus be out of the control of a bank, which means that they could not lend the money to another person — which kinda defeats one of the main functions of a bank. If too much of this money was moved to wallets, it could cause the lending system to stall. Bank runs There have been many occurrences of runs on banks, including with Northern Rock. With this, customers queued to get access to the funds, and which generally slowed down the pressures on withdrawals. With a digital pound, this could be made much worse, as customers could withdraw their funds with a simple transfer. Banks could thus risk a run on their funds. Cybersecurity? Generally, we trust our banks to look after our money. With a digital wallet, attackers could target hacks, which could have lower levels of control on access to the wallet. A core part of the Bank of England's strategy for the digital pound is to develop resilience in both the technical and financial disuptions involved [2]: Technical challenges The enablement of a CBDC brings many technical challenges. Privacy and auditability There is a significant balance between privacy and auditabilty. The use of zero-knowledge proofs will allow for privacy within transactions, but this will hide the sender and recipient of a transaction. This privacy, though, can restrict auditability and reduce the opportunities for law-enforcement investigations. Programmability Most current models must have the full state transition of a transaction to be in-place for a transaction to go ahead (to avoid double spending). Within contract implementations, there may be intermediate states that allow for the digital pound to exist in an intermediate state awaiting an event. For example, Bob might commit to paying Alice for a new car, but she will not accept shipping the car until Bob commits the funds. Once she ships the car, the funds would then stay pending until Bob confirms its receipt. This smart contract associated with the transaction would thus need to store the state of the intermediary state, and not release the funds to Alice until there is a digital proof of receipt from Bob (Figure 6). Figure 6: Programmability Interoperability A major focus for the digital pound must be the interlinkage with existing Layer-2 payment channel networks. This would also support cross-border transactions but will require integration with other CBDCs in other countries. Offline payments In the likely model for the digital pound, there is an interaction between the central bank, and the transacting parties (Bob and Alice). In some circumstances, there could be no Internet connection, and thus there needs to be an offline transaction. This type of transaction will likely require a secret enclave to be setup on a hardware payment device so that the transaction could not be tampered with. Minting and redemption It is likely that the CBDC will be responsible for minting and removing the digital tokens. Each of these would be digitally signed by the issuing bank. But, the great risk here is the use of the private key to sign the transactions of the central bank. If an insider in the Bank of England gained access to this, then tokens could be issued or even removed by malicious entities — this is equivalent to printing forged bank notes. Productionization While models exist as prototypes, the scale-up to a national level would involve extensive design and implementation skills to make sure there were no ways to compromise the infrastructure. Denial of service attacks In a model where Bob and Alice own their private keys, there are no fees for a payment. This means there is no cost to support payment transactions, which means that it could be susceptible to a Denial of Service against the infrastructure — as it will not cost anything to flood the system with valid and invalid transactions. Likely mitigations here are rate-limiting, and the enforcement of a cool-off period before money can be respent on another transaction. Along with this, there could be proof-of-work transactions (such as computing a hash value of a given complexity for each transaction), or fees charged for a given volume of transactions. Quantum resistance Existing public key encryption methods — such as ECC and RSA — are at risk against quantum computers. The infrastructure that we create must be resilient to a medium-term attack against transactions. Currently, NIST has defined that Dilithium, FALCON and SPHINCS+ are the preferred solutions for digital signatures, and should replace RSA and ECDSA signatures. For key exchange, Kyber is recommended as a replacement for ECDH. It is likely that any digital currency will support these methods, alongside existing public key methods — but will migrate in time to the post-quantum robust methods. Conclusions It is an exciting time. A digital currency will open up new areas of innovation, but one slip-up could bring the whole of the financial infrastructure down in an instant. I repeat again, this is not cryptocurrency, but a trusted digital payment infrastructure. There are good opportunities to improve the detection of fraud and scamming, and truly move to a more trusted financial world. References [1] Lovejoy, J., Fields, C., Virza, M., Frederick, T., Urness, D., Karwaski, K., … & Narula, N. (2022). A high performance payment processing system designed for central bank digital currencies. Cryptology ePrint Archive. [2] The digital pound: Technology Working Paper, Bank of England, 2023.

In research, we build on the shoulders of giants, and Taher Elgamal is one the giants of cybersecurity. His work on Netscape led to the creation of SSL, and for which much of our Web security is still built on. His paper on "A public key cryptosystem and a signature scheme based on discrete logarithms" is true classic, and has been referenced over 11,600 times. Within the paper, Tahir outlined an encryption method and a digital signature method. His ‘base' was to take John Napier's logarithm, and make them discrete. The signature method was adopted as the Digital Signature Standard (DSS) by NIST, and which has to become ECDSA, as used by Bitcoin and Ethereum. The Elgamal methods is now being used in many new areas of privacy, including within homomorphic encryption methods. Tahir studied electrical engineering in the late 1970s at Stanford University. It was there he met Marty Hellman and who helped him spark an interesting in cryptography. He received his PhD in 1984 and it was Marty who introduced him to Paul Kocker at Netscape Communications. Together, Paul and Tahir worked on a method to implement end-to-end encryption, and published SSL 3.0 in November 1996. Join this "fireside chat", as Taher recalls his past, and also looks to the future.

Join Lois Houston and Nikita Abraham, along with special guest Rohit Rahi, as they discuss the various security capabilities that are built into OCI, ensuring full-stack protection and a platform that's secure by design.   Oracle MyLearn: https://mylearn.oracle.com/ Oracle University Learning Community: https://education.oracle.com/ou-community   Twitter: https://twitter.com/Oracle_Edu LinkedIn: https://www.linkedin.com/showcase/oracle-university/   Special thanks to Arijit Ghosh, Kiran BR, David Wright, the OU Podcast Team, and the OU Studio Team for helping us create this episode.  

On April 19th 2022, Neil Madden disclosed a vulnerability in many popular Java runtimes and development kits. The vulnerability, dubbed "Psychic Signatures", lies in the cryptography for ECDSA signatures and allows an attacker to bypass signature checks entirely for these signatures. How are popular cryptographic protocol implementations in Java affected? What's the state of Java cryptography as a whole? Join Neil, Nadim and Lucas as they discuss. Music composed by Yasunori Mitsuda. Special Guest: Neil Madden.

Crypto-Tuesday January 10, 2023 - Account abstraction (AA) is a powerful concept that can help business owners unlock the full potential of Ethereum transactions. AA combines user accounts and smart contracts into just one account type, giving users more flexibility in validating a transaction on the blockchain. Account abstraction (AA) is a proposal that attempts to combine user accounts and smart contracts into just one Ethereum account type by making user accounts function like smart contracts. This means that transactions on the Ethereum blockchain will have more flexibility when it comes to being validated. For instance, instead of having rigid requirements such as a valid ECDSA signature or sufficient balance to cover the cost of computation, users will be able to design their own unique criteria for validating their transactions. One of the biggest benefits of using account abstraction (AA) is that it enables multi-owner accounts, which can be used to facilitate auto payments between multiple parties without any manual intervention. This makes AA perfect for businesses looking to streamline their payment processes. Additionally, since AA allows you to customize your own criteria for validating a transaction, you can ensure that only legitimate transactions are processed on your blockchain network. This helps minimize fraud and other malicious activity on your blockchain network. Another benefit of using account abstraction is that it allows for much faster transaction processing times than traditional Ethereum transactions. Since users are not required to wait for confirmations from miners before processing a transaction, you can dramatically reduce transaction processing times with AA and make sure your customers get their products or services delivered promptly. Account abstraction (AA) offers numerous benefits for business owners looking to transition onto the blockchain platform and take advantage of its features in order to streamline their operations and reduce costs associated with managing payments between multiple parties. With AA, businesses can enjoy enhanced security measures due to customizable criteria for validating transactions as well as faster processing speeds due to reduced waiting times for confirmations from miners. Ultimately, if you want your business operations to run smoothly and efficiently while enjoying maximum security and trustworthiness from customers, then account abstraction may be exactly what you need! Attorney Steven A. Leahy takes an in-depth look at what Account Abstraction is and how it can benefit your business.on Today's Tax Talk. https://www.forbes.com/sites/michaeldelcastillo/2022/12/19/visa-proposal-would-bring-ethereum-users-one-step-closer-to-being-their-own-bank/?sh=7b43948521b5 https://usa.visa.com/solutions/crypto/auto-payments-for-self-custodial-wallets.html --- Send in a voice message: https://anchor.fm/steven-leahy1/message

Links: A super-neat exploration of the Lambda execution environment from a security perspective. Detect and block advanced bot traffic  How to evaluate and use ECDSA certificates in AWS Certificate Manager - AWS released support for ECDSA certificates. Canary Tokens

This week John talks more on his recent work using Swift Attributed String API, his past experiences with start ups and the connections and relationships that make it work. Scotty talks his week of modernising MoneyWell including upgrading to ECDSA keys, the correct way of dealing with problems with open source software. Andy Matuschak Sparkle XcodeGen Going Hardcore at Twitter Markdown Images My Mom's Cat Is Famous SNL COVID Parody

Software Releases and Project Updates 00:01:41 COLDCARD Mk4 5.0.7 - Sep 9, 2022 (bit.ly/3BClP0f) 00:05:56 Core Lightning v0.12.0 - Aug 24, 2022 (bit.ly/3S5lr1m) 00:12:43 Blockclock 1.2.0 - Sep 15, 2022 (bit.ly/3BxSILG) 00:13:34 Spectre desktop v1.12.0 - Aug 26, 2022 (bit.ly/3qSWBWK) 00:16:28 Joinmarket v0.9.7 - Aug 28, 2022 (bit.ly/3qWoH3f) 00:17:50 NPM package for SeedXOR. (bit.ly/3C8BOFb) 00:25:56 RoboSats on Umbrel (bit.ly/3fcjDFa) 00:27:19 Ledger adding miniscript (bit.ly/3UmX4xX) 00:29:16 Trezor & Wasabi Join Forces To Make Bitcoin More Private (bit.ly/3BXXJOV) 00:30:03 Fulcrum added to bitcoinbinary (bit.ly/3DK4xBc) 00:37:51 btcd v0.23.1-beta, Aug 31 2022 (bit.ly/3Urjwpv) 00:38:04 Zeus v0.6.6, Aug 26 2022 (bit.ly/3f9vpjD) 00:39:24 Nunchuk implements bip21, Aug 31 2022 (bit.ly/3BZWG14) 00:39:57 BISQ v1.9.5, Aug 22 2022 (bit.ly/3LyPrR5) 00:41:01 Fountain Podcasts v0.4.8 (bit.ly/3f1ZTnH) 01:33:44 ATEC608A NRND (bit.ly/3xGWmBZ) 01:39:26 ETH merge (bit.ly/3SlgfWR) 01:51:21 Spiral - Private info retrieval block explorer (bit.ly/3BDto70) 01:56:03 US Treasury OFAC Releases Clarifications on Tornado Cash Sanctions (bit.ly/3S1PEyl) 01:57:05 BIP Proposal: Wallet Labels Export Format (bit.ly/3Sj5c17) 02:00:51 STARK - Zero knowledge bitcoin blockchain state prover (bit.ly/3C0oT8b) 02:03:09 Mullvad VPN hardware device (bit.ly/3f9LV3p) Noteworthy 00:53:47 BIPBounty: Tax Deductible Bitcoin Bug Bounties (bit.ly/3LMxP4l) 00:59:34 Fedimint grant season (bit.ly/3S32zjP) 01:00:00 Tether Holds Firm on Decision Not To Freeze Tornado Cash Addresses (bit.ly/3UwFgAg) 01:01:04 New York Digital Investment Group Announces Lightning Accelerator Project “in Wolf's Clothing” (bit.ly/3xHo1Ti) 01:01:49 Tadge Dryja joins Lightspark (https://bit.ly/3SoAZNG) 01:11:26 Shoutout, no bullshit bitcoin - (bit.ly/3DEqB05) 01:12:22 LN Explorer (bit.ly/3xIYF7k) 01:16:34 Ledger wallets now available at Best Buy (bit.ly/3BA10mr) Bitcoin Optech Newsletter: 01:24:13 Bitcoin Core #23202 extends the psbtbumpfee RPC 01:25:08 Eclair #2387 adds support for fee bumping and signet 01:25:27 LDK #1652 updates support for onion messages w/ ability to send reply paths and decode them when received 01:25:36 HWI #627 adds support for P2TR keypath spends using the BitBox02 hardware signing device 01:33:22 BDK begins verifying both ECDSA and schnorr signatures immediately after the wallet creates them 02:18:00 Events: OsloPlebs Austin Bitcoin Design Club BitBlockBoom Baltic Honeybadger BTCAzores Bitcoin Amsterdam The Bitcoin Collective Atlanta Bitcoin Conf Adopting Bitcoin Unconfiscatable Africa Bitcoin Conf

I'm joined by guests Matt Odell, Bitstein & Pierre Rochard. Software Releases and Project Updates 00:01:41 COLDCARD Mk4 5.0.7 - Sep 9, 2022 (bit.ly/3BClP0f) 00:05:56 Core Lightning v0.12.0 - Aug 24, 2022 (bit.ly/3S5lr1m) 00:12:43 Blockclock 1.2.0 - Sep 15, 2022 (bit.ly/3BxSILG) 00:13:34 Spectre desktop v1.12.0 - Aug 26, 2022 (bit.ly/3qSWBWK) 00:16:28 Joinmarket v0.9.7 - Aug 28, 2022 (bit.ly/3qWoH3f) 00:17:50 NPM package for SeedXOR. (bit.ly/3C8BOFb) 00:25:56 RoboSats on Umbrel (bit.ly/3fcjDFa) 00:27:19 Ledger adding miniscript (bit.ly/3UmX4xX) 00:29:16 Trezor & Wasabi Join Forces To Make Bitcoin More Private (bit.ly/3BXXJOV) 00:30:03 Fulcrum added to bitcoinbinary (bit.ly/3DK4xBc) 00:37:51 btcd v0.23.1-beta, Aug 31 2022 (bit.ly/3Urjwpv) 00:38:04 Zeus v0.6.6, Aug 26 2022 (bit.ly/3f9vpjD) 00:39:24 Nunchuk implements bip21, Aug 31 2022 (bit.ly/3BZWG14) 00:39:57 BISQ v1.9.5, Aug 22 2022 (bit.ly/3LyPrR5) 00:41:01 Fountain Podcasts v0.4.8 (bit.ly/3f1ZTnH) 01:33:44 ATEC608A NRND (bit.ly/3xGWmBZ) 01:39:26 ETH merge (bit.ly/3SlgfWR) 01:51:21 Spiral - Private info retrieval block explorer (bit.ly/3BDto70) 01:56:03 US Treasury OFAC Releases Clarifications on Tornado Cash Sanctions (bit.ly/3S1PEyl) 01:57:05 BIP Proposal: Wallet Labels Export Format (bit.ly/3Sj5c17) 02:00:51 STARK - Zero knowledge bitcoin blockchain state prover (bit.ly/3C0oT8b) 02:03:09 Mullvad VPN hardware device (bit.ly/3f9LV3p) Noteworthy 00:53:47 BIPBounty: Tax Deductible Bitcoin Bug Bounties (bit.ly/3LMxP4l) 00:59:34 Fedimint grant season (bit.ly/3S32zjP) 01:00:00 Tether Holds Firm on Decision Not To Freeze Tornado Cash Addresses (bit.ly/3UwFgAg) 01:01:04 New York Digital Investment Group Announces Lightning Accelerator Project “in Wolf's Clothing” (bit.ly/3xHo1Ti) 01:01:49 Tadge Dryja joins Lightspark (https://bit.ly/3SoAZNG) 01:11:26 Shoutout, no bullshit bitcoin - (bit.ly/3DEqB05) 01:12:22 LN Explorer (bit.ly/3xIYF7k) 01:16:34 Ledger wallets now available at Best Buy (bit.ly/3BA10mr) Bitcoin OpTech Newsletter: 01:24:13 Bitcoin Core #23202 extends the psbtbumpfee RPC 01:25:08 Eclair #2387 adds support for fee bumping and signet 01:25:27 LDK #1652 updates support for onion messages w/ ability to send reply paths and decode them when received 01:25:36 HWI #627 adds support for P2TR keypath spends using the BitBox02 hardware signing device 01:33:22 BDK begins verifying both ECDSA and schnorr signatures immediately after the wallet creates them 02:18:00 Events: OsloPlebs Austin Bitcoin Design Club BitBlockBoom Baltic Honeybadger BTCAzores Bitcoin Amsterdam The Bitcoin Collective Atlanta Bitcoin Conf Adopting Bitcoin Unconfiscatable Africa Bitcoin Conf Links & Contacts: Website: https://bitcoin.review/Podcast Twitter: https://twitter.com/bitcoinreviewhq NVK Twitter: https://twitter.com/nvk Telegram: https://t.me/BitcoinReviewPod Email: bitcoinreview@coinkite.com Full show notes: https://bitcoin.review/podcast/2022/07/27/Episode-06.html

Discount link: https://hardblock.com.au/join/ozbitcoinpod Guest: https://twitter.com/llfourn (https://github.com/llfourn) - Contact Lloyd to work on bitcoin development with him in Malaysia! Host: https://twitter.com/mission_bitcoin Notes - Lloyd's bitcoin journey and getting into bitcoin (and cryptography) development - Developing the GUN (Go Up Number) command line interface bitcoin wallet - Developing the stripped-down DLC (discrete log contracts) betting/wager extension for GUN - Working on FROST, a new multi-signature protocol that uses Schnorr threshold signatures with a single public key (rather than multiple public keys being disclosed on the blockchain like in 'traditional' multi-signature protocols) - Privacy-improving and data-saving (leading to fee-reducing) affects of Schnorr signature aggregation - History of why ECDSA (elliptic curve digital signature algorithm) was used initially over Schnorr signatures (spoiler: it's related to patents) - Lightning Network (LN) privacy considerations: - Where (on-chain) are your LN channel open transactions originating from? - Practical tip: using coinjoins or coinswaps before opening LN channels can improve privacy - Privacy versus convenience trade-offs when sending LN directly to your recipient versus sending via multiple intermediary hops first - More hops on a LN payment pathway is not always better (eg, it can lead to payment failure, and could erode privacy if multiple of those routing nodes are surveilling the network)) - Practical tips: keep all your channels unannounced ("private") and only connect with nodes you trust are not performing network surveillance - Will PTLCs (point time locked contracts) improve LN privacy more than currently-used HTLCs (hashed time lock contracts)? - Channel probing attacks exist today to discover "private" (ie, unannounced) LN channels and to determine their channel balance; this is exacerbated by public channels announcing all of their identifying details (which makes process-of-elimination and brute-force attacks more viable on the remaining unannounced channels) - What you do with your on-chain coins (UTXOs) after closing a LN channel can be important with regard to privacy; in fact, what your channel partners do with their on-chain UTXOs post channel close can also impact your privacy! - Practical tip: coinswap or coinjoin your left-over UTXO after closing a LN channel - Cross-layer links (ie, base-layer and LN layer) are bad for privacy, but some improvements are coming (eg, using unique channel aliases/IDs with each LN node you connect with, rather than a reused channel ID that can be linked easily back to your on-chain UTXO) - Practical tip: run your own node (but be mindful it can be done badly - there are cases when using a trusted third party may be better) - LN sender-side privacy is generally better than receiver-side, as a LN invoice to receive a payment will leak private information (eg, which UTXO belongs to the node) - Practical tip: don't re-use LN invoices - A potential LN privacy and convenience solution: using payment hubs, similar to the Tumblebit proposal and Chaumian e-cash mints (eg, FediMint or MiniMint), but with added improvements with regards to custody of funds and transaction output size - Attending the Asia-Pacific Bitcoin Socratic to help flesh out bitcoin improvements References https://bitcoinproblems.org https://github.com/bitcoin-sydney/socratic https://abytesjourney.com/lightning-privacy

Guillaume et Emmanuel discutent de l'état des versions de Java utilisées, de Java String template, et de beaucoup de failles de sécurité. On pourra presque se renommer Les Cast Sécu ;P On y ressussite aussi la rubrique débutant et discutons du piège de la classe URL. Enregistré le 20 mai 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–279.mp3 News Langages L'état de Java selon newrelic Java 11 commence enfin à être utilisé plus que Java 8 en prod (48% vs 46%) Dans les versions non LTS, c'est Java 14 qui a l'air d'avoir le plus de succès non LTS en prod est 2,7% Après Oracle, c'est la distrib de AWS qui est pas mal utilisée suivi par adoptium Beaucoup d'utilisation de Java dans des containeurs (70%) avec 1 seul core, donc aussi moins de bénéfices dans l'utilisation de G1 pour le GC Toujours dans les containeurs, les applis Java tournent souvent avec moins de 512MB de RAM (45%) String templates en Java les string template c'est ce qui a fournit log4shell donc attention Replace certains usages de stringbuilder , stringfromat et messageformat Beaucoup de langages offrent ça (bash ahah) Exemple d'usage html, json, yaml etc Ils veulent permettre des règles de transformations et de validation (escape caractère) Peut même éviter le,passage par l'étape du passeur Objet template a le template et la policy Embedded expressions: chaînes de caractères, arithmétique, invoque méthodes ou champs, pas besoin d'échapper les double guillemets. Lignes multiples Quid capture des variables locales sans l'avis du développeur. Pas d'exemple meta où le template est importé ou construit. Un article détaillé sur ce qui est nouveau niveau GC dans Java 18 Librairies Quarkus 2.8 et 2.9 WebAuthN Confluent Schema Registry Kotlin Scala RESTEasy Reactive est la couche par défaut GraalVM 22 Elasticsearch Dev Services Outillage Un nouveau décompilateur avec du code plus lisible Tous plus ou moins un fork de celui d'intellij maintenu par JetBrains, le fork d'avant est de Minecraft Reconstruit des constructions de plus haut niveau et plus moderne. Exemples Sécurité Une vulnérabilité dans struts 2 Un problème qui n'avait été que partiellement corrigé. Lié à OGNL'et une double évaluation via %{…} sur du contenu venant de l'utilisateur. Le gros trou de sécu sur les signatures Java 15–18 attaque sur les approches ECDSA (elliptic curve digital signature algorithm), typiquement plus modernes cibles Java web start, Java applets, web services qui utilisent ECDSA (JWT, SAML, OIDC Id tokens, WebAuthN version Oracle Java 7, 8, 11, 15, 16, 17, 18, OpenJDK 15, 17, 18 (backport Oracle) Comme un psychic paper de dr who: peut signer numériquement un papier sans infos (paramètres de la courbe peuvent être à 0 ce qui permet de valider tous les messages (0) L'interprétation pour un framework comme Quarkus Spring4Shell avec risque de remote code execution (unfolding) Mitigations: mettre a jour 5.x, mettre a jour tomcat (tactique), setDisallowedField pour excludes les accès aux getter/setter class, passer a Java 8 La RCE est basée sur la navigation non restreinte de class.module.classLoader Spring MVC Early Announcement Spring Cloud exploit announcement Spring MVC Exploit Announcement Spring4Shell HelpNetSecurity assessment Spring4Shell Sonatype Assessment Qualys assessment Personal Security Checklist Recense les bonnes pratiques en terme de sécurité numérique Selon différents thèmes Authentication Browsing the Web Email Secure Messaging Social Media Networks Mobile Phones Personal Computers Smart Home Personal Finance Human Aspect Physical Security Google offre aux clients Google Cloud des libairies validées en sécurité Une équipe de maintenance Open Source chez Google Loi, société et organisation Apple va supprimer au téléchargements les applis non mises a jour depuis 3 ans et peu téléchargées ça a fait réagir et râler Des applis finies Mais surtout une résumassions c'est du taf (nouvelles règles, peut être mise à jour de framework) Du cote de Apple c'est nettoyer un peu la longue queue d'applis Et encourager les gens à rester au top (eg privacy infos) Les duchesses ferment leur slack aux hommes pas fait de gaité de cœur mais réaction aux événements temps des Modérations plus passe sur les posts d'hommes que de femmes Sensation de pas laisser la place aux femmes Maladresses et manques de respect Coupé dynamisme et la sécurité de parole Et beaucoup d'hommes et du coup sentiment d'épier Les duchess feront toujours des événements mixtes mais cet espace avait perdu son utilité première Comment la guerre en Ukraine ébranle la tech russe fragilisation fuite des cerveaux (depuis 2014 et la crimée (cerveaux emprunts de plus de liberté) manque .5 à 1 millions de developpeurs Karspersky et les doutes de ses clients (80% du chiffre d'affaire à l'étranger) Yandex moteur de recherche protégé car marcher local mais démission du CEO Default de paiement (endettement) e.g. VK 400 millions de dollars Envisager de raid de disque dur pour consommation locale Outils de l'épisode Faire le la configuration conditionnelle dans git includeIf permet de faire la condition Utile pour changer l'email entre bureau et perso par exemple. [aheritier] je le fais souvent avec des repertoires différents pour boulot vs oss/perso Rubrique débutant La comparaison des URL Les URLs sont égales si les IP sont égales donc DNS lookup donc pas constant pour la vie de l'instance de JVM vive les hash des Set et Map :) Conférences JavaDay au Paris JUG: Le futur de Java - le 22 juin 2022 Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/

How should we empower developers to embrace the NIST software development practices? Because from here on out, developers need to view themselves as the front lines of defense for the end-consumer. A more secure-aware developer leads to a more-protected consumer. Dr. Wang will offer her perspectives! In the AppSec News: Java's ECDSA implementation is all for nought, writing a modern Linux kernel RCE, lessons learned from the Okta breach, lessons repeated from a log4shell hot patch, a strategy for bug bounties, Microsoft finally disables SMB1!   Show Notes: https://securityweekly.com/asw194 Visit https://www.securityweekly.com/asw for all the latest episodes!   Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly

Java's ECDSA implementation is all for nought, writing a modern Linux kernel RCE, lessons learned from the Okta breach, lessons repeated from a log4shell hot patch, a strategy for bug bounties, Microsoft finally disables SMB1   Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw194

How should we empower developers to embrace the NIST software development practices? Because from here on out, developers need to view themselves as the front lines of defense for the end-consumer. A more secure-aware developer leads to a more-protected consumer. Dr. Wang will offer her perspectives! In the AppSec News: Java's ECDSA implementation is all for nought, writing a modern Linux kernel RCE, lessons learned from the Okta breach, lessons repeated from a log4shell hot patch, a strategy for bug bounties, Microsoft finally disables SMB1!   Show Notes: https://securityweekly.com/asw194 Visit https://www.securityweekly.com/asw for all the latest episodes!   Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly

Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/a-struts-rce-broken-java-ecdsa-psychic-signatures-and-a-bad-log4shell-fix.html An intresting mix of issues from crypto (Psychic Signatures), to a bad vulnerability patching service (patching log4shell), and bad logic leading to authentication bypassing and leaking sensitive keys. [00:00:24] Psychic Signatures in Java [CVE-2022-21449] [00:15:09] AWS's Log4Shell Hot Patch Vulnerable to Container Escape and Privilege Escalation [00:18:33] Bypass Apple Corp SSO on Apple Admin Panel [00:21:55] Exploiting Struts RCE on 2.5.26 [00:27:46] bluez: malicious USB devices can steal Bluetooth link keys over HCI using fake BD_ADDR [00:31:20] New XSS vectors The DAY[0] Podcast episodes are streamed live on Twitch (@dayzerosec) twice a week: Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. The Video archive can be found on our Youtube channel: https://www.youtube.com/c/dayzerosec You can also join our discord: https://discord.gg/daTxTK9 Or follow us on Twitter (@dayzerosec) to know when new releases are coming.

Java's ECDSA implementation is all for nought, writing a modern Linux kernel RCE, lessons learned from the Okta breach, lessons repeated from a log4shell hot patch, a strategy for bug bounties, Microsoft finally disables SMB1   Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw194

Links: GitHub organizations: https://alsmola.medium.com/securing-github-organizations-9c33c850638 CloudTrail would spew other accounts' credentials your way: https://onecloudplease.com/blog/security-september-cataclysms-in-the-cloud-formations Spot on: https://research.nccgroup.com/2022/01/13/10-real-world-stories-of-how-weve-compromised-ci-cd-pipelines/ Some excellent points: https://www.darkreading.com/cloud/enterprises-are-sailing-into-a-perfect-storm-of-cloud-risk “Amazon EC2 customers can now use ED25519 keys for authentication with EC2 Instance Connect”: https://aws.amazon.com/about-aws/whats-new/2022/01/ed25519-keys-authentication-ec2-instance-connect/ “Integrating AWS Security Hub, IBM Netcool, and ServiceNow, to Secure Large Client Deployments”: https://aws.amazon.com/blogs/apn/integrating-aws-security-hub-ibm-netcool-and-servicenow-to-secure-large-client-deployments/ “Best practices for cross-Region aggregation of security findings”: https://aws.amazon.com/blogs/security/best-practices-for-cross-region-aggregation-of-security-findings/ Assume AWS IAM Roles using SAML.to in GitHub Actions: https://github.com/saml-to/assume-aws-role-action TranscriptCorey: This is the AWS Morning Brief: Security Edition. AWS is fond of saying security is job zero. That means it's nobody in particular's job, which means it falls to the rest of us. Just the news you need to know, none of the fluff.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: So, most interesting this week is probably my request for AWS to support a different breed of SSH key. No, it's not a joke. Listen on and we'll get there.So, from the security community last week, everyone talks about how to secure AWS environments. This post takes a different direction and talks about how to secure GitHub organizations, which makes sense if you think about it as an area to focus on. If you compromise an org's GitHub repositories, it's basically game over for that company.I also came across this post from 2020, talking about how if asked politely, CloudTrail would spew other accounts' credentials your way. How many more exploits like this have we seen and just never been told about?NCC Group has some great stories up about compromising CI/CD pipelines, and they are all spot on. Because nobody really thinks about the Jenkins box that has everyone working with it, outsized permissions, and of course, no oversight.Enterprise cloud risk is a very real thing, so a post from Josh Stella, who's the CEO of Fwage—though he pronounces it as ‘Fugue'—and it makes some excellent points, and also cites me, so of course, I'm going to mention it here. We incentivize the behaviors we want to see more of. There's a security lesson in there somewhere.Corey: This episode is sponsored in part by our friends atNew Relic. If you're like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They've designed everything you need in one platform with pricing that's simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visitnewrelic.com. Observability made simple.Now, from AWS, what have they said? “Amazon EC2 customers can now use ED25519 keys for authentication with EC2 Instance Connect”. I really wish they'd add support for ECDSA keys as well, and no, this is not me making a joke. Those are the only key types Apple lets you store in the Secure Enclave on Macs that support it, and as a result, you can use that while never exporting the private key. I try very hard to avoid having private key material resident on disk, and that would make it one step easier.“Integrating AWS Security Hub, IBM Netcool, and ServiceNow, to Secure Large Client Deployments”. I keep talking about how if it's not simple, it's very hard to secure. AWS, IBM, and ServiceNow, all integrating is about as far from “Simple” as is possible to get.“Best practices for cross-Region aggregation of security findings”. And this was a post that I was about to snark that it should be as simple as “Click the button,” but then I read my post, and to my surprise and yes, delight, it already is. Good work.And in the land of tool, I found a post talking about how to assume AWS IAM Roles using SAML.to in GitHub Actions, and I really wish that that was first-party, but I'll take what I can get. Because again, I despise the idea of permanent IAM credentials just hanging out in GitHub or on disk or, realistically, anywhere. I like these ephemeral approaches. You can be a lot more dynamic with it and breaching those credentials doesn't generally result in disaster for everyone. And that's what happened last week in AWS security.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Links and vulnerability summaries for this episode are available at: https://dayzerosec.com/podcast/rust-in-the-web-a-special-guest-and-some-bad-crypto.html We are joined by Bastian Gruber to start the episode with a discussion about Rust. Then we'll dive into a few interesting vulnerabilities this week including yet another ECDSA implementation issue and some header smuggling research. [00:00:40] Rust Discussion with Bastian Gruber (Use the code poddayzero21 for 35% off Manning books) [00:46:29] Arbitrary Signature Forgery in Stark Bank ECDSA Libraries [CVE-2021-43572, CVE-2021-43570, CVE-2021-43569, CVE-2021-43568, CVE-2021-43571] [01:02:37] Becoming A Super Admin In Someone Elses Gsuite Organization And Taking It Over [01:06:52] Private Blog Content Disclosed in Atom Feed [01:08:29] Practical HTTP Header Smuggling: Sneaking Past Reverse Proxies to Attack AWS and Beyond [01:17:01] IDOR through MongoDB Object IDs Prediction [01:18:45] History of Cross-Site History Leaking The DAY[0] Podcast episodes are streamed live on Twitch (@dayzerosec) twice a week: Mondays at 3:00pm Eastern (Boston) we focus on web and more bug bounty style vulnerabilities Tuesdays at 7:00pm Eastern (Boston) we focus on lower-level vulnerabilities and exploits. The Video archive can be found on our Youtube channel: https://www.youtube.com/c/dayzerosec You can also join our discord: https://discord.gg/daTxTK9 Or follow us on Twitter (@dayzerosec) to know when new releases are coming.

July and August were very boring months for announcements, so Arjen, JM, and Guy decided to discuss them both in a single episode. They also decided to record before the month actually ended, which doesn't really behoove them as they missed out on a couple of actually interesting announcements. So those will be discussed in our September episode. News Finally in Sydney Amazon ml.Inf1 instances are now available on Amazon SageMaker in 4 additional AWS Regions Amazon RDS Cross-Region Automated Backups Regional Expansion AWS Directory Service now supports smart card authentication with AD Connector for Amazon WorkSpaces in 5 additional AWS Regions Serverless Lambda AWS Lambda adds support for Python 3.9 AWS Lambda now supports Amazon MQ for RabbitMQ as an event source Amplify AWS Amplify launches new full-stack CI/CD capabilities Complete guide to full-stack CI/CD workflows with AWS Amplify | Front-End Web & Mobile AWS Amplify CLI adds support for storing environment variables and secrets accessed by AWS Lambda functions AWS Amplify allows you to mix and match authorization modes in DataStore AWS Amplify now supports Sign in with Apple Announcing Amplify Geo (Developer Preview) for AWS Amplify Other Amazon API Gateway now supports mutual TLS with certificates from third-party CAs and ACM Private CA Simplify CI/CD configuration for serverless applications and your favorite CI/CD system — Public Preview AWS AppSync now supports custom authorization with AWS Lambda for GraphQL APIs Containers Amazon EKS and EKS Distro now support Kubernetes version 1.21 Amazon EKS now supports Kubernetes 1.21 | Containers Amazon EKS managed node groups now supports parallel node upgrades Amazon EKS now supports Multus Amazon ECS supports additional configurations for scheduled and event-driven tasks AWS Cloud Map supports configuring negative caching for DNS queries AWS App Mesh Constructs for AWS CDK are now generally available AWS Private Certificate Authority introduces integration with Kubernetes Amazon VPC CNI plugin increases pods per node limits EC2 & VPC Instances Introducing new Amazon EC2 G4ad instance sizes New – Amazon EC2 M6i Instances Powered by the Latest-Generation Intel Xeon Scalable Processors | AWS News Blog Amazon EC2 customers can now use ED25519 keys for authentication during instance connectivity operations Amazon EC2 Hibernation adds support for C5d, M5d, and R5d Instances Amazon Virtual Private Cloud (VPC) customers can now assign IP prefixes to their EC2 instances Assigning prefixes to Amazon EC2 network interfaces - Amazon Elastic Compute Cloud Amazon EC2 now supports custom time windows for Scheduled Events Auto Scaling Amazon EC2 Auto Scaling enhances Instance Refresh with configuration checks, Launch Template validation, and Amazon EventBridge notifications Amazon EC2 Auto Scaling now lets you control which instances to terminate on scale-in Other Amazon EC2 adds Resource Identifiers and Tags for VPC Security Group Rules Amazon CloudFront announces new APIs to locate and move alternate domain names (CNAMEs) AWS Elastic Beanstalk supports Capacity Rebalancing for Amazon EC2 Spot Instances AWS lowers data processing charges for AWS PrivateLink AWS IoT Core for LoRaWAN now supports VPC endpoints AWS IoT Core now supports VPC Endpoints Dev & Ops Dev Tooling EC2 Image Builder now supports parameters in components for creating custom images AWS Cloud9 introduces new features to browse CloudWatch Logs, S3, and use EC2 instance profiles Introducing AWS App Runner integration in the AWS Toolkit for VS Code Amazon CodeGuru Profiler adds recommendation support for Python applications Amazon CodeGuru Profiler extends visualizations capability with a new compare option for application profile Amazon CodeGuru Profiler announces new automated onboarding process for AWS Lambda functions CodeBuild Supports Publicly Viewable Build Results AWS AppConfig now enables customers to compare two application configuration versions AWS App2Container now supports containerization of complex multi-tier Windows applications CDK/CloudFormation Announcing CDK Pipelines GA, CI/CD for CDK Apps AWS CDK releases v1.111.0 - v1.116.0 with updates for unit testing and CDK Pipelines support AWS CloudFormation now supports more stacks per AWS account You can now import your AWS CloudFormation stacks into a CloudFormation stack set Systems Manager AWS Systems Manager Application Manager now supports full lifecycle management of AWS CloudFormation templates and stacks Now view inventory and patch compliance of stopped instances using AWS Systems Manager AWS Systems Manager Automation now supports upgrade of SQL Server 2012 AWS Systems Manager OpsCenter launches operational insights to identify duplicate items and event sources with unusual activity Now enable auto-approval of change requests and expedite changes with AWS Systems Manager Change Manager AWS Systems Manager Change Manager now supports AWS IAM roles as approvers AWS Systems Manager Fleet Manager now offers report generation for Managed Instances Other AWS Control Tower announces improvements to guardrail naming and descriptions Announcing Amazon CloudWatch cross account alarms Amazon CloudWatch Synthetics supports visual monitoring Amazon CloudWatch Logs now supports Usage Metrics Security AWS Firewall Manager now supports central monitoring of VPC routes for AWS Network Firewall AWS Shield Advanced no longer requires AWS WAF logging for web-application layer event response AWS Certificate Manager provides expanded usage of imported ECDSA and RSA Certificates Amazon QLDB supports customer managed KMS keys AWS Control Tower now provides support for KMS Encryption AWS Security Hub adds 10 new controls to its Foundational Security Best Practices standard for enhanced cloud security posture monitoring AWS License Manager now supports Delegated Administrator AWS WAF now offers managed rule group versioning AWS Security Hub adds 18 new controls to its Foundational Security Best Practices standard and 8 new partners for enhanced cloud security posture monitoring Data Storage & Processing AWS DataSync can now copy system access control lists (SACLs) to Amazon FSx for Windows File Server Amazon Lightsail now offers object storage for storing static content Amazon Data Lifecycle Manager launches new console experience Announcing availability of Red Hat Enterprise Linux with Microsoft SQL Server for Amazon EC2 Amazon Neptune now supports the openCypher query language Amazon RDS Proxy can now be created in a shared Virtual Private Cloud (VPC) Amazon RDS for SQL Server now supports Automatic Minor Version Upgrades Introducing Amazon MemoryDB for Redis – A Redis-Compatible, Durable, In-Memory Database Service | AWS News Blog AWS Transfer Family expands compatibility for FTPS/FTP clients and increases limit for number of servers Amazon ElastiCache for Redis now supports auto scaling EBS AWS Announces General Availability of Amazon EBS io2 Block Express Volumes Amazon Elastic Block Store now supports idempotent volume creation AWS CloudTrail now supports logging of data events for Amazon EBS direct APIs Athena Amazon Athena adds parameterized queries to improve reusability and security Amazon Athena announces data source connector for Power BI S3 AWS Storage Gateway adds support for AWS Privatelink for Amazon S3 and Amazon S3 Access Points Amazon S3 Access Points aliases allow any application that requires an S3 bucket name to easily use an access point Amazon S3 on Outposts supports direct access for applications running outside the Outposts VPC Amazon S3 on Outposts now supports sharing across multiple accounts Amazon EMR now supports Amazon S3 Access Points to simplify access control Redshift Amazon Redshift simplifies the use of JDBC/ODBC with authentication profile Cross-Account Data Sharing for Amazon Redshift | AWS News Blog Redshift spatial performance enhancements and new spatial functions Glue AWS Glue Studio now provides data previews during visual job authoring AWS Glue DataBrew now supports writing prepared data directly into JDBC-supported destinations AWS Glue DataBrew adds the ability to specify which data quality statistics are generated for your datasets AWS Glue DataBrew now supports numerical format transformations AWS Glue DataBrew now supports writing prepared data into AWS Lake Formation-based AWS Glue Data Catalog S3 tables Snow Family AWS Snowball Edge Storage Optimized devices now supports high performance NFS data transfer AWS Snow Family now enables you to remotely monitor and operate your connected Snowcone devices AWS Snowball now supports multicast streams and routing by providing instances with direct access to external networks AWS Snowcone now supports multicast streams and routing by providing instances with direct access to external networks AI & ML Amazon Textract announces improvements to detection of handwritten text, digits, dates, and phone numbers Amazon Textract announces specialized support for automated processing of invoices and receipts Announcing Model Variable Importance for Amazon Fraud Detector AWS customers can now view all the labels supported by Amazon Rekognition Amazon Neptune ML is now generally available with support for edge predictions, automation, and more Amazon EC2 Inf1 instances now supports TensorFlow 2 SageMaker Amazon announces new AWS Deep Learning Containers to deploy Hugging Face models faster on Amazon SageMaker Amazon SageMaker Pipeline introduces a automatic hyperparameter tuning step Amazon SageMaker Autopilot and Automatic Model Tuning now support more refined access control using Condition Key Policies Amazon SageMaker now supports M5d, R5, P3dn, and G4dn instances for SageMaker Notebook Instances Amazon SageMaker Pipelines now supports invoking AWS Lambda Functions Amazon SageMaker notebook instance now supports Amazon Linux 2 Introducing Amazon SageMaker Asynchronous Inference, a new inference option for workloads with large payload sizes and long inference processing times Kendra Announcing Amazon Kendra Smaller Units and Price Drop Amazon Kendra releases Web Crawler to enable web site search Amazon Kendra releases Principal Store for secure search Amazon Kendra releases WorkDocs Connector Other Cool Stuff IoT AWS IoT SiteWise is expanding its transforms and formula expressions capabilities AWS IoT SiteWise Edge now generally available AWS SiteWise now supports custom time intervals for metric aggregations Announcing support for new Timestamp function, PreTrigger function and ability to write nested expressions within aggregation functions (SiteWise) Announcing support for exporting data from AWS IoT SiteWise to Amazon S3 The rest The Amazon Chime SDK adds media capture pipelines to enable capture of meeting video, audio, and content streams Amazon AppStream 2.0 adds support for real-time audio-video using a web browser AWS Now Allows Customers To Pay For Their Usage in Advance AWS Organizations increases quotas for tag policies AWS DeepRacer announces DeepRacer LIVE races Amazon HealthLake is now Generally Available Introducing AWS for Health Introducing Amazon Route 53 Application Recovery Controller | AWS News Blog CloudFormation templates for Amazon Route 53 Application Recovery Controller (ARC) - GitHub Amazon CloudWatch adds support for trimmed mean statistics Amazon WorkSpaces now offers web access with WorkSpaces Streaming Protocol (WSP) Amazon WorkSpaces Renews Windows Desktop Experience with Windows Server 2019 bundles and 64-bit Microsoft Office 2019 Fully customizable action space now available in AWS DeepRacer Console Sponsors CMD Solutions Silver Sponsors Cevo Versent

¿Qué es el Sandbox financiero de España? ¿Qué es una estrategia a Corto? Proceso de verificación de la firma de un mensaje con el criptosistema ECDSA con la colaboración de Raúl López, Guillermo Abellán y Raúl Jaime Guillermo Abellán es Licenciado en Economía, experiencia de 18 años como Directivo del grupo Banco Santander, en 2014 crea plataforma de Equity Crowdfunding con algoritmo y scoring de riesgos.Desde 2017 promueve el ecosistema cripto es fundador de La Ola Blockchain, DeFi Lab DAO (laboratorio de finanzas descentralizadas). Ademas es embajador de BUIDLnetwork red apoyada por Consensys. Redes sociales de DeFi Lab: → Website: https://www.defilab.es/​ → Telegram: https://t.me/DeFi_Lab​ → Twitter: https://twitter.com/DeFi_Lab​ → YouTube: https://www.youtube.com/c/DeFiLabDAO​ Redes sociales Guillermo Abellán → Twitter: https://twitter.com/AbeBere​ → Linkedin: https://www.linkedin.com/in/guillermoabellanberenguer/ Raúl Jaime, Director académico en Algoritmia – Instituto Europea de formación Tecnológica. Licenciado en Administración y Dirección de Empresas por la Universitat Oberta de Catalunya. Executive-MBA por la Universidad de Barcelona y Executive MBA en Dirección financiera por EADA. Actualmente Doctorando en Ciencias de la Computación (línea de investigación blockchain) en la Universidad Internacional de Rioja. Autor del libro «El libro verde del emprendedor colaborativo» y del libro «Emprendedor social. Redes sociales Algoritmia – Instituto Europeo de formación Tecnológica → Website:https://algoritmia.institute/​ → Twitter: https://twitter.com/AlgoritmiaT​ → Linkedin: https://www.linkedin.com/company/algoritmia-instituto-europeo-de-formacion-tecnologica/ Redes sociales Raúl Jaime → Twitter: https://twitter.com/ruljaimemaestre​ → Linkedin: https://www.linkedin.com/in/rauljaimemaestre/ Redes sociales Coinmotion → Website:https://coinmotion.com/es/​ → Twitter: https://twitter.com/Coinmotion_es​ → Linkedin: https://www.linkedin.com/company/coinmotion-spain/​ Redes sociales Raúl López → Twitter: https://twitter.com/raullopezgn​ → Linkedin: https://www.linkedin.com/in/lopezraul/ Territorio Bitcoin → Website: https://www.territoriobitcoin.com/​ → Twitter: https://twitter.com/territoriobtc​ → Linkedin: https://www.linkedin.com/company/territorio-bitcoin/ 1 Minuto es un programa que te cuenta toda la actualidad de una forma diferente Noticias, Economía, Finanzas, Información financiera y de mercado, Medios de pago, Bitcoin, Blockchain, DEFI, Fintech, NeoBancos Presentamos una nueva forma de conocer toda la actualidad. Todo esto en 1 minuto o menos. De la mano de los mejores expertos seleccionados por Territorio Bitcoin con un solo objetivo: Ofrecer información relevante apostando como siempre por contenidos propios y de calidad.

Pasos firma mensaje criptosistema ECDSA – 5 variables a tener en cuenta más allá de la rentabilidad con la colaboración de Raúl Jaime y Guillermo Abellán Guillermo Abellán es Licenciado en Economía, experiencia de 18 años como Directivo del grupo Banco Santander, en 2014 crea plataforma de Equity Crowdfunding con algoritmo y scoring de riesgos.Desde 2017 promueve el ecosistema cripto es fundador de La Ola Blockchain, DeFi Lab DAO (laboratorio de finanzas descentralizadas). Ademas es embajador de BUIDLnetwork red apoyada por Consensys. Redes sociales de DeFi Lab: → Website: https://www.defilab.es/​ → Telegram: https://t.me/DeFi_Lab​ → Twitter: https://twitter.com/DeFi_Lab​ → YouTube: https://www.youtube.com/c/DeFiLabDAO​ Redes sociales Guillermo Abellán → Twitter: https://twitter.com/AbeBere​ → Linkedin: https://www.linkedin.com/in/guillermoabellanberenguer/ Raúl Jaime, Director académico en Algoritmia – Instituto Europea de formación Tecnológica. Licenciado en Administración y Dirección de Empresas por la Universitat Oberta de Catalunya. Executive-MBA por la Universidad de Barcelona y Executive MBA en Dirección financiera por EADA. Actualmente Doctorando en Ciencias de la Computación (línea de investigación blockchain) en la Universidad Internacional de Rioja. Autor del libro «El libro verde del emprendedor colaborativo» y del libro «Emprendedor social. Redes sociales Algoritmia – Instituto Europea de formación Tecnológica → Website:https://algoritmia.institute/​ → Twitter: https://twitter.com/AlgoritmiaT​ → Linkedin: https://www.linkedin.com/company/algoritmia-instituto-europeo-de-formacion-tecnologica/ Redes sociales Raúl Jaime → Twitter: https://twitter.com/ruljaimemaestre​ → Linkedin: https://www.linkedin.com/in/rauljaimemaestre/ Territorio Bitcoin → Website: https://www.territoriobitcoin.com/​ → Twitter: https://twitter.com/territoriobtc​ → Linkedin: https://www.linkedin.com/company/territorio-bitcoin/ 1 Minuto es un programa que te cuenta toda la actualidad de una forma diferente Noticias, Economía, Finanzas, Información financiera y de mercado, Medios de pago, Bitcoin, Blockchain, DEFI, Fintech, NeoBancos Presentamos una nueva forma de conocer toda la actualidad. Todo esto en 1 minuto o menos. De la mano de los mejores expertos seleccionados por Territorio Bitcoin con un solo objetivo: Ofrecer información relevante apostando como siempre por contenidos propios y de calidad.

Ventajas e inconvenientes DeFi sobre ETH o BSC – El proceso de firma con el criptosistema ECDSA con la colaboración de Guillermo Abellán y Raúl Jaime Guillermo Abellán es Licenciado en Economía, experiencia de 18 años como Directivo del grupo Banco Santander, en 2014 crea plataforma de Equity Crowdfunding con algoritmo y scoring de riesgos.Desde 2017 promueve el ecosistema cripto es fundador de La Ola Blockchain, DeFi Lab DAO (laboratorio de finanzas descentralizadas). Ademas es embajador de BUIDLnetwork red apoyada por Consensys. Redes sociales de DeFi Lab: → Website: https://www.defilab.es/​ → Telegram: https://t.me/DeFi_Lab​ → Twitter: https://twitter.com/DeFi_Lab​ → YouTube: https://www.youtube.com/c/DeFiLabDAO​ Redes sociales Guillermo Abellán → Twitter: https://twitter.com/AbeBere​ → Linkedin: https://www.linkedin.com/in/guillermoabellanberenguer/ Raúl Jaime, Director académico en Algoritmia – Instituto Europea de formación Tecnológica. Licenciado en Administración y Dirección de Empresas por la Universitat Oberta de Catalunya. Executive-MBA por la Universidad de Barcelona y Executive MBA en Dirección financiera por EADA. Actualmente Doctorando en Ciencias de la Computación (línea de investigación blockchain) en la Universidad Internacional de Rioja. Autor del libro «El libro verde del emprendedor colaborativo» y del libro «Emprendedor social. Redes sociales Algoritmia – Instituto Europea de formación Tecnológica → Website:https://algoritmia.institute/​ → Twitter: https://twitter.com/AlgoritmiaT​ → Linkedin: https://www.linkedin.com/company/algoritmia-instituto-europeo-de-formacion-tecnologica/ Redes sociales Raúl Jaime → Twitter: https://twitter.com/ruljaimemaestre​ → Linkedin: https://www.linkedin.com/in/rauljaimemaestre/ Territorio Bitcoin → Website: https://www.territoriobitcoin.com/​ → Twitter: https://twitter.com/territoriobtc​ → Linkedin: https://www.linkedin.com/company/territorio-bitcoin/ 1 Minuto es un programa que te cuenta toda la actualidad de una forma diferente Noticias, Economía, Finanzas, Información financiera y de mercado, Medios de pago, Bitcoin, Blockchain, DEFI, Fintech, NeoBancos Presentamos una nueva forma de conocer toda la actualidad. Todo esto en 1 minuto o menos. De la mano de los mejores expertos seleccionados por Territorio Bitcoin con un solo objetivo: Ofrecer información relevante apostando como siempre por contenidos propios y de calidad.

Criptosistema ECDSA - 1 Minuto Blockchain DeFi con la colaboración de Raúl Jaime Maestre

In this week’s episode, we chat with Omer Shlomovits (https://www.omershlomovits.com/) from ZenGo Wallet (https://zengo.com/) about MPC, threshold cryptography and how the research around this topic can be used in a blockchain context. We reference the Zero Knowledge Podcast Episode 90 with Nigel Smart (https://www.zeroknowledge.fm/90). Here are some additional links to check out: * ZenGo X (https://zengo.com/research/) * Flaws Could Have Exposed Cryptocurrency Exchanges to Hackers (https://www.wired.com/story/cryptocurrency-exchanges-key-flaws-hackers/) presented at Blackhat USA * Omer’s work on Diogenes (https://medium.com/zengo/dogbyte-attack-playing-red-team-for-eth2-0-vdf-ea2b9b2152af) * Survey of threshold ECDSA (https://eprint.iacr.org/2020/1390.pdf) * MPC Alliance (https://www.mpcalliance.org) * JugglingSwap: Scriptless Atomic Cross-Chain Swaps (https://arxiv.org/abs/2007.14423) * CryptoWills: How to Bequeath Cryptoassets (https://ieeexplore.ieee.org/document/9229848) Thanks to this week’s sponsor Least Authority (https://leastauthority.com/). If you are skilled in the area of zero-knowledge protocols and other advanced cryptography for scalability and privacy enhancing tech, you should get in contact with them. They currently have an open security auditor position see more at leastauthority.com/careers (https://leastauthority.com/careers/) You can also find the Gitcoin grants here: Least Authority’s Grant for the Moon Math Manual -> https://gitcoin.co/grants/543/the-moonmath-manual-to-zk-snarks Zero Knowledge Podcast -> https://gitcoin.co/grants/329/zero-knowledge-podcast If you like what we do: Follow us on Twitter - @zeroknowledgefm (https://twitter.com/zeroknowledgefm) Join us on Telegram (https://t.me/joinchat/B_81tQ57-ThZg8yOSx5gjA) Catch us on Youtube (https://www.youtube.com/channel/UCYWsYz5cKw4wZ9Mpe4kuM_g) Read up on the r/ZKPodcast subreddit (https://www.reddit.com/r/zkpodcast) Give us feedback! -https://forms.gle/iKMSrVtcAn6BByH6A Support our Gitcoin Grant (https://gitcoin.co/grants/329/zero-knowledge-podcast) Support us on the ZKPatreon (https://www.patreon.com/zeroknowledge) Or directly here: ETH: 0xC0FFEE1B5083230a5154F55f253B6b6ae8F29B1a BTC: 1cafekGa3podM4fBxPSQc6RCEXQNTK8Zz ZEC: t1R2bujRF3Hzte9ALHpMJvY8t5kb9ut9SpQ

Elliptic-curve signatures have become a highly used cryptographic primitive in secure messaging, TLS as well as in cryptocurrencies due to their high speed benefits over more traditional signature schemes. However, virtually all signature schemes are known to be susceptible to misuse, especially when information about the nonce is leaked to an attacker. LadderLeak is a new attack that exploits side channels present in ECDSA, claiming to allow real-world breaking of ECDSA with less than a bit of nonce leakage. But what does “less than a bit” mean in this context? Is LadderLeak really that effective at breaking ECDSA, with so little information to go on? Joining us this episode are LadderLeak co-authors Akira Takahashi, Mehdi Tibouchi and Yuval Yarom to discuss these questions and more. Links and papers discussed in the show: * LadderLeak: Breaking ECDSA With Less Than One Bit Of Nonce Leakage (https://eprint.iacr.org/2020/615) Music composed by Toby Fox and performed by Sean Schafianski (https://seanschafianski.bandcamp.com/). Special Guests: Akira Takahashi, Mehdi Tibouchi, and Yuval Yarom.

• ¿Quién avalará la propiedad privada en una #Blockchain? • El voto utilizando Blockchain,... ¿evitaría la #corrupción? • ¿Podría afectar la #computacióncuántica cuando llegue al sistema de #encripción ECDSA de #Bitcoin? ¿Qué es Bitcoin? Mini curso gratuito de los fundamentos de #Bitcoin. https://QueEsBitcoin.co • Resumen semanal de mercados con JuanSE NL. Para más detalles visita: https://juansebot.com/c/avanzado/?promo=2 • ¿Es posible que un gobierno persiga la dirección de una billetera, restrinja de algún modo o prohíba? Opsec: Seguridad de Criptoactivos https://criptomonedastv.com/producto/seminario-opsec Este es un resumen semanal de nuestras transmisiones en vivo. Puedes participar con tus preguntas Lunes a Viernes a las 2:00 PM (Centro USA) Version #podcast en Anchor: https://anchor.fm/criptomonedastv Intercambios #cripto a cripto con comisiones muy competitivas gracias a nuestra colaboración con Coinswitch https://exchange.criptomonedastv.com/ Síguenos también en: Twitch: https://www.twitch.tv/criptomonedastv Periscope: https://www.periscope.tv/CriptoMonedasTV Minds https://www.minds.com/criptomonedastv?referrer=criptomonedastv Telegram: https://t.me/criptomonedastvcom LBRY: https://lbry.tv/$/invite/CwjMVs6xzKY4pVZnPt4vQ6jiDdKtNe7u D.tube https://d.tube/#!/c/criptomonedastv Bitchute https://www.bitchute.com/channel/a0wO4KeEFcuo/ Guarda tus Bitcoins de forma segura: Trezor - https://criptomonedastv.com/ir/trezor Ledger Nano - https://criptomonedastv.com/ir/ledgernano BitBox v 2.0 - https://criptomonedastv.com/ir/bitbox ColdCard y Open Dime - https://criptomonedastv.com/ir/coldcard CryptoSteel - https://criptomonedastv.com/ir/cryptosteel KeepKey - https://criptomonedastv.com/ir/keepkey

Those who have been in crypto long enough remember the not-so-good-ol’ days when an air-gapped machine was the only way to store private keys securely. Thankfully, the wallet space has come a long way from that era. But we still live in a world where the seed phrase is the single atomic point of failure. Enter threshold signatures schemes (TSS), a multi-party computation (MPC) where different parties generate a key and are all required to create a valid signature. We’re joined by Omer Shlomovits and Ouriel Ohayon, Co-founders of ZenGo. Their product is a ‘keyless’ crypto wallet, which means users never need to generate or store a key which gives them access to their funds. Keys are created with an MPC, where both ZenGo and the user are required to sign a transaction. TTS opens up exciting new possibilities like social recovery, user permissions for teams, and inheritance planning schemes. The important distinction between ZenGo and existing multi-signature wallets is that they achieve this using only cryptography, and do not rely on on-chain elements like smart contracts or op_scriptSig in Bitcoin.Topics covered in this episode:- Omer and Ouriel’s respective backgrounds in academia and online consumer-facing products- What lead them to want to build yet another crypto wallet- The state of custody in the crypto wallet ecosystem and the challenge which remain unaddressed- A quick refresh on cryptographic primitives and multi-party computations (MPC)- The building blocks of cryptographic signatures and threshold signature schemes (TSS)- How TSS is different from Bitcoin multi-sig and smart contract multi-sig- TSS in ECDSA vs. Schnorr signatures- Applications and use cases for TSS- ZenGo’s on-boarding, restore process and use of biometrics- The future of wallet interoperability in a world of proprietary cryptographic schemesEpisode links: - [ZenGo: Bitcoin & Cryptocurrency Wallet](https://zengo.com)- [‎ZenGo: Bitcoin & Crypto Wallet on the App Store](https://Zengo.com/enjoy)- [Threshold Signatures Explained](https://www.binance.vision/security/threshold-signatures-explained)- [ShareLock: Mixing for Cryptocurrencies from Multiparty ECDSA](https://eprint.iacr.org/2019/563.pdf)- [KZen Networks on GitHub](https://github.com/KZen-networks)- [Zengo Research](https://zengo.com/research/)- [KZen Research Telegram Group](https://t.me/kzen_research)- [Tel Aviv Blockchain Week Recap with Anna Rose of the Zero Knowledge Podcast](https://www.youtube.com/watch?v=ccywXWTSFKM)Sponsors: - Vaultoro: Trade gold to Bitcoin instantly and securely starting at just 1mg - http://vaultoro.com- Trail of Bits: Trust the team at the forefront of blockchain security research - https://trailofbits.comThis episode is hosted by Sebastien Couture & Brian Fabian Crain. Show notes and listening options: [epicenter.tv/306](https://epicenter.tv/306)

Today's episode Corey and Collin bring on Andrew Poelstra, a mathematician and Director of Research at Blockstream. The guys dive straight into ECDSA vs Schnorr signatures, its history, and their future in crypto systems. They talk about Mimble Wimble, and how it bled into upcoming massive improvements of the Bitcoin protocol. Lots of great stuff to sink your teeth into this episode so we go a bit longer than usual. Enjoy the show! Links: Monero Monitor - Mimble Wimble Blockstream Andrew's Github Donate: https://donate.hashingitout.stream

Today's episode Corey and Collin bring on Andrew Poelstra, a mathematician and Director of Research at Blockstream. The guys dive straight into ECDSA vs Schnorr signatures, its history, and their future in crypto systems. They talk about Mimble Wimble, and how it bled into upcoming massive improvements of the Bitcoin protocol. Lots of great stuff to sink your teeth into this episode so we go a bit longer than usual. Enjoy the show! Links: Monero Monitor - Mimble Wimble Blockstream Andrew's Github Donate: https://donate.hashingitout.stream

OpenBSD 6.5 has been released, mount ZFS datasets anywhere, help test upcoming NetBSD 9 branch, LibreSSL 2.9.1 is available, Bail Bond Denied Edition of FreeBSD Mastery: Jails, and one reason ed(1) was a good editor back in the days in this week’s episode. Headlines OpenBSD 6.5 Released Changelog Mirrors 6.5 Includes OpenSMTPD 6.5.0 LibreSSL 2.9.1 OpenSSH 8.0 Mandoc 1.14.5 Xenocara LLVM/Clang 7.0.1 (+ patches) GCC 4.2.1 (+ patches) and 3.3.6 (+ patches) Many pre-built packages for each architecture: aarch64: 9654 amd64: 10602 i386: 10535 Mount your ZFS datasets anywhere you want ZFS is very flexible about mountpoints, and there are many features available to provide great flexibility. When you create zpool maintank, the default mountpoint is /maintank. You might be happy with that, but you don’t have to be content. You can do magical things. Some highlights are: mount point can be inherited not all filesystems in a zpool need to be mounted each filesystem (directory) can have different ZFS characteristics In my case, let’s look at this new zpool I created earlier today and I will show you some very simple alternatives. This zpool use NVMe devices which should be faster than SSDs especially when used with multiple concurrent writes. This is my plan: run all the Bacula regression tests concurrently. News Roundup Branch for netbsd 9 upcoming, please help and test -current Folks, once again we are quite late for branching the next NetBSD release (NetBSD 9). Initially planned to happen early in February 2019, we are now approaching May and it is unlikely that the branch will happen before that. On the positive side, lots of good things landed in -current in between, like new Mesa, new jemalloc, lots of ZFS improvements - and some of those would be hard to pull up to the branch later. On the bad side we saw lots of churn in -current recently, and there is quite some fallout where we not even have a good overview right now. And this is where you can help: please test -current, on all the various machines you have especially interesting would be test results from uncommon architectures or strange combinations (like the sparc userland on sparc64 kernel issue I ran in yesterday) Please test, report success, and file PRs for failures! We will likely announce the real branch date on quite short notice, the likely next candidates would be mid may or end of may. We may need to do extra steps after the branch (like switch some architectures back to old jemalloc on the branch). However, the less difference between -current and the branch, the easier will the release cycle go. Our goal is to have an unprecedented short release cycle this time. But.. we always say that upfront. LibreSSL 2.9.1 Released We have released LibreSSL 2.9.1, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. This is the first stable release from the 2.9 series, which is also included with OpenBSD 6.5 It includes the following changes and improvements from LibreSSL 2.8.x: API and Documentation Enhancements CRYPTO_LOCK is now automatically initialized, with the legacy callbacks stubbed for compatibility. Added the SM3 hash function from the Chinese standard GB/T 32905-2016. Added the SM4 block cipher from the Chinese standard GB/T 32907-2016. Added more OPENSSLNO* macros for compatibility with OpenSSL. Partial port of the OpenSSL ECKEYMETHOD API for use by OpenSSH. Implemented further missing OpenSSL 1.1 API. Added support for XChaCha20 and XChaCha20-Poly1305. Added support for AES key wrap constructions via the EVP interface. Compatibility Changes Added pbkdf2 key derivation support to openssl(1) enc. Changed the default digest type of openssl(1) enc to sha256. Changed the default digest type of openssl(1) dgst to sha256. Changed the default digest type of openssl(1) x509 -fingerprint to sha256. Changed the default digest type of openssl(1) crl -fingerprint to sha256. Testing and Proactive Security Added extensive interoperability tests between LibreSSL and OpenSSL 1.0 and 1.1. Added additional Wycheproof tests and related bug fixes. Internal Improvements Simplified sigalgs option processing and handshake signing algorithm selection. Added the ability to use the RSA PSS algorithm for handshake signatures. Added bnrandinterval() and use it in code needing ranges of random bn values. Added functionality to derive early, handshake, and application secrets as per RFC8446. Added handshake state machine from RFC8446. Removed some ASN.1 related code from libcrypto that had not been used since around 2000. Unexported internal symbols and internalized more record layer structs. Removed SHA224 based handshake signatures from consideration for use in a TLS 1.2 handshake. Portable Improvements Added support for assembly optimizations on 32-bit ARM ELF targets. Added support for assembly optimizations on Mingw-w64 targets. Improved Android compatibility Bug Fixes Improved protection against timing side channels in ECDSA signature generation. Coordinate blinding was added to some elliptic curves. This is the last bit of the work by Brumley et al. to protect against the Portsmash vulnerability. Ensure transcript handshake is always freed with TLS 1.2. The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible. FreeBSD Mastery: Jails – Bail Bond Denied Edition I had a brilliant, hideous idea: to produce a charity edition of FreeBSD Mastery: Jails featuring the cover art I would use if I was imprisoned and did not have access to a real cover artist. (Never mind that I wouldn’t be permitted to release books while in jail: we creative sorts scoff at mere legal and cultural details.) I originally wanted to produce my own take on the book’s cover art. My first attempt failed spectacularly. I downgraded my expectations and tried again. And again. And again. I’m pleased to reveal the final cover for FreeBSD Mastery: Jails–Bail Bond Edition! This cover represents the very pinnacle of my artistic talents, and is the result of literally hours of effort. But, as this book is available only to the winner of charity fund-raisers, purchase of this tome represents moral supremacy. I recommend flaunting it to your family, coworkers, and all those of lesser character. Get your copy by winning the BSDCan 2019 charity auction… or any other other auction-type event I deem worthwhile. As far as my moral fiber goes: I have learned that art is hard, and that artists are not paid enough. And if I am ever imprisoned, I do hope that you’ll contribute to my bail fund. Otherwise, you’ll get more covers like this one. One reason ed(1) was a good editor back in the days of V7 Unix It is common to describe ed(1) as being line oriented, as opposed to screen oriented editors like vi. This is completely accurate but it is perhaps not a complete enough description for today, because ed is line oriented in a way that is now uncommon. After all, you could say that your shell is line oriented too, and very few people use shells that work and feel the same way ed does. The surface difference between most people's shells and ed is that most people's shells have some version of cursor based interactive editing. The deeper difference is that this requires the shell to run in character by character TTY input mode, also called raw mode. By contrast, ed runs in what Unix usually calls cooked mode, where it reads whole lines from the kernel and the kernel handles things like backspace. All of ed's commands are designed so that they work in this line focused way (including being terminated by the end of the line), and as a whole ed's interface makes this whole line input approach natural. In fact I think ed makes it so natural that it's hard to think of things as being any other way. Ed was designed for line at a time input, not just to not be screen oriented. This input mode difference is not very important today, but in the days of V7 and serial terminals it made a real difference. In cooked mode, V7 ran very little code when you entered each character; almost everything was deferred until it could be processed in bulk by the kernel, and then handed to ed all in a single line which ed could also process all at once. A version of ed that tried to work in raw mode would have been much more resource intensive, even if it still operated on single lines at a time. Beastie Bits CFT for FreeBSD ZoL Simple DNS Adblock AT&T Unix PC in 1985 OpenBSD-current drm at 4.19, includes new support for Intel GPUs like Coffee Lake "What are the differences between Linux and OpenBSD?" - Twitter thread Announcing the pkgsrc-2019Q1 release (2019-04-10) Feedback/Questions Brad - iocage Frank - Video from Level1Tech and a question Niall - Revision Control Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv Your browser does not support the HTML5 video tag.

Tone worked on Wall Street for almost 10 years starting as a Risk Analyst at Bear Stearns and later becoming a VP at JP Morgan Chase, in the aftermath of the 2008 financial crisis. His expertise is in Economic Trends, Trading and Risk Analysis. Ever since getting involved in the Crypto Currency ecosystem in early 2013, he has been very active in spreading the relevance and importance of this technology as it helps promote economic freedom. Tone has been featured in several Documentaries like Magic Money & Bitcoin - Beyond the Bubble. Tone is now an independent content creator at ToneVays.com and on his YouTube Channel focused on sound economics & finance. Tone holds a Masters Degree in Financial Engineering from Florida State University along with Bachelor Degrees in Mathematics and Geology.Twitter: https://twitter.com/ToneVaysWebsite: https://tonevays.comTrading Information: http://LibertyLifeTrail.comFollow the podcast on Telegram!https://t.me/ToneVaysPodcastBotBitcoin: 3Hk9cR6p8XAAbmD2GkvSdcbznhqXvLDX4oLearn Trading: http://www.libertylifetrail.com/education/learntrading/Upcoming Seminars: https://tonevays.com/workshopsPrivate Consulting: http://www.libertylifetrail.com/consulting/Please Support via Affiliate Codes:Trading View: http://tradingview.go2cloud.org/aff_c?offer_id=2&aff_id=4905&url_id=3BitMex 10% Off: https://www.bitmex.com/register/cMvHXgTrezor/Ledger: https://www.cryptohwwallet.com/?acc=70efdf2ec9b086079795c442636b55fb&bannerid=3TorGuard VPN 50% off code & link = tone50: https://torguard.net/aff.php?aff=3782Buy The Dip Store 20% Off: http://sh1030.ositracker.com/75271/6304CryptoMatic Bitcoin Watch: Discount Code = TONEhttps://cryptomatic.io/en/1Broker: https://1broker.com/?r=14766Magic Money Film: Vimeo Discount Code = TONEhttp://www.magicmoneyfilm.com/Disclaimer: The 1Broker & BitMex affiliate links are to be used at your own risk, I mostly use them to just place trades for less than $100 and I'm ready for all my bitcoins being hacked. (best is to always hold your own keys)Tone Vays is available for consulting at the rate of 0.1 btc per hour. Please email Tone@protonmail.ch for additional info.Follow the best podcasts from the best minds in the Bitcoin and Cryptocurrency space on twitter.https://twitter.com/bitcoinpodcasts

Listen to WCN Audio Podcasts:https://itunes.apple.com/us/podcast/world-crypto-network/id825708806?mt=2Call Us LIVE!SKYPE WorldCryptoNetworkTrack the Mayer Multiple on WCN: https://www.worldcryptonetwork.com/priceCheck out the brand new http://WorldCryptoNetwork.com/Follow WCN on Twitter:https://twitter.com/WorldCryptoNetSubscribe to the WCN YouTube Channel and participate in the live chat!https://www.youtube.com/user/WorldCryptoNetworkFollow the best podcasts from the best minds in the Bitcoin and Cryptocurrency space on twitter.https://twitter.com/bitcoinpodcasts

This episode of LAB Radio was a part of our coverage of CryptoBlockcon where Chris Groshong interviewed Adam Koltun, Lead Business Strategist of Quantum Resistant Ledger (QRL). Chris Groshong (left), CEO of CoinStructive Inc, and Adam Koltun (right), Lead Business Strategist of Quantum Resistant Ledger (QRL) As Adam so eloquently put it in their recap blog post, the conference itself was a cornucopia of very different industries squished together in an expansive venue: "The event was held at the Mandalay Bay Resort and Casino. In addition to CBC, the MLB Winter Meetings, and a National Finals Rodeo competition was being held nearby, so many of the competitors were staying at Mandalay Bay. Certainly, literal cowboys, baseball executives and blockchain enthusiasts rubbing shoulders made for some interesting juxtapositions. As much as those of us within the industry can sometimes get weary of terms like “adoption” or “mainstream” or “awareness” — moments like these serve as an eloquent reminder, to me, that blockchain/cryptocurrency are still completely unknown to large swaths of American society, at least. It’s useful, I find, to sometimes recognize that for all the drama this space can sometimes produce, that in the long-run, these are minor speedbumps that will be hardly (if at all) remembered by the vast majority of crypto users within the next 10 years." As stated on their website: "The Quantum Resistant Ledger (QRL) is a first of its kind, future-proof post quantum value store and decentralized communication layer which tackles the threat Quantum Computing will pose to cryptocurrencies. This is backed by provably secure, peer-reviewed XMSS (instead of 256-bit ECDSA) with a proof-of-work(POW) algorithm, Cryptonight v7, which will later be hard forked to Proof of Stake." QRL aims to future proof the Blockchain from Quantum computing through peer-reviewed and proven precursors like Extended Merkle Signature Scheme (EMSS): "QRL provides a blockchain that is resistant to both conventional and quantum computing attacks. The future of the internet will be built on decentralized protocols and abstraction layers, and we plan on being ready for that future, as well as any sudden quantum computing development (“Y2Q”) that may usher in that reality sooner than expected. Our blockchain will utilize the previously vetted, provably secure Extended Merkle Signature Scheme (XMSS) to ensure that our network is resistant to quantum computing attacks. We aim to secure our network against not only the inevitability of quantum computing, and all that implies for the blockchain and cryptocurrency space, but also the potential for a black swan event to rapidly and irreversibly advance the technology with no immediate warning. By utilizing an address format that allows us to change hash functions down the line if necessary, we have created a blockchain that is both secure today and adaptable tomorrow." For show notes and more visit: LAB Radio

Welcome to episode 60 of The Bitcoin Game, I'm Rob Mitchell. I'm happy to bring to you part two of my interview with Cypherpunk and CEO of Blockstream, Dr. Adam Back. In this episode, we take a deep dive into Liquid, Blockstream's new federated sidechain. There's a lot more to Liquid than I realized, and it's fascinating to hear tons of details about the protocol. I lead us astray with some of my questions, but Dr. Back never fails to drop tons of crypto-knowledge. And if you missed the first part of my interview, give episode 59 a listen to hear a great Cypherpunk history lesson. EPISODE LINKS First half of our interview (The Bitcoin Game #59) https://letstalkbitcoin.com/blog/post/the-bitcoin-game-59-dr-adam-back Adam Back (Adam3us) on Twitter https://twitter.com/adam3us Dr. Back's Info Page http://www.cypherspace.org/adam Blockstream https://blockstream.com Lightning Network White Paper by Joseph Poon & Thaddeus Dryja https://lightning.network/lightning-network-paper.pdf Duplex Micropayment Channels by Christian Decker & Roger Wattenhofer https://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf ETHZ (where Christian Decker earned his Bitcoin PhD) https://www.ethz.ch/de.html Rusty Russell https://en.wikipedia.org/wiki/Rusty_Russell C-Lightning https://github.com/ElementsProject/lightning Liquid https://blockstream.com/liquid Liquid Assets https://blockstream.com/2018/07/02/liquid-issued-assets Confidential Transactions https://bitcoinmagazine.com/articles/confidential-transactions-how-hiding-transaction-amounts-increases-bitcoin-privacy-1464892525 ERC-20 https://en.wikipedia.org/wiki/ERC-20 Counterparty https://counterparty.io/docs/faq-xcp UTXO https://en.wikipedia.org/wiki/Unspent_transaction_output Bulletproofs https://crypto.stanford.edu/bulletproofs https://eprint.iacr.org/2017/1066.pdf Tether https://en.wikipedia.org/wiki/Tether_(cryptocurrency) Proof of Burn https://www.coinbureau.com/education/proof-of-burn-explained Public Key vs. Public Address https://www.reddit.com/r/Bitcoin/comments/3filud/whats_the_difference_between_public_key_and Lamport Signatures https://en.wikipedia.org/wiki/Lamport_signature The Byzantine Generals Problem https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf Schnorr Signatures https://en.wikipedia.org/wiki/Schnorr_signature ECDSA https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm Denial-of-Service Attack https://en.wikipedia.org/wiki/Denial-of-service_attack Tor https://www.torproject.org Liquid Block Explorer https://blockstream.com/2018/08/02/accelerating-liquid-adoption-liquid-block-explorer NBitcoin by Nicolas Dorier https://www.codeproject.com/Articles/768412/NBitcoin-The-most-complete-Bitcoin-port-Part-Crypt Green Address Wallet https://greenaddress.it KYC Compliance https://en.wikipedia.org/wiki/Know_your_customer Paul Sztorc talks about Sidechains, Drivechain, Liquid https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-377-sidechains-drivechains-and-the-apple-store RootStock https://en.wikipedia.org/wiki/RootStock Spark Lightning Wallet by Nadav Ivgi https://bitcoinmagazine.com/articles/spark-new-gui-lightning-wallet-bitcoin-now-available-download Lightning Splice-In, Splice Out (and more) https://medium.com/@pierre_rochard/day-2-of-the-chaincode-labs-lightning-residency-669aecab5f16 SPV Wallet https://en.bitcoinwiki.org/wiki/Simplified_Payment_Verification Neutrino Lite Bitcoin Client https://github.com/lightninglabs/neutrino/blob/master/README.md Lightning Watchtower https://www.coindesk.com/laolu-building-watchtower-fight-bitcoin-lightning-fraud/ ABCore by Lawrence Nahum (BTC full node on Android) https://play.google.com/store/apps/details?id=com.greenaddress.abcore Hardware Wallet https://en.bitcoin.it/wiki/Hardware_wallet STAY IN TOUCH Thanks so much for taking the time to listen to The Bitcoin Game! https://Twitter.com/TheBTCGame http://TheBitcoinGame.com Rob@TheBitcoinGame.com SPONSORS BTC Inc is excited to announce its upcoming conference, Distributed Health, November 5 & 6 in Nashville, TN. This is the first conference to bridge the gap between blockchain technology and the healthcare industry. Now in its third year, this two-day event is an opportunity for all members of the ecosystem, including payers, providers, law makers, retailers, investors and innovators, to reshape the future of healthcare. For more information, visit: health.distributed.com and use the promo code: BTCGAME20 to secure a 20% discount! While much of a Bitcoiner's time is spent in the world of digital assets, sometimes it's nice to own a physical representation of the virtual things you care about. For just the price of a cup of coffee or two (at Starbucks), you can own the world famous Bitcoin Keychain. As Seen On The Guardian • TechCrunch • Engadget • Ars Technica • Popular Mechanics Inforwars • Maxim • Inc. • Vice • RT • Bitcoin Magazine • VentureBeat PRI • CoinDesk • Washington Post • Forbes • Fast Company Bitcoin Keychains - BKeychain.com CREDITS All music in this episode of The Bitcoin Game was created by Rob Mitchell. The Bitcoin Game box art was created from an illustration by Rock Barcellos. Bitcoin (Segwit) tipping address: 3AYvXZseExRn3Dum8z9tFUk9jtQK6KMU4g Note: We've recently migrated our RSS feed (and primary content host) from Soundcloud to Libsyn. So if you notice the Soundcloud numbers have dropped off recently, that's the reason.

Simon is with Anthony Macey, Martin Bartlam, Partner and International Group Head of Finance & Projects and Fintech Global Co-Chair at DLA Piper, Noelle Acheson, CFA and Editorial Producer at Coindesk, and Todd McDonald, Co-Founder and Head of Partnerships at R3, to go over the biggest blockchain stories of the week. First up the panel looks at crypto unicorn, Bitmain considering $18 Billion IPO, one of the world's largest. The cryptocurrency mining company is filing for an initial public offering (IPO) potentially as high as $18 billion this September at a market capitalization of $40 to $50 billion. Then they discuss Facebook's Marcus stepping down from Coinbase board. David Marcus is stepping down from the board of directors at cryptocurrency exchange Coinbase, citing his new assignment at Facebook leading the social media giant's blockchain strategy. Barclays denies crypto trading desk plans as staff removes ‘Digital Asset Project’ LinkedIn Info. Barclays told Cointelegraph that they have “no plans for a crypto trading desk.” As of press time, Duval and Tyrer’s LinkedIn profiles still show positions at Barclays working with 'digital assets,' but all information detailing the specifics of the jobs is not listed. Goldman Sachs, JPMorgan invest in Axoni's $32 Million funding round. Enterprise-focused blockchain startup Axoni has completed a $32 million Series B funding round led by Goldman Sachs and Nyca Partners. Also participating in the round were Andreessen Horowitz, Citi, JP Morgan, Wells Fargo, Y Combinator and Digital Currency Group, among others. R3 publishes a new post-quantum signature algorithm tailored to blockchains. Corda team has recently announced a new digital signature scheme that unlike RSA and ECDSA, it will remain secure even against a powerful quantum computer. The panel manage to explain quantum computing. Criminal activity in cryptocurrency has dropped 80% since 2013. An agent of the U.S. Drug Enforcement Administration (DEA) has noted that Bitcoin’s (BTC) role in crimes has dropped to just 10% of transactions, while transactions themselves have “grown tremendously”. We also have a Tweet of the Week on Ripple. All this and so much more on this week's episode of Blockchain Insider. And if you enjoyed our tweet of the week why not send us your best tweets? See if you can get a shout out on the show! We hope you enjoy the show and, as ever, don't forget to subscribe! Want to join the conversation on all the topics discussed? Tweet the show @bchaininsider and if you really love the show, please leave us a review on iTunes. This week's episode of Blockchain Insider was produced by Laura Watkins and Petrit Berisha. Edited by Holly Blaxill. Special Guests: Anthony Macey, Martin Bartlam, Noelle Acheson, and Todd McDonald.

Area41 Zurich report Book Club - 4th Tuesday of the month https://www.owasp.org/images/d/d3/TLS_v1.3_Overview_OWASP_Final.pdf   https://www.owasp.org/index.php/TLS_Cipher_String_Cheat_Sheet TLS_DHE_RSA_AES_256_GCM_SHA256   TLS = Protocol DHE = Diffie-Hellman ephemeral (provides Perfect Forward Secrecy)     Perfect Forward Secrecy = session keys won’t be compromised, even if server private keys are Past messages and data cannot be retrieved or decrypted (https://en.wikipedia.org/wiki/Forward_secrecy)   RSA = Digital Signature (authentication)     There are only 2 (RSA, or ECDSA)   AES_256_GCM - HMAC (hashed message authentication code)   https://www.owasp.org/index.php/TLS_Cipher_String_Cheat_Sheet https://en.wikipedia.org/wiki/HMAC#Definition_.28from_RFC_2104.29   https://en.wikipedia.org/wiki/Funicular   https://mozilla.github.io/server-side-tls/ssl-config-generator/?hsts=no   Join our #Slack Channel! Email us at bds.podcast@gmail.com or DM us on Twitter @brakesec #Spotify: https://brakesec.com/spotifyBDS #RSS: https://brakesec.com/BrakesecRSS #Youtube Channel:  http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://brakesec.com/BDSiTunes #Google Play Store: https://brakesec.com/BDS-GooglePlay Our main site:  https://brakesec.com/bdswebsite #iHeartRadio App:  https://brakesec.com/iHeartBrakesec #SoundCloud: https://brakesec.com/SoundcloudBrakesec Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast by using our #Paypal: https://brakesec.com/PaypalBDS OR our #Patreon https://brakesec.com/BDSPatreon #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://brakesec.com/BDS-PlayerFM #Stitcher Network: https://brakesec.com/BrakeSecStitcher #TuneIn Radio App: https://brakesec.com/TuneInBrakesec

BCoin is a bitcoin client which implements BIP-37. It can track transactions, public keys, and public key hashes (bitcoin addresses) without saving the entire blockchain to disk. This means you can have a wallet with a synchronized balance and send and receive payments without keeping track of a 20GB database. BCoin is implemented in pure javascript, and is browserify-able (this means compiling a binding to an ECDSA library is not even required for node.js). For us, the fact that peer to peer communication is not encrypted on the Bitcoin network seems like more of an oversight to me than anything else. They now have begun integrating the Lightning Network. It's called "blight". Purse.io takes over this episode as both Christopher Jeffrey (JJ) who is the CTO & Engineer at Purse and podcast regular Steven McKie join us in the studio. We continue to give you that mid-week goodness.

本期节目由 思客教学 赞助，思客教学 “专注 IT 领域远程学徒式” 教育。 本期由 Terry 主持, 请到了他的最好基友 Jan, 和他聊聊比特币背后的技术, 分布式系统, 算法以及Blockchain. Intridea Peatio ethfans LMAX Disruptor archlinux bspwm plan9 ranger Is bitcoinn a good idea? Merkle tree Linked list Hash List Mixing 椭圆曲线签名算法 (ECDSA) Checksum RSA Zerocash Zero-knowledge proof The Byzantine Generals Problem Leslie Lamport LaTeX TeX Donald Knuth Lamport signature PoW’s pros and cons PoS’s pros and cons DAO and DAC scrypt Proof-of-stake Vitalik Buterin Ethereum gollum Nick Szabo’s Smart Contracts Idea Bitcoin Script Special Guest: Jan.

Nicolas Courtois is a cryptographer and senior lecturer at University College London. He has been studying cryptocurrencies for some time and has written a number of papers on bitcoin. His talk is titled “Cryptographic Security of ECDSA in bitcoin” in which he exposes the security vulnerabilities in the specific variation of the Elliptic Curve digital Signature Algorithm used in bitcoin. Episode links: Slides for this presentation Nicolas Courtois’s Wikipedia Page Personal blog On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies paper Nicolas’s Bitcoin Publications This episode is hosted by Sébastien Couture. Show notes and listening options: epicenter.tv/050

This week on the show we'll be showing you how to set up RAID arrays in both FreeBSD and OpenBSD. There's also an interview with David Chisnall - of the FreeBSD core team - about the switch to Clang and a lot more. As usual, we'll be dropping the latest news and answering your emails, so sit back and enjoy some BSD Now - the place to B.. SD. This episode was brought to you by Headlines OpenBSD 5.5 released (http://www.openbsd.org/55.html) If you ordered (https://https.openbsd.org/cgi-bin/order) a CD set (https://twitter.com/blakkheim/status/461909893813784576) then you've probably had it for a little while already, but OpenBSD has formally announced the public release (http://undeadly.org/cgi?action=article&sid=20140501153339) of 5.5 This is one of the biggest releases to date, with a very long list of changes and improvements Some of the highlights include: time_t being 64 bit on all platforms, release sets and binary packages being signed with the new signify tool, a new autoinstall feature of the installer, SMP support on Alpha, a new AViiON port, lots of new hardware drivers including newer NICs, the new vxlan driver, relayd improvements, a new pf queue system for bandwidth shaping, dhcpd and dhclient fixes, OpenSMTPD 5.4.2 and all its new features, position-independent executables being default for i386, the RNG has been replaced with ChaCha20 as well as some other security improvements, FUSE support, tmpfs, softraid partitions larger than 2TB and a RAID 5 implementation, OpenSSH 6.6 with all its new features and fixes... and a lot more The full list of changes (http://www.openbsd.org/plus55.html) is HUGE, be sure to read through it all if you're interested in the details If you're doing an upgrade from 5.4 instead of a fresh install, pay careful attention to the upgrade guide (http://www.openbsd.org/faq/upgrade55.html) as there are some very specific steps for this version Also be sure to apply the errata patches (http://www.openbsd.org/errata55.html) on your new installations... especially those OpenSSL ones (some of which still aren't fixed (http://marc.info/?l=oss-security&m=139906348230995&w=2) in the other BSDs yet) On the topic of errata patches, the project is now going to also send them out (signed (http://undeadly.org/cgi?action=article&sid=20140502103355)) via the announce mailing list (http://lists.openbsd.org/cgi-bin/mj_wwwusr?user=&passw=&func=lists-long-full&extra=announce), a very welcome change Congrats to the whole team on this great release - 5.6 is going to be even more awesome with "Libre"SSL and lots of other stuff that's currently in development *** FreeBSD foundation funding highlights (http://freebsdfoundation.blogspot.com/2014/04/freebsd-foundation-spring-fundraising_28.html) The FreeBSD foundation posts a new update on how they're spending the money that everyone donates "As we embark on our 15th year of serving the FreeBSD Project and community, we are proud of what we've done to help FreeBSD become the most innovative, reliable, and high-performance operation system" During this spring, they want to highlight the new UEFI boot support and newcons (http://freebsdfoundation.blogspot.com/2014/05/freebsd-foundation-newcons-project.html) There's a lot of details about what exactly UEFI is and why we need it going forward FreeBSD has also needed some updates to its console to support UTF8 and wide characters Hopefully this series will continue and we'll get to see what other work is being sponsored *** OpenSSH without OpenSSL (http://marc.info/?l=openbsd-cvs&m=139879453001957&w=2) The OpenSSH team has been hard at work, making it even better, and now OpenSSL is completely optional Since it won't have access to the primitives OpenSSL uses, there will be a trade-off of features vs. security This version will drop support for legacy SSH v1, and the only two cryptographic algorithms supported are an in-house implementation of AES in counter mode and the new combination (http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?rev=HEAD;content-type=text%2Fplain) of the Chacha20 stream cipher with Poly1305 for packet integrity Key exchange is limited to elliptic curve Diffie-Hellman and the newer Curve25519 KEXs No support for RSA, DSA or ECDSA public keys - only Ed25519 It also includes a new buffer API (http://marc.info/?l=openbsd-cvs&m=139883582313750&w=2) and a set of wrappers to make it compatible with the existing API Believe it or not, this was planned before all the heartbleed craziness Maybe someday soon we'll have a mini-openssh-portable in FreeBSD ports and NetBSD pkgsrc, would be really neat *** BSDMag's April 2014 issue is out (http://bsdmag.org/magazine/1861-free-pascal-on-bsd-april-bsd-issue) The free monthly BSD magazine has got a new issue available for download This time the articles include: pascal on BSD, an introduction to revision control systems and configuration management, deploying NetBSD on AWS EC2, more GIMP tutorials, an AsiaBSDCon 2014 report and a piece about how easily credit cards are stolen online Anyone can contribute to the magazine, just send the editors an email about what you want to write No Linux articles this time around, good *** Interview - David Chisnall - theraven@freebsd.org (mailto:theraven@freebsd.org) The LLVM/Clang switch, FreeBSD's core team, various topics Tutorial RAID in FreeBSD and OpenBSD (http://www.bsdnow.tv/tutorials/raid) News Roundup BSDTalk episode 240 (http://bsdtalk.blogspot.com/2014/04/bsdtalk240-about-time-with-george.html) Our buddy Will Backman has uploaded a new episode of BSDTalk, this time with our other buddy GNN as the guest - mainly to talk about NTP and keeping reliable time Topics include the specific details of crystals used in watches and computers to keep time, how temperature affects the quality, different sources of inaccuracy, some general NTP information, why you might want extremely precise time, different time sources (GPS, satellite, etc), differences in stratum levels, the problem of packet delay and estimating the round trip time, some of the recent NTP amplification attacks, the downsides to using UDP instead of TCP and... much more GNN also talks a little about the Precision Time Protocol (https://en.wikipedia.org/wiki/Precision_Time_Protocol) and how it's different than NTP Two people (http://www.bsdnow.tv/episodes/2014_01_29-journaled_news_updates) we've interviewed (http://www.bsdnow.tv/episodes/2014_03_05-bsd_now_vs_bsdtalk) talking to each other, awesome If you're interested in NTP, be sure to see our tutorial (http://www.bsdnow.tv/tutorials/ntpd) too *** m2k14 trip reports (http://undeadly.org/cgi?action=article&sid=20140502092427) We've got a few more reports from the recent OpenBSD hackathon in Morocco The first one is from Antoine Jacoutot (who is a key GNOME porter and gave us the screenshots for the OpenBSD desktop tutorial (http://www.bsdnow.tv/tutorials/the-desktop-obsd)) "Since I always fail at actually doing whatever I have planned for a hackathon, this time I decided to come to m2k14 unprepared about what I was going to do" He got lots of work done with ports and pushing GNOME-related patches back up to the main project, then worked on fixing ports' compatibility with LibreSSL Speaking of LibreSSL, there's an article (http://undeadly.org/cgi?action=article&sid=20140505062023) all would-be portable version writers should probably read and take into consideration Jasper Adriaanse also writes (http://undeadly.org/cgi?action=article&sid=20140501185019) about what he got done over there He cleaned up and fixed the puppet port to work better with OpenBSD *** Why you should use FreeBSD on your cloud VPS (https://www.atlantic.net/blog/2014/04/08/freebsd-ssd-cloud-vps-hosting-10-reasons/) Here we have a blog post from Atlantic, a VPS and hosting provider, about 10 reasons for using FreeBSD Starts off with a little bit of BSD history for those who are unfamiliar with it and only know Linux and Windows The 10 reasons are: community, stability, collaboration, ease of use, ports, security, ZFS, GEOM, sound and having lots of options The post goes into detail about each of them and why FreeBSD makes a great choice for a VPS OS *** PCBSD weekly digest (http://blog.pcbsd.org/2014/05/weekly-feature-digest-27-software-system-redesign/) Big changes coming in the way PCBSD manages software The PBI system, AppCafe and related tools are all going to use pkgng now The AppCafe will no longer be limited to PBIs, so much more software will be easily available from the ports tree New rating system coming soon and much more *** Feedback/Questions Martin writes in (http://slexy.org/view/s21bk2oPuQ) John writes in (http://slexy.org/view/s2n9fx1Rpw) Alex writes in (http://slexy.org/view/s2rBBKLA4u) Goetz writes in (http://slexy.org/view/s20JY6ZI71) Jarrad writes in (http://slexy.org/view/s20YV5Ohpa) ***

This time on the show, we'll be showing you how to do a fully-encrypted installation of FreeBSD and OpenBSD. We also have an interview with Damien Miller - one of the lead developers of OpenSSH - about some recent crypto changes in the project. If you're into data security, today's the show for you. The latest news and all your burning questions answered, right here on BSD Now - the place to B.. SD. This episode was brought to you by Headlines Secure communications with OpenBSD and OpenVPN (http://johnchapin.boostrot.net/blog/2013/12/07/secure-comms-with-openbsd-and-openvpn-part-1/) Starting off today's theme of encryption... A new blog series about combining OpenBSD and OpenVPN to secure your internet traffic Part 1 covers installing OpenBSD with full disk encryption (which we'll be doing later on in the show) Part 2 covers the initial setup of OpenVPN certificates and keys Parts 3 and 4 are the OpenVPN server and client configuration Part 5 is some updates and closing remarks *** FreeBSD Foundation Newsletter (https://www.freebsdfoundation.org/press/2013Dec-newsletter) The December 2013 semi-annual newsletter was sent out from the foundation In the newsletter you will find the president's letter, articles on the current development projects they sponsor and reports from all the conferences and summits they sponsored The president's letter alone is worth the read, really amazing Really long, with lots of details and stories from the conferences and projects *** Use of NetBSD with Marvell Kirkwood Processors (http://evertiq.com/design/33394) Article that gives a brief history of NetBSD and how to use it on an IP-Plug computer The IP-Plug is a "multi-functional mini-server was developed by Promwad engineers by the order of AK-Systems. It is designed for solving a wide range of tasks in IP networks and can perform the functions of a computer or a server. The IP-Plug is powered from a 220V network and has low power consumption, as well as a small size (which can be compared to the size of a mobile phone charger)." Really cool little NetBSD ARM project with lots of graphs, pictures and details *** Experimenting with zero-copy network IO (http://adrianchadd.blogspot.com/2013/12/experimenting-with-zero-copy-network-io.html) Long blog post from Adrian Chadd about zero-copy network IO on FreeBSD Discusses the different OS' implementations and options He's able to get 35 gbit/sec out of 70,000 active TCP sockets, but isn't stopping there Tons of details, check the full post *** Interview - Damien Miller - djm@openbsd.org (mailto:djm@openbsd.org) / @damienmiller (https://twitter.com/damienmiller) Cryptography in OpenBSD and OpenSSH Tutorial Full disk encryption in FreeBSD & OpenBSD (http://www.bsdnow.tv/tutorials/fde) News Roundup OpenZFS office hours (https://www.youtube.com/watch?v=wWmVW2R_uz8) Our buddy George Wilson (http://www.bsdnow.tv/episodes/2013_12_04-zettabytes_for_days) sat down to take some ZFS questions from the community You can see more info about it here (http://open-zfs.org/wiki/OpenZFS_Office_Hours) *** License summaries in pkgng (http://www.shiningsilence.com/dbsdlog/2013/12/09/12934.html) A discussion between Justin Sherill (http://www.bsdnow.tv/episodes/2013_11_13-the_gateway_drug) and some NYCBUG guys about license frameworks in pkgng Similar to pkgsrc's "ACCEPTABLE_LICENSES" setting, pkgng could let the user decide which software licenses he wants to allow Maybe we could get a "pkg licenses" command to display the license of all installed packages Ok bapt, do it *** The FreeBSD challenge continues (http://thelinuxcauldron.com/2013/12/08/freebsd-challenge/) Checking in with our buddy from the Linux foundation... The switching from Linux to FreeBSD blog series continues for his month-long trial Follow up from last week: "As a matter of fact, I did check out PC-BSD, and wanted the challenge. Call me addicted to pain and suffering, but the pride and accomplishment you feel from diving into FreeBSD is quite rewarding." Since we last mentioned it, he's decided to go from a VM to real hardware, got all of his common software installed, experimented with the Linux emulation, set up virtualbox, learned about slices/partitions/disk management, found BSD alternatives to his regularly-used commands and lots more *** Ports gets a stable branch (https://svnweb.freebsd.org/ports?view=revision&revision=336615) For the first time ever, FreeBSD's ports tree will have a maintained "stable" branch This is similar to how pkgsrc does things, with a rolling release for updated software and stable branch for only security and big fixes All commits to this branch require approval of portmgr, looks like it'll start in 2014Q1 *** Feedback/Questions John writes in (http://slexy.org/view/s2iRV1tOzB) Spencer writes in (http://slexy.org/view/s21gAR5lgf) Campbell writes in (http://slexy.org/view/s203iOnFh1) Sha'ul writes in (http://slexy.org/view/s2yUqj3vKW) Clint writes in (http://slexy.org/view/s2egcTPBXH) ***