An ‘r’ before a string tells the Python interpreter to treat backslashes as a literal (raw) character. Normally, Python uses backslashes as escape characters. Prefacing the string definition with ‘r’ is a useful way to define a string where you need the backslash to be an actual backslash and not part of an escape code that means something else in the string.
1. In this example, Python will interpret each ‘\t’ found in this string as a tab. That is, the backslash+t is interpreted as an escape sequence with a special purpose.
>>> 'path\to\the\thing' 'path\to\the\thing' >>> print('path\to\the\thing') path o he hing >>>
2. By adding the leading r, Python will know that the backslashes are to be interpreted as literal characters and not escape sequences. Interestingly, note how Python represents the literal backslash–as an escape sequence of backslash + backslash.
>>> r'path\to\the\thing' 'path\\to\\the\\thing' >>> print(r'path\to\the\thing') path\to\the\thing >>>
3. This means another way to handle the literal backslash problem is to use backslash + backslash in your string definition. However, this feels like a clunkier way to define the string to me when compared to using ‘r’. Using ‘r’ makes for, I think, more readable Continue reading
“People ask me to predict the future, when all I want to do is prevent it. Better yet, build it. Predicting the future is much too easy, anyway. You look at the people around you, the street you stand on, the visible air you breathe, and predict more of the same. To hell with more. I want better.”
— Ray Bradbury, from Beyond 1984: The People Machines
The story and the path are clear: quantum computers are coming that will have the ability to break the cryptographic mechanisms we rely on to secure modern communications, but there is hope! The cryptographic community has designed new mechanisms to safeguard against this disruption. There are challenges: will the new safeguards be practical? How will the fast-evolving Internet migrate to this new reality? In other blog posts in this series, we have outlined some potential solutions to these questions: there are new algorithms for maintaining confidentiality and authentication (in a “post-quantum” manner) in the protocols we use. But will they be fast enough to deploy at scale? Will they provide the required properties and work in all protocols? Are they easy to use?
Adding post-quantum cryptography into architectures and networks Continue reading
Theoretically, there is no impediment to adding post-quantum cryptography to any system. But the reality is harder. In the middle of last year, we posed ourselves a big challenge: to change all internal connections at Cloudflare to use post-quantum cryptography. We call this, in a cheeky way, “post-quantum-ifying” our services. Theoretically, this should be simple: swap algorithms for post-quantum ones and move along. But with dozens of different services in various programming languages (as we have at Cloudflare), it is not so simple. The challenge is big but we are here and up for the task! In this blog post, we will look at what our plan was, where we are now, and what we have learned so far. Welcome to the first announcement of a post-quantum future at Cloudflare: our connections are going to be quantum-secure!
The life of most requests at Cloudflare begins and ends at the edge of our global network. Not all requests are equal and on their path they are transmitted by several protocols. Some of those protocols provide security properties whilst others do not. For the protocols that do, for context, Cloudflare uses: TLS, QUIC, WireGuard, DNSSEC Continue reading
It should be safe to say that most of us have had a tough time these past two years, no …
The post Cisco Live 2022 – Good vibes again! first appeared on Fryguy's Blog.In the first half of the AI/ML in Networking webinar, Javier Antich walked us through the AI/ML hype, basics of machine learning, and machine learning techniques.
In the second part of the webinar, he described “The Good, The Bad and The Ugly”, starting with the good parts: where does AI/ML make sense in networking?
In the first half of the AI/ML in Networking webinar, Javier Antich walked us through the AI/ML hype, basics of machine learning, and machine learning techniques.
In the second part of the webinar, he described “The Good, The Bad and The Ugly”, starting with the good parts: where does AI/ML make sense in networking?
A closure in Rust is an anonymous function. An anonymous function is a function without a name. A closure is defined with parameters between two pipes and expressions between curly braces || By default, closures borrow a reference to the parameters that are passed into it. ...continue reading
A closure in Rust is an anonymous function. An anonymous function is a function without a name. A closure is defined with parameters between two pipes and expressions between curly braces || Unlike functions, closures CAN capture variables from their enclosing scope. By...continue reading
For the last three years, the Crypto Forum Research Group of the Internet Research Task Force (IRTF) has been working on specifying the next generation of (hybrid) public-key encryption (PKE) for Internet protocols and applications. The result is Hybrid Public Key Encryption (HPKE), published today as RFC 9180.
HPKE was made to be simple, reusable, and future-proof by building upon knowledge from prior PKE schemes and software implementations. It is already in use in a large assortment of emerging Internet standards, including TLS Encrypted Client Hello and Oblivious DNS-over-HTTPS, and has a large assortment of interoperable implementations, including one in CIRCL. This article provides an overview of this new standard, going back to discuss its motivation, design goals, and development process.
Public-key cryptography is decades old, with its roots going back to the seminal work of Diffie and Hellman in 1976, entitled “New Directions in Cryptography.” Their proposal – today called Diffie-Hellman key exchange – was a breakthrough. It allowed one to transform small secrets into big secrets for cryptographic applications and protocols. For example, one can bootstrap a secure channel for exchanging messages with confidentiality and integrity using a key exchange Continue reading
The rise of cloud native and containerization, along with the automation of the CI/CD pipeline, introduced fundamental changes to existing application development, deployment, and security paradigms. Because cloud native is so different from traditional architectures, both in how workloads are developed and how they need to be secured, there is a need to rethink our approach to security in these environments.
As stated in this article, security for cloud-native applications should take a holistic approach where security is not an isolated concern, but rather a shared responsibility. Collaboration is the name of the game here. In order to secure cloud-native deployments, the application, DevOps, and security teams need to work together to make sure security happens earlier in the development cycle and is more closely associated with the development process.
Since Kubernetes is the most popular container orchestrator and many in the industry tend to associate it with cloud native, let’s look at this holistic approach by breaking it down into a framework for securing Kubernetes-native environments.
At a high level, the framework for securing cloud-native environments consists of three stages: build, deploy, and runtime.
In the build stage, developers write code and the code gets compiled, Continue reading
The following post originally appeared on the Packet Pushers’ Ignition site on November 13, 2020. 5G has long been declared the future of mobile networks by both tech analysts and the popular press, but scratch the surface and IT pros will find that behind all the hype and headlines lies a massive redesign of network […]
The post Mobile Edge Computing (MEC) Puts Compute, Networking Services Closer To Applications appeared first on Packet Pushers.
Marketing is an underappreciated (and even demonized) part of the process in creating and managing networking products. Cathy Gadecki of Juniper joins Russ White and Tom Ammon on this episode of the Hedge to fill in the background and discuss the importance of marketing, and some of the odd corners where marketing impacts product development.
As a large data processing country, Germany is at the forefront of security and privacy regulation in Europe and sets the tone for other countries to follow. Analyzing and meeting the requirements to participate in Germany’s cloud security industry requires adherence to international, regional, and country-specific standards. Cloudflare is pleased to announce that we have taken appropriate organizational and technical precautions to prevent disruptions to the availability, integrity, authenticity, and confidentiality of Cloudflare’s production systems in accordance with BSI-KritisV. TÜViT, the auditing body tasked with auditing Cloudflare and providing the evidence to BSI every two years. Completion of this audit allows us to comply with the NIS Directive within Germany.
In 2019, Cloudflare registered as an Operator of Essential Services’ under the EU Directive on Security of Network and Information Systems (NIS Directive). The NIS Directive is cybersecurity legislation with the goal to enhance cybersecurity across the EU. Every member state has started to adopt national legislation for the NIS Directive and the criteria for compliance is set individually by each country. As an ‘Operator of Essential Services’ in Germany, Cloudflare is regulated by the Federal Continue reading
An introduction to formal analysis and our proof of the security of KEMTLS
Good morning everyone, and welcome to another Post-Quantum–themed blog post! Today we’re going to look at something a little different. Rather than look into the past or future quantum we’re going to look as far back as the ‘80s and ‘90s, to try and get some perspective on how we can determine whether a protocol is or is not secure. Unsurprisingly, this question comes up all the time. Cryptographers like to build fancy new cryptosystems, but just because we, the authors, can’t break our own designs, it doesn’t mean they are secure: it just means we are not smart enough to break them.
One might at this point wonder why in a post-quantum themed blog post we are talking about security proofs. The reason is simple: the new algorithms that claim to be safe against quantum threats need proofs showing that they actually are safe. In this blog post, not only are we going to introduce how we go about proving a protocol is secure, we’re going to introduce the security proofs of KEMTLS, a version of TLS designed to be more secure against quantum computers, and Continue reading
Cryptographic code is everywhere: it gets run when we connect to the bank, when we send messages to our friends, or when we watch cat videos. But, it is not at all easy to take a cryptographic specification written in a natural language and produce running code from it, and it is even harder to validate both the theoretical assumptions and the correctness of the implementation itself. Mathematical proofs, as we talked about in our previous blog post, and code inspection are simply not enough. Testing and fuzzing can catch common or well-known bugs or mistakes, but might miss rare ones that can, nevertheless, be triggered by an attacker. Static analysis can detect mistakes in the code, but cannot check whether the code behaves as described by the specification in natural-language (for functional correctness). This gap between implementation and validation can have grave consequences in terms of security in the real world, and we need to bridge this chasm.
In this blog post, we will be talking about ways to make this gap smaller by making the code we deploy better through analyzing its security properties and its implementation. This blog post continues our work on high assurance Continue reading