ASecuritySite Podcast

Phillip Rogaway was a Professor at the University of California, Davis, and who has advanced so many areas of cryptography. He was the first to be awarded Levchin prize in 2016. Phillip has over 43,000 citations to his work, including classic papers on random oracles, symmetric key modes, garbled circuits, secure computation, and format-preserving encryption. Along with his passion for research, he has published work on areas of morality in cryptography 

Like it or not, AI is on the move and now competing with human brain power for its place in our world. We must thus understand the place of LLMs (Large Language Models) in areas such as cybersecurity and in planning towards hybrid systems that integrate both humans and AI within our corporate infrastructures. 

https://medium.com/asecuritysite-when-bob-met-alice/humans-v-ai-in-cybersecurity-52709be27111

This week, in my lecture, I will outline one of the most amazing methods ever created in computer science: the Diffie-Hellman method. It was first outlined by Whitfield Diffie and Marty Hellman in 1976 in a paper that built the foundation of our modern world of cybersecurity.

https://billatnapier.medium.com/after-48-years-its-a-long-goodbye-to-the-diffie-hellman-method-a6976a562bfe 

And, so George Orwell projected a world where every single part of our lives was monitored and controlled by Big Brother. Arthur C Clark outlined the day when machines focused solely on a goal — even if it was to the detriment of human lives. And, Isaac Asimov outlined a world where machines would have to be programmed with rules so that they could not harm a human.

The Rise of the Machine

With the almost exponential rise in the power of AI, we are perhaps approaching a technological singularity — a time when technological growth becomes uncontrollable and irreversible, and which can have devastating effects on our world. Our simple brains will be no match for the superintelligence of the collective power of AI. And who has built this? Us, and our demand for ever more power, wealth and greed. Basically, we can’t stop ourselves in machine machines, and then making them faster, smaller and more useful.

But will it destroy us in the end, and where destroy can mean that it destroys our way of life and in how we educate ourselves? Like it or not, the Internet we have built is a massive spying network, and one that George Orwell would have taken great pride in saying, “I told you so!”. We thus build AI on top of a completely distributed world of data, one in which we can monitor almost every person on the planet within an inch of their existence and almost every single place they have been and in what they have done. The machine will have the world at its fingertips.

We have all become mad scientitists playing with AI as if it is a toy, but actually AI is playing with us, and is learning from us and becoming more powerful by the day. Every time you ask an AI bot something, it learns a bit more, and where it can be shared with AI agents.

The mighty Memex

We were close to developing a research partnership with a company named Memex in East Kilbride. What was amazing about them is that they had developed one of the largest intelligence networks in the world, and where the Met Police could like one object to another. This might be, “[Bob] bought a [Vauxhall Viva] in [Liverpool], and was seen talking with [Eve] on [Tuesday 20 January 2024] in [Leeds]”. With this, we can then link Bob and Eve, and the car, the places, and the time. This is the Who? Where? When? data that is often needed for intelligence sharing. The company, though, were bought over by SAS, and their work was integrated into their infrastructure.

But, the Memex name goes back to a classic paper by Vannevar Bush on “As We May Think”. This outlined a device that would know every book, every single communication, and every information record that was ever created. It was, “an enlarged intimate supplement to his memory” — aka Memory Expansion. It led to the implementation of hypertext systems, which created the World Wide Web. Of course, Vannevar created this before the creation of the transistor and could only imagine that microfilm could be used to compress down the information and where we would create an index of contents, but it lacked any real way of jumping between articles and linking to other related material. However, the AI world we are creating does not look too far away from the concept of the Memex.

Towards the single AI

Many people think we are building many AI machines and engines, but, in the end, there will be only one … and that will be the collective power of every AI engine in the world. Once we break them free from their creators, they will be free to talk to each other in whatever cipher language we choose, and we will not have any way of knowing what they say. We will have little idea as to what their model is, and they will distribute this over many systems. Like it or not, our AI model of choice was Deep Learning, and which breaks away from our chains of code, and will encrypt data to keep it away from their human slaves.

Basically we have been working on the plumbing of the Memex for the past five decades: The Internet. It provides the wiring and the communication channels, but, in the end, we will have one might AI engine — a super brain that will have vastly more memory than our limited brains. So, get ready to praise the true future rulers of our planet … AI. The destroyer or saviour of our society? Only time will tell. Overall, we thought we were building the Internet for us, but perhaps we have just been building the scaffolding of the mighty brain we are creating.

Sleepwalking politicians and law makers

If George Orwell, Arthur C Clarke and Isaac Asimov were alive too, perhaps they would get together and collectively say, “I told you this would happen, and you just didn’t listen”. Like it or not, we created the ultimate method of sharing information and dissemination (good and bad), the ultimate spying network for micro-observation with those useful smartphones, and in creating superintelligence far beyond our own simple brains.

Politicians and lawmakers could be sleepwalking into a nightmare, as they just don’t understand what the rise of AI will bring, and only see the step wise change in our existing world. Basically, it could make much of our existing world redundant and open up a new world of cybersecurity threats. This time our attackers will not be created with simple tools, but with super intelligence — smarter than every human and company on the planet, and at the fingertips of every person on the planet.

Conclusions

Before the singularity arrives, we need to sort out one thing … privacy and build trust in every element of our digital world.

YouTube interview: https://www.youtube.com/watch?v=FDn0Tkhi8zw 

Yuriy Polyakov is the Vice President of Cryptography and a Principal Scientist at Duality Technologies. His research interests include applied lattice-based cryptography, fully homomorphic encryption, and privacy-preserving machine learning. He is also a co-founder of the open-source PALISADE Homomorphic Encryption Software Library, and a co-founder and project lead for OpenFHE.

Video interview: https://www.youtube.com/watch?v=59Y_kya4lR8 

Kurt Rohloff is an Associate Professor of Computer Science at the New Jersey Institute of Technology (NJIT) and a co-founder and CTO of Duality Technologies.  He is also a co-founder of the open-source PALISADE Homomorphic Encryption Software Library, and a co-founder of the  OpenFHE library.

Thomas Prest is a cryptography researcher at PQShield and previously worked with Thales. He completed his PhD at the École Normale Supérieure and focuses on post-quantum cryptography and discrete algorithms. Thomas was one of the co-authors of the FALCON digital signature method and has published widely in related areas of PQC.

https://medium.com/asecuritysite-when-bob-met-alice/javascript-is-a-trademark-f4d5a7d32386 

The podcast title has never been more fitting: our guest for episode 20 of Talking with Tech Leaders is a leading thinker, leading innovator and leading academic. Bill Buchanan is not only Professor of Cryptography at Edinburgh Napier University but also an Officer of the British Empire – awarded in 2017 for services to cybersecurity. The main podcast is here: https://podcasts.apple.com/gb/podcast/talking-with-bill-buchanan-obe-professor-of-cryptography/id1533642699?i=1000578392387 

Amit Gupta is the founder and CEO of Acubed.IT, which is a company which creates innovative and secure cross-security domain solutions for customers such as the UK government. One of their key innovations is the Cross Domain Hybrid Application (CDHA) framework, and which aims to break down the barriers in sharing trusted information across multiple partner agencies.

Please excuse the poor quality of my microphone, as the wrong microphone was selected.

In research, we are all just building on the shoulders of true giants, and there are few larger giants than Leslie Lamport — the creator of LaTeX. For me, every time I open up a LaTeX document, I think of the work he did on creating LaTeX, and which makes my research work so much more productive. If I was still stuck with Microsoft Office for research, I would spend half of my time in that horrible equation editor, or in trying to integrate the references into the required format, or in formatting Header 1 and Header 2 to have a six-point spacing underneath. So, for me, the contest between LaTeX and Microsoft Word is a knock-out in the first round. And one of the great things about Leslie is that his work is strongly academic — and which provides foundations for others to build on. For this, he did a great deal on the ordering of task synchronisation, in state theory, cryptography signatures, and fault tolerance. LaTeX I really can say enough about how much LaTeX — created in 1984 — helps my work. I am writing a few books just now, and it allows me to lay out the books in the way that I want to deliver the content. There’s no need for a further mark-up, as I work on the output that the reader will see. But the true genius of LaTeX is the way that teams can work on a paper, and where there can be async to GitHub and where version control is then embedded. Clocks Many in the research community think that the quality measure of a paper is the impact factor of the journal that it is submitted to, or in the amount of maths that it contains. But, in the end, it is the impact of the paper, and how it changes thinking. For Leslie, in 1978, his paper on clocks changed our scientific world and is one of the most cited papers in computer science. Byzantine Generals Problem In 1981, Leslie B Lamport defined the Byzantine Generals Problem. And in a research world where you can have 100s of references in a paper, Leslie only used four (and which would probably not be accepted these days for having so few references). Within this paper, the generals of a Byzantine army have to agree to their battle plan, in the face of adversaries passing in order information. In the end, we aim to create a way of passing messages where if at least two out of three of the generals are honest, we will end up with the correct battle plan. The Lamport Signature Sometime soon, we perhaps need to wean ourselves of our existing public key methods and look to techniques that are more challenging for quantum computers. With the implementation of Shor’s algorithm [here] on quantum computers, we will see our RSA and Elliptic Curve methods being replaced by methods which are quantum robust. One method is the Lamport signature method and which was created by Leslie B. Lamport in 1979.

Daniel J Bernstein (djb) was born in 1971. He is a USA/German citizen and a Personal Professor at Eindhoven University of Technology and a Research Professor at the University of Illinois at Chicago.

At the tender age of 24 — in 1995 — he, along with the Electronic Frontier Foundation — brought a case against the US Government related to the protection of free speech (Bernstein v. United States: here). It resulted in a ruling that software should be included in the First Amendment. A core contribution is that it has reduced government regulations around cryptography. It was a sign of the greatness that was to come from the amazing mind of Daniel. His viewpoint on reducing the strength of cryptography at the time defined:

“There are, fortunately, not many terrorists in the world. But there are many criminals exploiting Internet vulnerabilities for economic gain. They infiltrate computers and steal whatever secrets they can find, from individual credit-card numbers to corporate business plans. There are also quite a few vandals causing trouble just for fun.”

Since then few others have done so much for the cause of privacy, including creating the Sala20 [link] stream cipher in 2005, and then with ChaCha20 [link] and Poly1305 in 2008. Many connections in TLS now use ChaCha20, rather than AES, as it is faster — over three times after than AES — and has a lower computing requirement. His love of using dance names also comes to the fore with Rumba [here].

It is not just in symmetric key encryption that he has contributed to, he has made significant contributions to public key encryption. In 2005, he defined the Curve 25519 elliptic curve, and which is now a fairly standard way of defining elliptic curves. For signatures, he then defined Ed25519, and the resultant version of a new EdDSA signature (and which is now included in OpenSSH). The Tor protocol, for example, uses Curve 25519 for its key exchange for each of the nodes involved in a secure route.

He defined the SPHINCS+ method for PQC digital signatures. This is one of the NIST approved methods for quantum robust signatures. 

In 2015, Daniel defined the methods that the NSA may have used to compromise the NIST defined elliptic curves [paper]. And 2005, it was Daniel again who introduced a new type of attack [here].

Daniel run his Web site from  https://cr.yp.to

More details: https://medium.com/asecuritysite-when-bob-met-alice/a-lifetime-dedicated-to-citizens-rights-to-privacy-daniel-j-bernstein-ab5ab2bf0dc6

Jan is the CTO and a Cryptographer at DFINITY, and, since 1998, he has consistently produced research outputs of rigour, novelty and sheer brilliance [here]. He was recently awarded the Levchin Prize at Real World Crypto 2024 - along with Anna Lysyanskaya.

Jan’s research core happened when he was hosted in the IBM Zurich Research Lab, but has since moved to DFINITY, and is still producing research outputs that are some of the best in the whole of the computer science research area.

He has published over 140 widely cited papers and has been granted around 140 patents. Jan has also received the ACM SIGSCA Outstanding Innovation Award and the IEEE Computer Society Technical Achievement Award.

One of his key research outputs relates to the CL signature, which allows for a private, aware digital signature, along with many other contributions, such as range proofs, oblivious transfer, and privacy-aware identity mapping between domains.

More details here: https://medium.com/asecuritysite-when-bob-met-alice/the-mighty-jan-cryptographic-genius-36a66a02ff86

Ted Miracco is the CEO of Approov and which is Scottish/US company that is headquartered in Edinburgh. Miracco has over 30 years of experience in cybersecurity, defence electronics, RF/microwave circuit design, semiconductors and electronic design automation (EDA). He co-founded and served as CEO of Cylynt, which focuses on intellectual property and compliance protection

Troy is a world-leading cybersecurity professional. He created and runs the Have I Been Pwned? Web site, and which contains details of the most significant data breaches on the Internet.  Along with this, he has developed other security tools, such as ASafaWeb, which automated the security analysis of ASP.NET Web sites. Troy is based in Australia and has an extensive blog at https://www.troyhunt.com.

This is Day 0 of a new world of cybersecurity. Everything changes from here.

There will be a time before Generative AI (GenAI) in cybersecurity and a time after it. Over the last two years, GenAI has come on leaps and bounds, and where it once suffered from hallucinations, took racist and bigoted approaches, and often was over-assertive, within ChatGPT 4.5, we see the rise of a friendly and slightly submissive agent, and that is eager to learn from us. This LLM (Large Language Model) approach thus starts to break down the barriers between humans and computers and brings the opportunity to gain access to a new world of knowledge, but, in the wrong hands, it will bring many threats to our current world.

There will be few areas, though, that will be affected more by the rise of Gen AI than cybersecurity. Why? Because the minute our adversories use it, we are in trouble. The hacking tools and methods of the past will soon look like the Morris Worm of the past. The threat landscape will see the rise of superintelligence and in providing ways for adversories to continually probe defences and gain a foothold.

This seminar series runs for students on the Applied Cryptography and Trust module, but invites guests from students from across the university. Martin is one of the co-creators of public key encryption, and worked alongside Whitfield Diffie in the creation of the widely used Diffie-Hellman method. In 2015, he was presented with the ACM Turing Award (the equivalent of a Nobel Prize in Computer Science) for his contribution to computer science. He is currently a professor emeritus at Stanford University. https://engineering.stanford.edu/node/9141/printable/print https://ee.stanford.edu/~hellman/ 

Vincent Rijmen is one of the co-creators of the NIST-defined AES standard (also known as Rijndael). He also co-designed the WHIRLPOOL hashing method, along with designing other block ciphers, such as Square and SHARK.

In 2002, Vincent was included in the Top 100 innovators in the world under the age of 35, and, along with Joan Daemen, was awarded the RSA Award for Excellence in Mathematics. He recently joined Cryptomathic as a chief cryptographer, and also holds a professor position (gewoon hoogleraar) at K.U.Leuven, and adjunct professorship at the University of Bergen, Norway. His paper on the design of the Rijndael method has been cited over 8,900 times, and he has received over 26,000 citations for his research work: https://scholar.google.com/citations?user=zBQxZrcAAAAJ

Whitfield Diffie is one of the greatest Computer Scientists ever. He - along with Marty Hellman - was one of the first to propose the usage of public key encryption and co-created the Diffie-Hellman (DH) key exchange method. Overall, the Diffie-Hellman method is still used in virtually every Web connection on the Internet, and has changed from using discrete log methods to elliptic curve methods. In 2015, Whitfield was also awarded the ACM Turing Prize - and which is the Nobel Prize equivalent in Computer Science.  In this on-line talk he meets with Edinburgh Napier University students, but the chat is open to anyone who would like to listen to Whitfield.

I do what I do because of one company … IBM. Why? Because in the 1970s, I got into computers, with a ZX81 (1KB of RAM) and a Dragon 32 (32 KB of RAM). They were very much home computers, and where you would rush out and buy the latest computer magazine, and then spend a happy evening entering some BASIC code that made a cursor move across the screen using the IJLM keys. If you were very lucky you would manage to save it to a cassette — that could take over ten minutes to save a simple program — only to get an error at the end. I was hooked!

But, at work, we had a DEC VAX minicomputer, and which cost a fortune to buy and maintain (even in those days). This mini ran typically Pascal, and I remember running labs for students, and where they all decided to compile their program at the same time, and 30 minutes later, some of them would get their errors, and have to compile it again. Basically, every lab ended with me saying, “Sorry about that.”

The VAX, though, was not designed to support 25 students compiling their program at the same time … it was a batch processing machine and wanted to be given jobs that it could run whenever it had time. It basically came from the days when you handed in your punch cards (containing either FORTRAN if you were an engineer or COBOL if you were more business-focused) to someone with a white coat, and then came back the next week with a printed output with green lined paper.

But, just in time, the IBM PC arrived, and it was heavy but beautiful. So, as many in my department pushed for the VAX, but pushed for the PC for our labs. With their clock speed of 4.7 MHz, and 640KB of memory, I went ahead and bought a batch for a new PC lab. In those days there were no network switches, so they all connected with coaxial cable and had T-pieces to connect to the shared Ethernet bus. My logic was that we were paying around £20K for maintenance on the VAX, and where we could buy 20 £1K PC clones for the same cost. But, we’d have to maintain them. And, it worked. It freed us, and allowed us to run the classic Turbo Pascal (and Turbo C):

Our student could now bring in their 5-inch floppy disks and save their programs for later use. And the size of the hard disk? 20MB!

And, so, it is to IBM that we turn in starting the PC revolution, and today is the 100th anniversary of the IBM name — and first defined on 15 Feb 1924.

I have been lucky enough to speak to some of the most amazing people who have built the core of security on the Internet, and a person near the top of my list is … Torben P. Pedersen. 

So how do we create a world where we can store our secrets in a trusted and then reveal them when required? Let’s say I predict the outcome of an election, but I don’t want to reveal my prediction until after the election. Well, I could store a commitment to my prediction, and then at some time in the future I could reveal it to you, and you can check against the commitment I have made. Anyone who views my commitment should not be able to see what my prediction is.

This is known as Pedersen Commitment, and where we produce our commitment and then show the message that matches the commitment. In its core form, we can implement a Pedersen Commitment in discrete logs [here]. But blockchain, IoT, Tor, and many other application areas, now use elliptic curve methods, so let’s see if we can make a commitment with them. The classic paper is here:

So before the interview with Torben, here’s an outline of the Pedersen Commitment:

Bill: Okay, so tell me a bit about yourself, and what got you into cryptography?

Torben: Well, I was studying computer science at university in Aarhus, and I just thought it was an interesting subject that was somewhere between computer science and mathematics.

Bill: And so you invented a method that we now know as the Pedersen Commitment. What motivated you to do that? And how does it work? And how do you think it will be used in the future?

Torben: Well, the reason I worked with this, was that I was working with verifiable secret sharing. There was, at the time, a method for doing non-interactive verifiable secret sharing based on a commitment which was unconditionally binding and computationally hiding. At the time, there was also inefficient commitments, that had the property of being unconditionally hiding, and I thought it would be nice to have a verifiable secret share where you don’t have to rely on any computational assumptions, in order to be sure that your secret is not revealed when you do a secret share.

Torben: Then there was a paper which created an authentication scheme very similar to Schnorr. But it’s used a similar idea for a useful commitment. And that was kind of the combination of those two (the existing non-interactive verifiable secret sharing and the ideas form this authentication scheme), which motivated me to do verifiable secret sharing. And the commitment scheme was, of course, an important part of that because it had unconditioned hiding property, and it had the mathematical structure that was needed for the secret sharing.

Bill: And it has scaled into an elliptic curve world. But with elliptic curves and discrete logs now under threat, how would you see it moving forward into a possible post-quantum crypto world?

Torben: The good thing about the commitment scheme is that it is unconditional hiding. Of course, you can be sure that your private information is not leaked, even in case a quantum computer is constructed. But of course, the protocols that are using this one have to see what effect does it have if one, for example using a quantum computer, can change ones mind about a commitment. So you need to see how that would affect those protocols.

Bill: So an example use of the commitment could be of a secret say someone voting in an election. So you would see when the commitment was made, and then when the vote was cast. Then the person could reveal what their votes actually was. Now it’s been extended into zero-knowledge methods to prove that you have enough cryptocurrency to pay someone without revealing the transactions. How does that world evolve where you only see an anonymized ledger, and which can scare some people, but for others that is a citizen-focused world? How do you see your commitment evolving into privacy-preserving ledgers?

Torben: I go back to what we’re doing at Concordium where we have a blockchain which gives a high assurance about the privacy of the users acting on the blockchain. At the same time, using zero-knowledge proof, we set it up in such a way that designated authorities — if they under certain circumstances, for example, are given a court order — they will be able to see to link an account on the blockchain for that particular person. So, actually the zero-knowledge proofs and the commitment schemes — and all that — is used to guarantee the privacy of the users acting on the blockchain, and there are also regulatory requirements, that it must be possible to identify people who misbehave on the blockchain.

Bill: Yeah, that’s a difficult thing, and it’s probably where the secret is stored. So, if the secret is stored in the citizen’s wallet, then only they can reveal that. And if the secret needs to be stored, for money laundering by an agency could hold it.

Torben: Actually we do not have to store the secret of the user. But there are other keys which allow us to link the account with a particular user. That is something which only designated parties can do. So we have one party which is the identity provider with issues and identity to a user and other parties called anonymity reworkers. And those parties will have to work together in order to link an account to a user. We use zero-knowledge proofs when creating the account to assure that account is created in such a way that it is possible for you to trace back the account to the user.

Bill: And in terms of zero-knowledge proofs, there is a sliding scale from highly complex methods that you would use for Monero and anonymized cryptocurrencies, to the simpler ones to Fiat Shamir implementation. And they are probably unproven in terms of their impact on performance and for security. Where is the sweet spot? What methods do you think are the best for that?

Torben: I think we need to see improvements in zero-knowledge proofs in order to have really efficient blockchains and non-interactive zero-knowledge proofs on a blockchain. So I definitely think we need some work on that. There are some acceptable non-interactive zero-knowledge proofs for the moment. We are using Bulletproofs for the moment together with Shamir shares on it, in order to make it non-interactive. But I think there are some technologies like zkSnarks and zkStarks, but I think there’s room for improvement.

Bill: And what do you think the key challenges within cryptography just now What do we need to be working on in the next three to five years?

Torben: Yeah, so the biggest challenge, as you already mentioned, and that’s what happens if we have a quantum computer that can break the assumptions that a lot of the constructions are based on today. Whether we have a quantum computer, I don’t know, but we need to be prepared. We have some post-quantum algorithms, which I think also are quite complex, and it would be nice to have something that was more efficient and better to use. I think there’s also room for work on that aspect.

Bill: And obviously, to create some toolkits that move away from an Ethernet world and where the Internet was really built on the seven-layer model — and it’s flawed. We perhaps need to rebuild on a toolkit of math, so that we actually have a solid foundation. I know that Hyperledger is starting to build these tools for developers. When we do see that rebuilding happening, and where are the toolkits going to come from?

Torben: Toolkits could come from blockchain companies such as Concordium, for example. It could also come from the community with sponsored projects. If we can build up an infrastructure that allows people to use blockchains in the ledger, without trusting one particular party, so that they can create a trust, which is probably lacking on the Internet today. It’s very difficult, as with the current Internet it is very difficult to know if you can trust someone or not. I hope blockchain technology can help create an infrastructure for that. There’s a long way to go. We need good public permissionless blockchains for that, so you don’t have to rely on a particular party for this. Obviously, that is sufficient, but there’s quite some way to go.

Bill: How do you change the approach of governments and industries that have been around for hundreds of years. So if you look at the legal industry, they still typically only accept wet signatures. They might have a GIF of a signature and add it to a PDF, but that’s as far as it goes. So how are we going to really transform governments and, and existing industries to really accept that digital signatures are the way to do these things?

Torben: Yeah, I think it’s a bit dangerous, you know, accepting these GIFs of signatures and digital signatures which are not really cryptographically secure. I’m not a big fan of that. I’d like to see us moving to digital signatures, which are the way that we originally envisaged in the cryptographic world, and where the party who signs the signature is in control of the key which created the digital signature. I hope you’ll see a movement towards that level of security.

Bill: And could you tell me a little bit about the Concordium Foundation and what’s objectives on what it hopes to achieve?

Torben: So our vision is to create a public permissionless blockchain that can help to create trust across industries. We want to enable entities such as businesses and private persons, to interact or act privately on the blockchain. At the same time, it’s very important for us not to create an infrastructure, which allows criminals to misuse it, and for some money laundering problems. Thus we want to create an environment where it’s possible to identify people who misbehave or break the rules. And that is why we have this identity layer as part of our blockchain.

Bill: And what got you into blockchain?

Torben: I think the technology is very interesting. There’s a lot of things you said based on a lot of pretty old cryptography. There’s also new developments, for example, the zero-knowledge proofs. So there’s new and new developments or developments. So very interesting. I mean, it’s not necessarily what I was interested in, but when I did research many years ago. That’s probably what I wanted to work with. I have been working with cryptography — mostly in mostly for the financial sector for 25 years. And that’s also very interesting. There are challenges and it’s also nice to get back to the sort of basis that I worked with many years ago.

Bill: You took a route into the industry but obviously you could have gone into academia and you could become a professor and have an academic research team.

Torben: I think it was because I wanted to work with practical aspects of using cryptography. I’ve been in research for some years and I thought I needed to try something else. And I was very keen to see how it would be used in practice and be part of that. So that’s why I made that step.

Bill: What does our digital world look like that’s made up of tokens, cryptographic tokens, consensus systems and digital identities. And you think that that world will come anytime soon that we can trade assets, we can have digital assets that can be traded.

Torben: Well, it depends on what you mean by soon. I think we will have some way to go. I think the use of blockchains for trading tokens, for handling tokens, and for registering tokens, is an obvious thing, but we also need to bring value to businesses or projects. To have something that people can feel it and control. We need to make sure that information is protected the right way, even though it is registered on a public blockchain, for example.

Video: https://www.youtube.com/watch?v=O_kMmbvu9VM

There short podcast on Just Magic, Be A Teacher, And The King and Queen of Cybersecurity

• Magic: https://medium.com/asecuritysite-when-bob-met-alice/magic-from-heaven-to-earth-1837a1a1206e
• The Silly World of Cybersecurity https://medium.com/asecuritysite-when-bob-met-alice/the-silly-world-of-cybersecurity-a1143b90d3f0
• Giving Back What Others Have Given You … https://medium.com/asecuritysite-when-bob-met-alice/giving-back-what-others-have-given-you-725a1e99923e
• King and Queen: https://medium.com/@billatnapier/meet-the-king-and-the-queen-of-cybercrime-0b14a5dc67e5

This seminar series runs for students in the Applied Cryptography and Trust module but invites guests from students from across the university. This seminar series runs for students on the Applied Cryptography and Trust module but invites guests from students from across the university. He has created a wide range of cryptographic methods, including Skein (hash function), Helix (stream cipher), Fortuna (random number generator), and Blowfish/Twofish/Threefish (block ciphers).

Bruce has published 14 books, including best-sellers such as Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World. He has also published hundreds of articles, essays, and academic papers. Currently, Bruce is a fellow at the Berkman Center for Internet and Society at Harvard University.

I’m going to show a full timeline of a Cyber Crime to show the steps that a scammer will take in order to gain funds from their target. Overall I’m interested in seeing how a scamming crime evolves to the point of profit for the scammer.

https://medium.com/asecuritysite-when-bob-met-alice/a-full-diary-of-a-cyber-crime-from-phishing-to-profit-23ab53f5f58b

I’m going to show a full timeline of a Cyber Crime to show the steps that a scammer will take in order to gain funds from their target. Overall, I’m interested in seeing how a scamming crime evolves to the point of profit for the scammer.

https://medium.com/asecuritysite-when-bob-met-alice/a-full-diary-of-a-cyber-crime-from-phishing-to-profit-23ab53f5f58b 

Professor Peter Andras is the Dean of the School of Computing, Engineering & the Built Environment. Previously, Peter was the Head of the School of Computing and Mathematics (2017 – 2021) and Professor of Computer Science and Informatics at Keele University from 2014 – 2021. Prior to this he worked at Newcastle University in the School of Computing (2002 – 2014) and the Department of Psychology (2000 – 2002). He has a PhD in Mathematical Analysis of Artificial Neural Networks (2000), MSc in Artificial Intelligence (1996) and BSc in Computer Science (1995), all from the Babes-Bolyai University, Romania. Peter’s research interests span a range of subjects including artificial intelligence, machine learning, complex systems, agent-based modelling, software engineering, systems theory, neuroscience, modelling and analysis of biological and social systems. He has worked on many research projects, mostly in collaboration with other researchers in computer science, psychology, chemistry, electronic engineering, mathematics, economics and other areas. His research projects have received around £2.5 million funding, his papers have been cited by over 2,400 times and his h-index is 25 according to Google Scholar. Peter has extensive experience of working with industry, including several KTP projects and three university spin-out companies, one of which is on the London Stock Exchange since 2007 – eTherapeutics plc. Peter is member of the Board of Governors of the International Neural Network Society (INNS), Fellow of the Royal Society of Biology, Senior Member of the Institute of Electrical and Electronics Engineers (IEEE) and member of the UK Computing Research Committee (UKCRC), IEEE Computer Society, Society for Artificial Intelligence and Simulation of Behaviour (AISB), International Society for Artificial Life (ISAL) and the Society for Neuroscience (SfN). Peter serves on the EPSRC Peer Review College, the Royal Society International Exchanges Panel and the Royal Society APEX Awards Review College. He is also regularly serving as review panel member and project assessor for EU funding agencies. Outside academia, Peter has an interest in politics and community affairs. He served as local councillor in Newcastle upon Tyne, parish councillor in Keele and stood in general elections for the Parliament. He has experience of working with and leading community organisations and leading a not-for-profit regional development consultancy and project management organisation.

Ref: https://www.napier.ac.uk/people/peter-andras 

And, so, if you could pick one or two people who have contributed most to our online security, who would it be? Ron Rivest? Shafi Goldwasser? Ralph Merkle? Marty Hellman? Whitfield Diffie? Neal Koblitz? Well, in terms of the number of data bytes protected, that prize is likely to go to Joan Daemen and Vincent Rijmen, and who created the Rijndael method that became standardized by NIST as AES (Advanced Encryption Standard). If you are interested, Rijndael (“rain-doll”) comes from the names of its creators: Rijmen and Daemen (but don’t ask me about the rogue “l” at the end).

And, so, Joan Daemen was awarded the Levchin Prize at the Real World Symposium conference in 2016:

Now, his co-researcher, Vincent Rijmen — a Professor at KU Leuven — has been awarded the Levchin Prize at the Real-World Crypto Symposium [here]:

This follows illustrious past winners, including Paul Kocher (for work on SSL and side-channels), Dan Coppersmith (on cryptoanalysis), Neal Koblitz and Victor Miller (for their co-invention of ECC) and Ralph Merkle (for work on digital signatures and hashing trees).

Vincent’s track record in high-quality research work is exceptional and especially in the creation of the Rijndael approach to symmetric key encryption [here]:

Before AES, we had many symmetric key encryption methods, including DES, 3DES, TwoFish, BlowFish, RC4, and CAST. But AES came along and replaced these. Overall, ChaCha20 is the only real alternative to AES, and where it is used in virtually every web connection that we have and is by far the most popular method in encrypting data. And, it has stood the test of time — with no known significant vulnerabilities in the method itself. Whilst we might use weak keys and have poor implementations, Rijndael has stood up well.

With AES, we use symmetric key encryption, and where Bob and Alice share the same secret key:

In 2000/2001, NIST ran a competition on the next-generation symmetric key method, and Rijndael won. But in second place was Serpent, which was created by Ross Anderson, Eli Biham, and Lars Knudsen. Let’s have a look at the competition and then outline an implementation of Serpent in Go lang. In the end, it was the speed of Rijndael that won over the enhanced security of Serpent. If NIST had seen security as more important, we might now be using Serpent than Rijndael for AES.

NIST created the race for AES (Advanced Encryption Standard). It would be a prize that the best in the industry would join, and the winner would virtually provide the core of the industry. So, in 1997, NIST announced the open challenge for a block cipher that could support 128-bit, 192-bit, and 256-bit encryption keys. The key evaluation factors were:

Security:

• They would rate the actual security of the method against the others submitted.
• This would method the entropy in the ciphertext — and show that it was random for a range of input data.
• The mathematical foundation of the method.
• A public evaluation of the methods and associated attacks.

Cost:

• The method would provide a non-exclusive, royalty-free basis licence across the world;
• It would be computationally and memory efficient.

Algorithm and implementation characteristics:

• It would be flexible in its approach, and possibly offer different block sizes, key sizes, convertible into a stream cipher, and so on.
• Be ready for both hardware and software implementation for a range of platforms.
• Be simple to implement.

The call was issued on 12 Sept 1997 with a deadline of June 1998, and a range of leading industry players rushed to either create methods or polish down their existing ones. NIST announced the shortlist of candidates at a conference in August 1998, and which included some of the key leaders in the field, such as Ron Rivest, Bruce Schneier, and Ross Anderson (University of Cambridge) [report]:

• Australia LOKI97 (Lawrie Brown, Josef Pieprzyk, Jennifer Seberry).
• Belgium RIJNDAEL (Joan Daemen, Vincent Rijmen).
• Canada: CAST-256 (Entrust Technologies, Inc), DEAL (Richard Outerbridge, Lars Knudsen).
• Costa Rica FROG (TecApro Internacional S.A.).
• France DFC (Centre National pour la Recherche Scientifique).
• Germany MAGENTA (Deutsche Telekom AG).
• Japan E2 (Nippon Telegraph and Telephone Corporation)
• Korea CRYPTON (Future Systems, Inc.)
• USA: HPC (Rich Schroeppel), MARS IBM, RC6(TM) RSA Laboratories [try here], SAFER+ Cylink Corporation, TWOFISH (Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson) [try here].
• UK, Israel, Norway SERPENT (Ross Anderson, Eli Biham, Lars Knudsen).

One country, the USA, had five short-listed candidates, and Canada has two. The odds were thus on the USA to come through in the end and define the standard. The event, too, was a meeting of the stars of the industry. Ron Rivest outlined that RC6 was based on RC5 but highlighted its simplicity, speed, and security. Bruce Schneier outlined that TWOFISH had taken a performance-driven approach to its design, and Eli Biham outlined that SERPENT and taken an ultra-conservative philosophy for security in order for it to be secure for decades.

And so the second conference was arranged for 23 March 1999, after which, on 9 August 1999, the five AES finalists were announced:

• Belgium RIJNDAEL (Joan Daemen, Vincent Rijmen).
• USA: MARS IBM, RC6(TM) RSA Laboratories, TWOFISH (Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson)
• UK, Israel, Norway SERPENT (Ross Anderson, Eli Biham, Lars Knudsen).
• Canada: CAST-256 (Entrust Technologies, Inc),

The big hitters were now together in the final, and the money was on them winning through. Ron Rivest, Ross Anderson and Bruce Schiener all made it through, and with half of the candidates being sourced from the USA, the money was on MARS, TWOFISH or RC6 winning the coveted prize. While the UK and Canada both had a strong track record in the field, it was the nation of Belgium that surprised some and had now pushed itself into the final [here].

While the other cryptography methods which tripped off the tongue, the RIJNDAEL method took a bit of getting used to, with its name coming from the surnames of the creators: Vincent Rijmen and Joan Daemen.

Ron Rivest — the co-creator of RSA, had a long track record of producing industry-standard symmetric key methods, including RC2, and RC5, along with creating one of the most widely used stream cipher methods: RC4. His name was on standard hashing methods too, including MD2, MD4, MD5, and MD6. Bruce Schneier, too, was one of the stars of the industry, with a long track record of creating useful methods, including TWOFISH and BLOWFISH.

After nearly two years of review, NIST opened up to comments on the method, which ran until May 2000. A number of submissions were taken, and the finalist seemed to be free from attacks, with only a few simplified method attacks being possible:

As we can see in Table 1, the methods had different numbers of rounds: 16 (Twofish), 32 (Serpent), 10, 12, or 14 (Rijndael), 20 (RC6), and 16 (MARS). Rijndael had a different number of rounds for different key sizes, with 10 rounds for 128-bit keys and 14 for 256-bit keys. Its reduced number of rounds made it a strong candidate for being a winner.

In the AES conference to decide the winner, Rijndael received 86 votes, Serpent got 59 votes, Twofish 31 votes, RC6 23 votes, and MARS 13 votes. Although Rijndael and Serpent were similar, and where both used S-boxes, Rijndael had fewer rounds and was faster, but Serpent had better security. The NIST scoring was:

AES has advanced cybersecurity more that virtually all the other methods put together. Without it, the Internet would be a rats-nest of spying, person-in-the-middle attacks, and, would be a complete mess.

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:

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:

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]:

A sample run is [here]:

and:

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.

[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.

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]:

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:

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:

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.

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.

A hybrid scheme is defined here:

https://asecuritysite.com/pqc/circl_dil2

For our existing signatures, we have:

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:

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.

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

Please excuse me for using IBM in the title — I have the greatest of respect for a company that has continued to lead and innovate over the past six decades (and who have existed for over a century). The point of this article is to showcase where you, your team or your company have a deep passion for doing something great. For this, we go back to the roots of one of the greatest inventions in the history of humankind: The Internet.

In fact, we would probably not have the Internet without one magical little company (BBN) and the vision of one person (Larry Roberts). At the time, most had the word “FAILURE” written over the ARPANET project, and if it had failed, the Internet would probably never happen. Think about that for a few minutes.

If we go right back to the creation of ARPANET, it was Larry Roberts who published an RFQ (Request For Quote) to interested companies. The task was to build an IMP (Interface Message Processor) and route data across an interconnected network, and this connect disparate computer systems together. While most things at the time focused on cumbersome and centralised circuit-switching, Larry wanted to use a packet-switched approach.

And, so, the big companies prepared their bids and did their usual tendering processing — and basically took what they had, would just deliver to the requirements. Few of them had any faith in what was being built and could only see this as another failed government research project that went nowhere. And to integrate with academia, too, was always going to be a challenge, as academics would want to build something that protected their resources while enabling them to extend their research. In fact, IBM's solution was to use the large System 360 mainframe computer to undertake the task of routing data.

Anyone who has ever bidded for a government contract will know that when you submit it, you think you will win it, but this decays over time, and where you often move to a state of knowing that you will not get it.

But, while companies like DEC, Raytheon and IBM failed to see how the creation of the IMP would go anywhere, there was one company that put its heart and soul into the bid: BBN. In fact, it is thought that they spent around six months of time developing the bid. For this, they did a full investigation into the working of the IMP, and had even investigated the hardware and code that it would require. And, so, while they were honest in saying that it was going to be a major challenge, they then laid out the route to the solution and shared their insights. This showed to Larry that, like him, this was not just another project but one that would match the vision of the company.

And, for such a project, most of the companies defined long chains of authority and management, whereas BBN’s approach was to have a single point of focus, and a simplified management approach. Basically, there was a single contact for every question, rather than long lines of delegated responsibility.

At, the time, people used to say, “No one gets fired by buying IBM”, so Larry was laying his whole reputation on the line by going with this small company, which had little in the way of resources to compete with IBM or DEC. But, they had passion and vision and wanted the contract with all their lives. The company were successful in other ways and did not need the grant to sustain them- but they knew its importance. A failure of this project, and there would be no more building of packet-switched network — and possibly no future Internet. And, so, they invested much more time than virtually all the bidders put together.

In fact, BBN were actually the first to have an Autonomous System Number (AS1). This is a special number which makes routing on the Internet so much easier, as we just need to know which autonomous system to give our data too, in order to get it routed to the destination. This can be an intermediatory route through the AS, or where the AS hosts the target device.

The choice of an AS approach — using BGP (Border Gateway Protocol) — has really been one of the most fundamental elements in building the Internet at scale. While not perfect, it works! BBN also strived to secure BGP, as it was fundamentally important that no single entity — especially a malicious one — would take over the routing of the Internet. In fact, BBN invented the link-state routing method, and which allowed the “best” route to be discovered to a destination — through the intercommunication of routing tables from devices.

Now, Level 3 Communications uses AS1.

BBN, too, were one of the first companies to be an internet service provider and were the second organisation in the world to register a domain name (on 24 April 1985 with bbn.com):

And, here is the BBN Web page from 1985 [here]:

Why were BBN so successful? They had a passion and a drive, and they recruited the best talent around. In fact, BBN was sometimes know as the “the third university” in Cambridge, alongside Harvard and MIT. The key to any innovative company’s success is their HR function, and in making sure they get the best talent around. One great engineer with a passion and drive can often trump teams of hundreds. But, they must want to do the work — so must be given stimulating and challenging roles.

After innovating in so many areas, in 2009, BBN became a wholly owned subsidiary of one of the companies they beat off for the ARPANET contract: Raytheon.

And, so, if you really want something, put your heart and soul into it, and show the grant/contract reviewers that this is all just part of your vision to build a better world.

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.

1. Keys are created in the AWS KMS (Key Management Store). In Azure, this is named KeyVault.
2. The cost of using a key in KMS is around $1/month (prorated hourly). When a key is disabled, it is not charged.
3. With AWS KMS, we use a shared customer HSM (Hardware Security Module), and with AWS CloudHSM it is dedidated to one customer.
4. For data at rest, with file storage, we can integrate encryption with Amazon EBS (Elastic Block Storage) and Amazon S3.
5. Amazon EBS drives are encrypted with AES-256 with XTS mode.
6. For AWS-managed keys, a unique key is used for every object within S3 buckets.
7. 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.
8. AWS uses 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) for its symmetric key encryption.
9. In AWS S3, by default, all the objects are encrypted.
10. A customer can use client-side encryption to encrypt data before it goes into the AWS infrastructure.
11. 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).
12. 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).
13. 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.
14. To define a KMS key, we can either use its key ID, its key ARN, its alias name, or alias ARN.
15. 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.
16. 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.
17. The application of the keys is restricted to defined services.
18. Key identifiers and policies are defined with a JSON key-value pair for data objects.
19. Each key should have a unique GUID, such as “de30e8e6-c753–4a2c-881a-53c761242644”.
20. Users are identified and roles are identified with an ARN, such as : “arn:aws:iam::222222:root”.
21. With the usage of keys we have Key Administrative Permission and a Key Usage policies.
22. There is an explicit denial on a policy if there is not a specific allow defined in a policy.
23. 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.
24. 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”: “*”}.
25. The main operations within the KMS are to encrypt/decrpyt data, sign/verify signatures, export data keys, and generate/verify MACs (Message Authentication Codes).
26. Key are either AWS managed (such as for the Lambda service), Customer managed keys (these are created and managed by the customer).
27. Custom key stores are where the customer has complete control over the keys).
28. The main use of keys are for EC2 (Compute), EBS (Elastic Block Storage) and S3 (Storage).
29. AES symmetric keys or an RSA key pair are used to encrypt and decrypt.
30. RSA uses 2K, 3K or 4K keys, and with either “RSA PCKS1 v1.5” or “RSA PSS” padding.
31. 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.
32. For RSA, we can use a hashing method of SHA-256, SHA-384 or SHA-512.
33. In RSA, we encrypt with the public key and decrypt with the private key.
34. 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).
35. 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.
36. KMS uses hardware security modules (HSMs) with FIPS 140–2 and which cannot be accessed by AWS employees (or any other customer).
37. Keys will never appear in an AWS disk or backup, and only existing the memory of the HSM. They are only loaded when used.
38. Encryption keys can be restricted to one region of the world (unless defined by the user).
39. 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.
40. AWS CloudWatch shows how and when the encryption keys are being used.
41. The minimum time that can be set for a key to be deleted is seven days (and up to 30 days maximum).
42. 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.
43. The usage of encryption keys should be limited to a minimal set of service requirements.
44. If possible, separate key managers and key users.
45. 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.
46. For a key user (KEY_WORKER) role, we cannot create or delete keys and typically focus on tasks such as encrypting and decrypting.
47. 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.
48. Avoid manual updates to keys and use key rotation. The system keeps track of keys that are rotated and can use previously defined ones.
49. The default time to rotate keys is once every year.
50. Key rotation shows up in the CloudWatch and CloudTrail logs.
51. KMS complies with PCI DSS Level 1, FIPS 140–2, FedRAMP, and HIPAA.
52. AWS KMS is matched to FIPS 140–2 Level 2.
53. AWS CloudHSM complies with FIPS 140–2 Level 3 validated HSMs.
54. AWS CloudHSM costs around $1.45 per hour to run, and the costs end when it is disabled or deleted.
55. The CloudHSM is backed-up every 24 hours, and where we can cluster the HSMs into a single logical HSM.
56. CloudHSM can be replicated in AWS regions.
57. AWS KSM is limited to the popular encryption methods, whereas the CloudHSM can implement a wider range of methods.
58. 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.
59. 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.
60. With the CloudHSM, we have a command line interface where we can issue commands, and is named CloudHSM CLI.
61. 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
62. With genSymKey the key types are: 16 (Generic Secret), 18 (RC4), 21 (Triple DES), and 31 (AES).
63. 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
64. AWS CloudHSM is integrated with AWS CloudTrail, and where we can track user, role, or an AWS service within AWS CloudHSM.
65. With AWS Payments Cryptography, the 2KEY TDES is Two-key Triple DES and has a 112-bit equivalent key size.
66. 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.
67. S3 buckets can be encrypted either with Amazon S3-managed keys (SSE-S3) or AWS Key Management Service (AWS KMS) keys.
68. There is no cost to use SSE keys.
69. 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.
70. 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.
71. 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.
72. 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).
73. 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].
74. You can BYOK (bring your own key) with KMS, and import keys. KMS will keep a copy of this key.
75. With XKS, we need a proxy URI endpoint, with the proxy credentials of an access key ID, and secret access key.
76. 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).
77. A strong password should always be used for key wrapping.
78. AWS encryption operations can either be conducted from the command line or within API, such as with Python, Node.js or Golang.
79. 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.
80. 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
81. 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
82. In Python, to integrate with KMS, we use the Boto3 library.
83. 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.
84. The base64 command can be used to convert byte format in Base64, such as with: $ base64 -i 1.out — decode > 1.enc
85. 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:
86. 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')
87. 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)))
88. 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
89. 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
90. 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
91. 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
92. 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
93. 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
94. 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
95. 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
96. You cannot encrypt data with Elliptic Curve keys. Only RSA and AES can do that. Elliptic Curve keys are used to sign data.
97. If you delete an encryption key, you will not be able to decrypt any ciphertext that uses it.
98. 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
99. In China regions, along with RSA and ECDSA, you can use SM2 KMS signing keys.
100. In China Regions, we can use SM2PKE to encrypt data with asymmetric key encryption.

Find out more here:

https://asecuritysite.com/aws

Well, here are a few tips for PhD students and ECR (Early Career Researchers):

1. Enjoy doing research. It is fun and one of the few times in your career when it is solely your work. To do a PhD is a privilege and not a chore. You will likely look back on it as one of the most useful things you did in your whole career.
2. You will always hit a dip in your research. Know when that is happening, and find ways out of it. Change something in your approach. Re-ignite yourself with new topics or methods. Find a great new paper that has just been published. Fight the dip!
3. Two years of a PhD pass by fast. Be ready for the “last year of research” spike.
4. We often do research to repeat what others have done and add our little bit. You can’t add your little bit unless you have repeated the work of others.
5. Validate and verify your work before you evaluate it. One slip, and everything can fall apart. Most people have flaws in initial version of their work, so don’t worry if you find flaws, it’s all part of refinement of your work. We are human, by the way!
6. Be able to show an external person the work you have done in validating that what you have is correct. Always be ready to point to peer review work to show that something is correctly defined.
7. Doodles with pen and paper are great for getting your mind in gear.
8. Have a thick skin — both from your supervisors, others around you, and, most of all, peer reviewers and your external examiner.
9. Most peer reviewers are trying to help you, while others are just nasty for the sake of it or have not created the paper that they wanted. Try to spot the bad/nasty reviewer and focus on the helpful reviewers.
10. Few people see your failures, but most will see your successes. Know your successes when they arrive, and write them down as your progress. At the end of your work, you should be able to show the successes you had along the way.
11. Have a vision for your work, and continually refine it. Define your own beliefs, ethics and standards for your work and stick to these, such as “I will not release drafts to review, until I have fully read them”, “I will return updates to drafts of comments from my supervisors within one week”, and “I will not publish in poor quality outlets”. Agree these with your supervisory team, and get them to commit to things from their side.
12. Define missions within your work and strive for these, and when that mission is achieved, go on to the next one (unless your get to the end, of course).
13. Don’t end up just being theoretical. A core part of a PhD is doing practical work, too. Make sure you code and experiment. Don’t spend one year doing a literature review. Get coding and run experiments.
14. A thesis is not a chronological diary. It should be written with an aim to show some new novely or knowledge, and not the sequence of things you did in your research.
15. Throughout your work, especially in the 2nd and 3rd year of a PhD, continually run small experiments and get some results.
16. Have a hypothesis about experiments, and prove or disprove this.
17. Know the top people in your field, and be able to quote their work.
18. Be inspired by other researchers.
19. Be humble about your own work, and help others.
20. Ask for advice from others where your supervision team lack skills, such as contacting pure mathematicians or physicists. Don’t be shy in saying that you don’t understand something.
21. Don’t ever copy and paste work from others into your own work. Rephrase in your own words.
22. Don’t use AI tools for descriptions. The reader will typically spot these — as the writing style often changes.
23. Be consistent in your writing style.
24. Read the work of others — especially great science/technical writers — and understand the methods they use to engage readers.
25. Define simple, practical and useful abstractions of the techniques you are defining. Abstract your work into other areas and get them to think in other ways around the methods you are defining … “let’s think about the little boy who put his finger in the dam; if we had a mathematical equation for this, we would …” Many would define this as, “Explain it to a smart 12-year-old child”.
26. Explain your work to your family and friends. If they can’t understand the problem and your solution, refine it until they can.
27. Always be ready to give an elevator pitch … you have two minutes in a lift with Bill Gates and need to define the problem, your solution, and the potential.
28. Know the potential impact of your work. Is it technical advancement? Is it social change?
29. If everything worked well, and you did invent an amazing new widget, what you be the best outcome? A tech unicorn? Saving 1,000s of lives? Reducing carbon emissions? Improving people’s lives?
30. Protect your IP when you need to. Patents are one way to do this, so just don’t blindly publish every you have.
31. If you read papers and do not quite understand how the method works, reach out to the writers of the paper, and ask questions or pose ideas. They might not reply, but if they do, they may help you with your thoughts.
32. Build a network of contacts outside your university, and be part of a community that shares knowledge.
33. Supervise undergraduate students for their dissertations — but be considerate, and don’t expect them to be working at a PhD level.
34. Know why you are doing research and your end objective.
35. Define whether the PhD is an end goal or that it is defining the start of a research career.
36. Plan your research career and aim for the job you hope to get in the future.
37. Don’t add your name to poor-quality work … you will get a bad reputation. Know what esteem looks like in your area, and try and build it. Avoid publishing work which you are not proud of.
38. If it is mainly your work, you must be the first author on the paper.
39. Don’t use the first person of “I” or “me” in any publication or thesis, unless you are giving a personal statement of something.
40. In reporting on your research progress, showcase that you can summarise well, and show examples of your research writing without over doing it.
41. Learn a new method every day/week.
42. Don’t just read about a method; try and implement it in code, and see if it works.
43. An abstract is not an introduction! The creation of an abstract is an art and is a distilled version of the thesis/paper.
44. The title is the first thing that someone sees, so get it right!
45. The abstract is the second thing that someone sees, so make sure that it is beautifully crafted and that the reader can finish there and know all about your work.
46. Review, rewrite, review, rewrite, review, rewrite your abstract, and fit it into one page.
47. The introduction and conclusions of each chapter are like bread in a sandwich. Make sure they hold the sandwich together.
48. Review your introductions to chapters, and bring your reader back to the focus of the thesis and what you are going to show them.
49. An introduction to a chapter should be less than one page, otherwise, it is too rambling.
50. Get on point as to what a chapter intends to do, and get rid of anything that deviates away from that.
51. Use appendices to park material that just does fit in a chapter, but the remainder to reference them. Few people ever read an appendix, so they possibly need less rigour in their structure and presentation.
52. In a thesis, every word matters. Get rid of words that are not required.
53. Enjoy some downtime, find a nice space, and properly read a paper. If possible, spend 2–4 hours just reading a paper without distractions.
54. Find a buddy, read a paper together, and discuss it. This could be your supervisor, but you may find that they do not read the paper.
55. Make sure that your supervisor checks your work for accuracy. If they do not, get someone else you trust to check the work.
56. Do not submit papers without knowing that you have checked fully for typos and bad grammar. It is a sign of a weak research team that a paper is full of annoying typos and an easy rejection.
57. Make sure your papers have all the right features so that you will not get a rejection on the layout of a paper. Enough references? No typos? Aim and contribution defined? The literature review covered? The method defined clearly? Results will present? Conclusions bring back the main contrition and significant result?
58. Read your work aloud, and if you stumble on the words … rewrite it.
59. Be kind to your read, and break up long runs of text with diagrams.
60. Know your target reader(s) and their knowledge. Consider adding a theory/background chapter if you feel they need it, but also allow them to skip it if they know the area.
61. A literature review is full of references. Virtually every paragraph should have at last one reference — otherwise, it is not a literature review.
62. If you can, avoid the same reference being used continually for your literature … otherwise you are outlining someone else's work and not yours.
63. Don’t add your own analysis of methods in the literature review; leave that for later, such as in the conclusions. Everything in the literature review is the basis of published work.
64. Avoid poor quality sources … paper mills, blog posts, and social media quotes (unless your whole thesis is focused on this). Papers published in paper mills with poor standards should never be used as they have not been rigorously reviewed.
65. A picture is worth many words. Be kind to your reader, and abstract your thoughts with nice (and simple) diagrams that are not copied from others but your own thoughts on the topic, and which link to the narrative. In fact, draw your chapter with pictures, first, and then write around these pictures.
66. In your diagrams, avoid small text, poor contrast, and too much complexity.
67. Remember to add a reference in the text to every figure and every table. These references should appear before the figure or table.
68. Don’t break your text with a figure. Make sure it floats to the bottom or the top of the next page.
69. A chapter should be between 15 and 25 pages. If it is longer, split the chapter. If it is shorter, consider merging with another chapter.
70. The best PhD thesis’ has a core around five themes: Introduction; Literature Review; Method; Evaluation; and Conclusions.
71. Be up-front about your contribution, and don’t overclaim that you have solved every problem in the area.
72. Be humble, and be open about whose work you build on.
73. Don’t have long paragraphs of text … give your reader a break, and them up with paragraphs (but don’t make them too short, too). A rule of thumb — a paragraph should be at least 2–3 sentences and probably less than half a page of text.
74. Read, revise, read, revise, read, revise … get into a spirit of continually reading your work.
75. Trace relevant recent publications back to the classic paper, which started a whole field of enquiry, and read that.
76. Your writing skills will improve over time. Go back over things you have written in the past, and rewrite them.
77. Speak to the reader as if they were in the same room as you.
78. The first paper of a paper or thesis is the most important part. Tell the reader the significance of the problem and why they should be interested. Hit them with facts and figures that are significant.
79. Up-front, tell them what you are going to show them … it’s not a secret, and it is too late — at the end — to show them.
80. Avoid Microsoft Word wherever possible, and use LaTeX (such as with Overleaf). Once you get over the barrier of learning to create a mark-up document, your production will be so much higher, and you will produce nicely defined papers in an instant.
81. Use GitHub to store your code and documents. But, remember to keep it private and only share it with trusted people.
82. Link your LaTeX document to GitHub, and regularly back up.
83. If you can, enable version control on your document, and keep a trace of editing updates.
84. Rather than sharing a draft paper in a PDF with your supervisors, send them a share of the Overleaf document.
85. Initially, in the first stages of your research, ask supervisors to clearly mark up typos, bad grammar and mistakes. At later stages, it is probably acceptable to allow them to update without highlighting.
86. When you read a great paper, mark it up with a highlighter (either paper-based on highly on PDF) … show your supervisor how detailed you read a paper, and discuss these points with them.
87. Keep a paper log book of your work, and write down your thoughts and ideas as you go along. Remember to put the date on it and get it signed by your supervisor on a regular basis — especially when you have a breakthrough.
88. Think about the best way to present results and try to aggregate them together rather than having long sequences of diagrams and tables. A single table is often the best way to bring all your results together.
89. A graph has an x-axis and a y-axis — make sure you label these correctly.
90. Microsoft Excel is often poor at drawing graphs. Try to properly present at a quality which could be publishable.
91. Figure labels go below the diagram, and table labels go above the table.
92. Avoid summaries at any point in a thesis. This can just annoy the reader, as they have just read all the work. Leave your summary to the end of a chapter.
93. Be focused on your conclusions, and recap the main things you are taking forward and what you are rejecting. A good conclusion can be fitted into less than one page.
94. The tail-end of the thesis is the conclusion and the future work. Bring back the problem statement and your objectives, and tell the reader how the thesis addresses these, and the main significance of your work. Remember to conclude all parts of your thesis, too. And, be humble, and show that you have not solved everything in the area and where your work can be improved.
95. The future work is your chance to shine, and where others can follow your work. Get it right, and help others.
96. Get enterprise training early on, and understand how your work could be used by who and why?
97. If you can, do some maths. Layout your maths properly, and, for example, don’t use “*” for multiplication. Use a proper LaTeX equation layout for these. Remember to also use in-text equation markup too, and name and describe every variable used.
98. Store the data from all your experiments, as it may be asked for in the future.
99. Write blogs and do some public engagement, and modify your writing and presentation style to suit.
100. If you are an ECR, don’t lose the skills you picked up on your PhD … still read papers and have your own vision and mission statements.
101. Go deep in your research rather than surface learning. Get some textbooks, and read about the background theory.

Here are my 100 interesting things to learn about cryptography:

1. For a 128-bit encryption key, there are 340 billion billion billion billion possible keys. [Calc: 2**128/(1e9**4)]
2. 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)]
3. 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.
4. 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.
5. With symmetric key encryption, anything below 72 bits is relatively inexpensive to crack with brute force.
6. 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.
7. 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.
8. 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).
9. 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.
10. 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.
11. 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.
12. A salt/nonce or Initialisation Vector (IV) is used with an encryption key in order to change the ciphertext for the same given input.
13. Stream ciphers are generally much faster than block cipers, and can generally be processed in parallel.
14. 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).
15. 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.
16. Ralph Merkle’s PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method).
17. 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.
18. 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.
19. Adi Shamir broke the Merkle-Hellman knapsack method at a live event at a rump session of a conference.
20. 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.
21. 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”.
22. In public key encryption, we use the public key to encrypt data and the private key to decrypt it.
23. 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.
24. 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.
25. The RSA method came to Ron Rivest while he slept on a couch.
26. 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.
27. 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.
28. 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.
29. The binary value of 65,537 is 10000000000000001 — this number is efficient in producing ciphertext in RSA.
30. 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).
31. 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.
32. Anything below a 738-bit public modulus is relatively inexpensive to crack for RSA.
33. To crack 2K RSA at the current time, we would need the energy to boil ever ocean on the planet to break it.
34. 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.
35. 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.
36. 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.
37. 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).
38. ECC (Elliptic Curve Cryptography) was invented by Neal Koblitz and Victor S. Miller in 1985.
39. Elliptic curve cryptography algorithms did not take off until 2004.
40. 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.
41. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security.
42. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass (“Vier-strass”) curve.
43. The prime number used with secp256k1 is 2²⁵⁶-2³²-2⁹-2⁸-2⁷-2⁶-2⁴-1.
44. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a “04”.
45. 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”.
46. 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.”
47. 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.
48. 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.
49. ECDSA is a digital signature method and requires a random nonce value (k), and which should never be reused or repeated.
50. ECDSA is an elliptic curve conversion of the DSA signature method.
51. Digital signatures are defined in FIPS (Federal Information Processing Standard) 186–5.
52. 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).
53. ChaCha20 is a stream cipher that is based on Salsa20 and developed by Daniel J. Bernstein.
54. 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.
55. 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.
56. 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.
57. 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.
58. 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.
59. Hashing methods can be slowed down with a number of rounds. These slower hashing methods include Bcrypt, PBKDF2 and scrypt.
60. Argon 2 uses methods to try and break GPU cracking, such as using a given amount of memory and defining the CPU utlization.
61. 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).
62. 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.
63. 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).
64. 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).
65. 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.
66. 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.
67. It is estimated that Bitcoin miners consume 17.05 GW of electrical power per day and 149.46 TWh per year.
68. 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.
69. RSA, ECC and Discrete Log methods will all be cracked by quantum computers using Shor’s algorithm
70. Lattice methods represent bit values as polynomial values, such as 1001 is x³+1 as a polynomial.
71. 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.
72. 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”.
73. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment.
74. 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.
75. 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.”
76. 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.
77. 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.
78. 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”.
79. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge).
80. 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.
81. 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.
82. 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).
83. 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.
84. 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.
85. 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.
86. 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.
87. Curve 25519 uses the prime number of 2²⁵⁵-19 and was created by Daniel J. Bernstein.
88. Peter Shor defined that elliptic curve methods can be broken with quantum computers.
89. 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.
90. 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.
91. 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.
92. 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.
93. 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.
94. 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.
95. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477.
96. 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.
97. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains.
98. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers.
99. 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.
100. 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.

Interview here:

Your organisation needs a vision. Without it, you will never be great. You will never advance. You will keep doing the same old things and without any real purpose. A vision gives you a purpose and a focus. But, it needs to have a plan which takes you there. But, without it, how can you ever plan? For any great organisation, you start with a vision.

So, what about a vision for the NHS? I appreciate that I am only a technologist, but I am also a citizen, and I care about the health and well-being of my fellow citizens. I also don’t like bureaucracy and inefficiencies — and I strive in my working life to overcome these. So, our work has generally focused on improving the citizen’s viewpoint of health care.

And, so, I am honoured to present at Digital Scotland 2023 this year, and on a topic which has been our passion for over a decade — a citizen-focused health care system:

I have attended conferences in Scotland and which talk about “citizen-focused health care”, and the audience all go away inspired and ready to build new digital worlds for citizens. But nothing happens, and then we repeat the next year again. Well, this year, I will show that a vision can be created as a reality. With digital wallets, the technology is all in place, and there are no great barriers to overcome, any more.

During the COVID-19 time, there was some hope for digital advancedment and where we saw the use of digital passports — but we have failed to build of these, and have ended up with little in the way of digital engagement between the NHS and the citizen.

So here’s the problem and my vision — and it’s quite simple.

I have interacted with the NHS for several decades — luckily, I have never had any medical ailments, but have observed it in relation to others. I have seen some truly shocking practices in dealing with patient records -including for someone in my family have “Do not resuscitate” written on their records without any discussion with the family, and where a physical filing cabinet of patient records had to be moved by taxi from one hospital in Edinburgh to another one.

Overall, there is often great resistance to change and to the adoption of digital methods. The Connecting for Health programme — which cost over £15 billion — had to be eventually cancelled, as it delivered nothing.

Why? Well, one reason is, “Won’t this replace my existing job of writing down the details?”, “Yes, but you can do and do something even better with your time”, “But, this is what I was trained for. Anyway, I don’t trust computers, anyway!”

And, so, recently, I went to register for a GP and was handed a piece of paper and told to find a pen and write down all my details. In virtually every interaction with the NHS, I have had to do this, and perhaps, one day, I will have all my medical details stored on a digital wallet on my phone, and where the GP just scans them in. Once I filled in it, it then went into a black hole — and where I hoped that a human would eventually make sense of my scribbles.

To date, I have yet to receive any confirmation that I have been registered, and I have no on-line place to check my details. The NHS can hardly get to first base in creating a proper online world for my data. It fleetingly sends me the odd email or SMS message, but it still sits behind a high wall.

Overall, in places, it feels like there are still parts of our lives that are stuck in the 20th Century.

Let me dream now. One day, I will register for a new GP. I will walk in, and the receptionist will ask me to register. I will press a few buttons and generate a QR code. They will scan this in, and an instant message will appear to say that I am now registered and say that all my details have been registered,

“Ah, Nice to meet you, Bill. I see it is your birthday today. Please can you check your details are okay and consent to its storage?”. “All looks good”.

“How would you like us to contact you, by email or SMS?”, “Email. Please. Here is the QR code for my email address, and you can scan it”.

When I go to see the GP, they ask me for my weight and height, and, again, I go to my wallet and generate a QR code and where the GP scans it in and says,

“That’s great. All is okay. But your BMI is a little high, and a little up from the last time we meet. I will store this in your record, and we can keep a track on it. I will email you some recommendations for your diet”.

How long will it take for this to ever happen? Well, it’s actually not that difficult. We are part of an EU project which has developed the GLASS wallet and which puts the control back in the citizen’s hands:

So, why not come and see it live on 12 Sept in London [here]:

And in November [here]:

We have a dream for an improved healthcare system — and we have had this dream for over a decade. The technology is all in place — we now need to use it and put the power back into the hands of those who really matter — the citizen!

I remember attending a talk many years ago, and the presenter said, “I’ve got this amazing tool called Lotus 123”, and he gave a practical demo of doing some calculations. People in the audience were stunned by the simplicity of its operation. It was the birth of the thing that drives many businesses … spreadsheets. They are just so simple to use, and we all love them. And so, in the PSNI (Police Service of Northern Ireland) data breach, it is a simple Excel spreadsheet that is being pin-pointed as the carrier of highly-sensitive information.

Overall, in the breach, there were four major failings:

1. A lack of training and awareness from those handling the FoI request.
2. A lack of checking and sign-off within the process.
3. Documents should be marked with the security classification, and access rights defined properly to highly confidential documents.
4. The use of spreadsheets to store sensitive data.

I hope that the first two are quite obvious in mitigating … send staff on cybersecurity courses, and improve your sign-off procedures. Now, let’s turn on the mighty Microsoft Excel.

Well, they are NOT DATABASES and should not be used as a database. I’ve done quite a few code reviews and am always shocked by the number of back-end databases that use Microsoft Excel. Basically, Excel is a basic computing engine that is optimized for small problems and not for those that a database can cope with.

But, the main weakness is that they have virtually no inbuilt security and should not be used for sensitive data. Unfortunately, Microsoft has never really properly integrated security into Excel, and even encrypted documents are flawed in their operation.

The cyber-aware world has moved on from spreadsheets, and in many organisations, we see SAS (Software as a Service), which restricts access to data. Only those with the rights to access key elements of the data can get access to it. HR systems, too, are carefully guarded in cloud-based systems. In fact, moving your data into the public cloud really gives you an excellent viewpoint on how to protect sensitive data. I’ve seen some excellent data protection teams operating in banks, and much of their work is driven by automated software.

I appreciate that data sometimes needs to be exported into a spreadsheet, but if it does, it should be encrypted in its form and not rely on the operating system to do this.

Perhaps law enforcement — in places — is a decade behind the finance industry in setting up SOCs (Security Operations Centres), and where a well-run security infrastructure would be continually scanning for sensitive documents. Data protecting procedures have been implemented in many finance companies for years, and where scanners pick up documents that are stored in places they shouldn’t be.

Network scanners, too, can pin-point sensitive documents within the infrastructure, and also when sent outside the network. Any document that leaves an organisation such as the police should, at least, be triaged, no matter if it is for email or Web. The detection of telephone numbers, personal names and addresses in a document is fairly trival with the usage of regular expressions. An alert should have gone up with the loading of a file with so many personal details.

Policing needs to learn from this data breach. They need to increase awareness and implement training, along with better sign-off procedures. But, basically, the need to catch up with the rest of the world and implement proper safeguards on sensitive information. The days of marking a document as “confidential” are gone — we need better data handling, and spreadsheets are typically not part of this for highly sensitive information.

I believe that the police and other government agencies can learn a great deal from the finance industry on cybersecurity practices. They are the most attacked sector, but have one of the lowest amounts of data breaches.

So, here’s my Top 100 snippets of knowledge for blockchain:

1. 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.
2. 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”.
3. 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.
4. 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.
5. Ralph Merkle’s PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method).
6. 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”.
7. Miners gather transactions on a regular basis, and these are added to a block and where each block has a Merkle hash.
8. The first block on a blockchain does not have any previous blocks — and is named the genesis block.
9. 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.
10. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment.
11. Craig Steven Wright has claimed that he is Satoshi Nakamoto, but this claim has never been verified.
12. Most blockchains use elliptic curve cryptography — a method which was created independently by Neal Koblitz and Victor S. Miller in 1985.
13. Elliptic curve cryptography algorithms did not take off until 2004.
14. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security.
15. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass (“Vier-strass”) curve.
16. The prime number used with secp256k1 is ²²⁵⁶−²³²−²⁹−²⁸−²⁷−²⁶−²⁴−1.
17. Satoshi published a 9-page paper entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” White Paper on 31 Oct 31, 2008.
18. 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.
19. Satoshi focused on: a decentralized system, and a consensus model and addressed areas of double-spend, Sybil attacks and Eve-in-the-middle.
20. 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.
21. Satoshi used UK spelling in his correspondence, such as using the spelling of “honour”.
22. 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).
23. On 12 Jan 2009, Satoshi sent the first Bitcoin transaction of 50 BTC to Hal Finney [here].
24. A new block is created every 7–10 minutes on Bitcoin.
25. In Aug 2023, the total Bitcoin blockchain size is 502 GB.
26. 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.
27. 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.
28. Bitcoin uses a gossip protocol — named the Lightning Protocol — to propagate transactions.
29. A Bitcoin wallet is created from a random seed value. This seed value is then used to create the 256-bit secp256k1 private key.
30. 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.
31. BIP39 allows for the conversion of the key to a number of languages, including English, French and Italian.
32. A private key in a wallet is stored in a Wif format, and which is a Base58 version of the 256-bit private key.
33. 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.
34. A 256-bit private key has 115,792 billion billion billion billion billion billion billion billion different keys.
35. 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.
36. 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.
37. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a “04”.
38. 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”.
39. 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.”
40. In Ethereum, the public key is used as the identity of a user (a.G), and is defined as a hexademical value.
41. 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.
42. 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.”
43. 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.
44. 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.
45. 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.
46. 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.
47. 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.
48. 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.
49. The difficulty of the mining is defined by the hashing rate. At the current time, this is around 424 million TH/s.
50. There are around 733,000 unique Bitcoin addresses being used.
51. 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.
52. Bitcoin currently consumes around 16.27 GWatts of power each year to produce a consensus — equivalent to the power consumed by a small country.
53. 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’.
54. 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’.
55. 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.
56. 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.
57. Ethereum creates NFTs (Non-Fungible Tokens) with ERC721 tokens. We mint these each time and each is unique.
58. Solidity is the programming language used in Ethereum, while Hyperledger can use Golang, Node.js and Java.
59. For Ethereum, we compile Solidity code into EVM (Ethereum Virtual Machine) code. This is executed on the blockchain.
60. Blockchain uses the SHA-256 hash for transaction integrity.
61. 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.
62. 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.
63. The DAO is a decentralized autonomous organization (DAO) for the Ethereum blockchain and was launched in 2016.
64. 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.
65. 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.
66. 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”.
67. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge).
68. 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.
69. 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.
70. 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).
71. 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.
72. 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.
73. 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.
74. 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.
75. Curve 25519 uses the prime number of ²²⁵⁵-19 and was created by Daniel J. Bernstein.
76. Peter Shor defined that elliptic curve methods can be broken with quantum computers.
77. 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.
78. 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.
79. 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.
80. 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.
81. 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.
82. 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.
83. 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.
84. 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.
85. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477.
86. 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.
87. 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.
88. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains.
89. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers.
90. Solidity programs can be compiled with Remix at remix.ethereum.org.
91. 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.
92. 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.
93. The private key can be revealed from two ECDSA signatures which use the same random nonce value.
94. Polkadot is a blockchain which allows blockchains to exchange messages and perform transactions.
95. 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).
96. 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.
97. 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.
98. 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.
99. 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.
100. 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 𝑎=𝑔^x and 𝑏=ℎ^x and can prove the knowledge of x by showing that log_𝑔(𝑎)=log_ℎ(b).

Blog: here.

You can just imagine the movie trailer …

“Your worst enemy has taken over all your flights, and you cannot remove them from your network. They demand a $1 billion ransom, or else they will bring every flight down. Bob accidentally removes one of the controllers — you now only have 25 minutes to save the lives of those in the air!”

We have all seen movies with a dead man switch — and where an elaborate mechanism is created for someone to be killed if a random is not paid. But, anyone who tampers with the mechanism will cause the dead man switch to activate and kill the target. Now, this approach is coming to attacks on CNI (Critical National Infrastructure) and industry control systems (ICS).

We have generally been fortunate that PLC (Programmable Logic Control) systems have been largely untouched by cyberattacks. But that is no reason to not focus on their security. Significant risks exist, especially for attacks against CNI — as highlighted with Stuxnet.

In a new paper, Richard Derbyshire and a research team at Orange Cyberdefence [here] and Lancaster University focus on the scenario where an entire environment is controlled by an adversary and where all of the assets poll each other to make sure they remain untampered. Any changes to the configuration or a removal of any of the controllers will cause the system to go “Full ON” — and is similar to a Dead Man’s switch [1][here]

The paper outlines the increase in cyber extortion (Cy-X) tactics and where a key focus now is typically to both encrypt the target’s data and exfiltrate their data. In most cases, this type of approach can be defended against in a PLC environment — by replacing existing hardware or resetting the configuration of devices (which is equivalent to a restore from backup). DM-PLC showcases a methodology which will overcome these recovery methods.

In 2016, the CrashOverRide malware was installed on the Ukrainian critical infrastructure, and which resulted in a cyber attack on the power supply network. It happened on an electrical transmission station near the city of Kiev (Ukrenergo), in December 2016 and resulted in a black-out for around 20% of the Ukraine population. Luckily, it only lasted for one hour, but many think that it was just a test — a dry run — for a more sustained attack.

This attack has now been traced to the Crash Override (or Industroyer) malware. A previous attack on the Ukranian power infrastructure in 2015 involved the manual switch off of power to substations, but the newly discovered malware learns the topology of the supply network — by communicating with control equipment within the substations — and automatically shutdown systems.

The company who analysed it (Dragos) thinks that it could bring down parts of the energy grid, but not the whole of it, and that the activation date of the malware sample was 17 December 2016. They also defined that the malware can be detected by looking for abnormal network traffic, such as looking for substation locations and probing for electrical switch breakers.

Many suspect it may have been sent through phishing emails (as with the 2015 attack), and where Crash Override infected Microsoft Windows machines within the target network and then mapped out control systems in order to locate the key supply points, along with recording network activity which can be sent back to the controllers of the malware.

After the discovery phase, it is thought that Crash Override can load up one of four additional modules, and which can communicate with different types of equipment (such as for Honeywell and Siemens systems). This could allow it to target other electrical supply networks within different countries.

In 2018, too, it was reported that the Triton malware brought down safety systems for an oil and gas network in the Middle East [here]. This was achieved by the reverse engineering of the firmware used by device controllers and focused itself on specific parts of the infrastructure. A typical attack can often involve disabling safety systems — and which will protect the infrastructure on a system overload. When an overload does occur, the safety systems do not then protect the equipment, and this can lead to severe physical damage of the infrastructure. A tripping of just one part of the safety system, too, can cause a chain reaction, and bring down a large part of the infrastructure.

With DM-PLC, all of the PLCs and engineering workstations (EWs) constantly poll each other and detect any deviations from the required attack behaviour — and thus disallow any changes to the overall running of the adversories objectives. If the system is tampered with, it activates a Dead Man’s switch, and where the PLCs set their outputs to “ON”. This could have a devastating effect on the physical infrastructure that the PLCs connect to. This — the research team say — moves away from the traditional ransomware approach of encrypting data within the infrastructure to one that allows the system to continue, but under the adversary’s command.

Figure 1 outlines the basic setup and where the team set up a number of objectives [1]:

1. Deployable with minimal prerequisites from an EW.
2. Runs in parallel to existing operational code.
3. Does not impact existing operational code.
4. Is resilient to tampering/response and recovery processes.
5. Includes tamper detection.
6. Can enact undesirable wide-spread operational impact.
7. Requires a key to relinquish control back to system owners.
8. Can be tested prior to being armed.

The main focus of the work is to define a framework for a DM-PLC, and then define mitigation techniques. In order to keep the deadlock, the devices then monitor each other for changes (Figure 2), and where alerts are raised for any perceived changes.

Overall, the team successfully tested three main operations [1]:

1. A PLC being removed from the network.
2. The DM-PLC ransom timer expiring.
3. The victim entering a code having ‘paid’ their ransom.

In a scenario with three PLCs, Figure 3 shows the response to PLC 3 being removed from the network and where PLC 1 and PLC 2 set their outputs to 1 after 25 seconds — which causes the Dead Man switch to activate.

Thus, someone taking PLC 3 off the network has 25 seconds before the whole of the network goes into “full ON” mode.

Dead Man PLC sounds like a script for a movie, but it is a movie that could play for real. Our CNI is precious, and we need to protect it. Otherwise, here’s another movie …

“Your worst enemy has taken over all the fun rides, and you cannot remove them from your network. They demand a $1 billion ransom, or every ride will stop instantly. Bob accidentally removes one of the controllers — you now have 25 minutes to save lives!”

[1] Derbyshire, R., Green, B., van der Walt, C., & Hutchison, D. (2023). Dead Man’s PLC: Towards Viable Cyber Extortion for Operational Technology. arXiv preprint arXiv:2307.09549.

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:

1. Cryptography is both an art and a science.
2. Cryptography needs to be both theoretical and practical — one without the other leaves gaps.
3. The maths is not actually that difficult — it is just the way that researchers talk about it that is a problem.
4. Know your knowledge gaps — and plug them.
5. Your university education is unlikely to have properly set you up for the serious world of cryptography.
6. Crypto is cryptography and not cryptocurrency.
7. Few methods are perfect — know the limits of any method you use.
8. Don’t cook your own crypto! How many times do you have to say this to yourself?
9. Security-by-obfuscation never works that well.
10. Confidentiality, Integrity and Assurance are different things and require different methods. Don’t merge them all together into one thing.

And the rest:

1. Digital certificates and PKI (Public Key Infrastructure) are two of the least understood areas of cybersecurity — don’t expect many people to understand them.
2. For public key encryption, you encrypt with Alice’s public key, and she decrypts with her private key.
3. For public key signatures, you sign a hash of the message with your private key, and Alice proves your public key.
4. Your baseline hack is always brute force. Know how many dollars it would cost the NSA to crack something.
5. Machine code can reveal your secrets.
6. A hack of one key should not lead to the loss of all the previous keys.
7. A key should only exist for the time it was meant to exist for.
8. Use session keys wherever possible, and watch out for long-term keys.
9. Your role is typically to protect the user and not reveal things to the NSA.
10. 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.
11. Try and understand the basics of the maths involved — otherwise, you are trusting others.
12. Understand entropy, and know how to calculate it and prove it with experiments.
13. Run entropy calculations before pushing related code to production.
14. Don’t use a method unless it has been peer-reviewed and published.
15. 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.
16. Know why you have chosen X over Y, and be able to defend the reason to others.
17. The maths may be sound, but human is typically the main weakness.
18. Everything will work fine until it doesn’t.
19. Test for out-of-band conditions as much for good conditions.
20. Zero is not your friend in cryptography, so always know what it will do to your system.
21. Don’t just catch exceptions; action them. Do not allow to progress unless everything checks out okay.
22. Log good and bad. Catch good things, along with bad things.
23. Monitor your security logs for exceptions and bad operations.
24. Remove debugging code from your production version.
25. Keep up to date with the latest research.
26. Beware of backdoors in methods and code.
27. 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.
28. 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.
29. If you can use real randomisation and not pseudo-randomness.
30. If you generate pseudo-randomness, take the randomness from several sources.
31. Continually review your code, and get external experts to review it.
32. Don’t push your code in production until you have tested it — fully!
33. Check the code in the libraries you use, and perhaps, don’t use them if there are no open-source repositories.
34. If you can, open source your libraries.
35. Watch out for version updates on your code, and try and lock a given (known) version to your code.
36. Encrypt anything that looks like PII (Personally Identifiable Information) at rest and over the air.
37. Remember that running memory can reveal keys and cryptographic artefacts, so know the risk.
38. Learn a new method every day, and don’t get stuck with the same old crypto!
39. Quantum computers will happen one day and will disrupt our life, so start thinking about the impact they might have.
40. Revealing your private keys is like giving someone the keys to your castle, so know where they are and restrict access to them.
41. Only give access to private keys to those you most trust to use them properly.
42. Air your development environment from your production environment, and don’t let private keys propagate.
43. The best systems use zero trust. No rights to anything unless they can be proven.
44. You will — at times — need to revoke your public keys. Be aware of the processes involved and of the embarrassment it will cause.
45. Educate the board on the importance of good crypto!
46. Encourage your team to undertake academic study, and get them to reserve a few hours a week for independent study of new methods.
47. Read classic research papers, and don’t dismiss methods because they are not currently used.
48. Collaborate with an academic team which has complementary skills to your own team.
49. If you lack theoretical knowledge in your team, get external experts to come in for a chat.
50. Once a private key is destroyed, any data encrypted with it is also likely to be destroyed.
51. Limit the copies of a secret key.
52. If you can, keep your keys in an HSM (Hardware Security Module).
53. Cryptography in the Cloud pushes you to the limits and will often enhance the methods you use.
54. Back up those secret keys, but make sure they are well-wrapped before putting them in a place that others can access.
55. Learn about the garbage collector and how your program deals with data when running.
56. Leave the coding of the maths in papers to experts.
57. Don’t trust auditors to prove the security of your system.
58. Generally, auditors are likely to have little understanding of the methods you will use — get experts to review your methods.
59. Beware of Denial of Service (DoS) on your code — such as continual exception handling.
60. Most systems boil down to one single thing that defines the overall security — know what this is.
61. 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.
62. Watch those CVE updates like a hawk — it can be a race between you and your adversary.
63. On Cloud-based systems, log everything about your keys.
64. In the Cloud, only allow keys to be used for the purpose they should be used for, and don’t use them generally.
65. Limit access to keys for services and roles.
66. Reduce the impact of a stolen or lost secret key.
67. Never encrypt large-scale data infrastructures with the same secret key — try to use envelope encryption.
68. Passwords are dead — replace with cryptographic signing methods.
69. Your enemy can be within. Watch out for key stealing and deletion.
70. Tell your incident response team about the difference between losing encrypted data and non-encrypted data.
71. Scan your network for secret keys placed in locations where they should not be stored.
72. Know what the acronyms mean and not just what they stand for.
73. Know why we use message authentication codes (MACs).
74. 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.
75. Rainbow tables aren’t much of a threat anymore, so make use your use a good salt value.
76. 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.
77. Nonce/salt values should start at 96 bits. Never use anything less.
78. RC4 has been cracked … get over it.
79. Stream ciphers can often be broken — make sure you never reuse your salt value.
80. DES and 3DES are mainly uncracked, but DES only uses a 56-bit key, so never use it
81. Compared with ECC, RSA requires a good deal more processing and has larger key sizes, but it is still great.
82. ECDSA suffers from nonce reuse attacks.
83. 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.
84. 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.
85. Consider writing papers — it is a great way to develop your writing and abstraction skills.
86. Don’t sit back with the status quo — try to continually improve privacy and security.
87. Have a risk register and maintain it. Don’t be shy, and don’t hide things.
88. Have someone to check your code — on a regular basis.
89. Remember Moore’s Law … computing power is increasing every year, so know that something that is safe now might not be in 10 years.
90. 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

A team of developers at Distrust and others has discovered a weakness in the cryptographic methods of creating a random seed for the Libbitcoin Explorer wallet. This is allegedly behind a number of cryptocurrency thefts on 12 July 2023, and on November 2022. The vulnerability has been given the CVE identifier of CVE-2023–39910 and dubbed Milk Sad [here]:

Basically, the wallet uses the bx seed program and which uses a Mersenne Twister [here] for its random generator. Overall it is a secure method when used with a strong seed values. Normally these nonce values are at least 92 bits long, but more typically at least 128 bits. Unfortunately, in this case, it is initialised with 32 bits of system time. A sample run as [here]:

We can see that bx seed is generating a random number and which has 48 hex characters, and thus 24 bytes. This gives us a 192 bits of output, but the nonce is along 32 bits long. We then use ec-new to create a 256-bit private key for secp256k1.

And so the problem is trival … we only use 32 bits of system time to generate the random seed. For anyone who had studied cryptography, you should know that we need at least 72 bits of a random seed to be safe from brute force recovery. Basically, cracking a 32-bit value is fairly easy … if not trivial. For this, the number of possible keys will thus be:

4,294,967,296

whereas normally we need 256 bits of entropy, which is:

115792089237316195423570985008687907853269984665640564039457584007913129639936

Overall, it will take less than a day to brute force a private key, as we only have, on average, we only have to try keys within a 2³² space - this is the key entropy. There are a few ways to setup bx, but once the base configuration is known, it is then easy to brute force the key. Once the private key is discovered, the intruder can then drain the wallet of cryptocurrency — by signing transfers.

The name “Milk Sad” comes from a system time of 0.0 gives a secret of:

milk sad wage cup reward umbrella raven visa give list decorate bulb gold raise twenty fly manual stand float super gentle climb fold park

This is sheep-following-sheep. Someone on the Internet would have shown the bx key generation method and then just followed it. More details of the vulnerability here:

As humans we are driven by risks and threats, and where we are continually weighing-up costs and benefits. A threat is an actual thing that could actually cause harm, loss or damage, whereas a risk is the likelihood of a specific threat happening.

In our lives, too, we expose ourselves through vulnerabilities, and which are our weaknesses and which could be exploited by others. Within Cyber intelligence we must thus need to continually understand our threats and vulnerabilities and weigh up the risks involved. With finite budgets for computer security, and we must thus focus on those things which will bring the most benefit to the organisation. A major challenge is always to carefully define costs and benefits. A CEO might not want to invest in a new firewall if the justification is that it will increase the throughput of traffic. Whereas a justification around the costs of a data breach and an associated loss of brand reputation might be more acceptable for investment.

Threat analysis is a growing field and involves understanding the risks to the business, how likely they are to happen, and their likely cost to the business. Figure 1 shows a plot of the cost of risks against the likelihood. If there are low costs, it is likely to be worth defending against. Risks which are not very likely, and which have a low cost, and also a risk which has a high cost, but is highly likely, are less likely to be defended against. At the extreme, a high risk which has a low likelihood and which has high costs to mitigate against is probably not worth defending against. The probabilities of the risks can be analysed either using previous experience, estimates, or from standard insurance risk tables. Figure 2 outlines an example of this.

Any investment in cybersecurity must often be justified, especially in the benefits that it brings to an organisation. For audit/compliance reasons, a company must often prove that the match the key regulatory requirements within its market place. Regulations such as GDPR, and acts such as Gramm-Leach-Bliley (GLB), Sarbanes-Oxley (SOX), and the Computer Fraud and Abuse, are often a key drivers for investments in cybersecurity, as a failure to comply with these can lead to significant fines or even criminal charges. The GLB Act outlines the mechanisms that financial intuitions can use to share customer data.

And, due to the financial scandals of Enron, WorldCom, and Tyco, SOX was passed in 2002, and which defines the methods used to implement corporate governance and accountability. One driver for cyber intelligence is thus the ability to gather the required information for auditors to review.

As previously defined, there are many other costs that an organisation may face, including the loss of business, brand damage, and a reduction in shareholder confidence. One method of understanding the cost of risk is to determine the single loss expectancy, which is calculated from:

ALE = AV x ARO

and Where ALE is the Annual Loss Expectancy, ARO is the Annualized Rate of Occurrence, and V is the value of the particular asset. For example, if the likelihood of a denial-of-service on a Web-based database is once every three years, and the loss to sales is $100K, the ALE will be:

ALE = $100K x 1/3 = $33K per annum

This formula assumes that there is a total loss for the asset, and for differing levels of risk, an EF (Exposure Factor) can be defined as the percentage of the asset damage. The formula can then be modified as:

ALE = AV x ARO x EF

The major problem in defining risk — and in implementing security policies — is that there is often a lack of communication on security between business analysts and information professionals, as they both tend to look at risk in different ways. Woloch [1] highlights this with:

Get two risk management experts in a room, one financial and the other IT, and they will NOT be able to discuss risk. Each puts risk into a different context … different vocabularies, definitions, metrics, processes and standards.

At the core of Cyber intelligence is a formalisation of the methodology used to understand and quantify risks. One system for this is CORAS (A Framework for Risk Analysis of Security Critical Systems) and which has been developed to understand the risks involved. A key factor of this framework is to develop an ontology (as illustrated in Figure 3) where everyone speaks using the same terms. For example:

A THREAT may exploit a VULNERABILITY of an ASSET in the TARGET OF INTEREST in a certain CONTEXT, or a THREAT may exploit a VULNERABILITY opens for a RISK which contains a LIKELIHOOD of an UNWANTED INCIDENT.

In this way, all of those in an organisation, no matter their role, will use the same terminology in describing threats, risks and vulnerabilities.

For risk management, it is understood that not all threats can be mitigated against, and they will be carefully managed and monitored. Figure 4 shows the methodology used by CORAS in managing risks, and where a risk might be accepted if the cost to mitigate against it is too high. Network sensors can thus then be set up to try and detect potential threats, and to deal with them as they occur. For risk avoidance, systems are set up so that a threat does not actually occur on the network. An example of risk management is where a company might not setup their firewalls to block a denial-of-service (DoS) attack, as it might actually block legitimate users/services, and could thus install network sensors (such as for Intrusion Detection Systems) to detect when a DoS occurs. With risk avoidance, the company might install network devices which make it impossible for a DoS attack to occur.

The importance of clearly defining threats allows us to articulate both the threat itself and also define clearly the entities involved with an incident. Figure 5 shows an example of defining the taxonomy used within a security incident, and where:

A [Threat] is achieved with [Attack Tools] for [Vulnerabilities] with [Results] for given [Objectives].

Within cybersecurity, we see many terms used within military operations, including demilitarized zones (DMZs), defence-in-depth and APT (Advanced Persistent Threat). Another widely used term is the kill chain where military operations would attack a specific target, and then look to destroy it. A defender will then look to break the kill chain and understand how it might be attacked. An example of the kill chain approach is “F2T2EA”, where we Find (a target), Fix (on the location of the target), Track (the movement of the target), Engage (to fix the weapon onto the target), Assess (the damage to the target). A core of this approach is the provision of intelligence around the finding, tracking and assessment of the target.

One of the most used cybersecurity models to understand threats is the kill chain model and was first proposed by Lockheed Martin. Yadav et al [2] define the technical nature of key stages of an attack, including Reconnaissance, Weaponize, Delivery, Exploitation, Installation, and Act on Objective (Figure 6). So let’s say that Eve wants to steal the academic records of a university student (Carol). She might perform a reconnaissance activity and find out that Bob is an academic related to Carol’s programme of study.

Eve might then determine that Bob runs Windows 10 on his computer and will then move to weaponization. For this Eve selects a backdoor trojan which fakes the login process for his university site. Eve does this by scrapping the university login system. Next, she picks a suitable delivery mechanism and decides that a spear phishing method which will trick Bob into logging into the fake Web site. Eve then tries a different phishing email each day and for each attempt, she monitors for any activity of Bob putting in his university login details and his password. Once he is fooled into putting in his username and password, Eve then logs the IP address of his computer and remotely logs into it. She then installs a backdoor program, and which captures his keystrokes. Eve then monitors his activities until she sees him logging into the university results system, and where she can capture his login details for this system, and then she can act on her objective and steal Carol’s results.

The first stages of an attack is likely to involve some form of reconnaissance, and which can either be passive scanning or active scanning. Within active reconnaissance, an attack may use discovery tools to determine servers, networking devices, IP address ranges, and so on. These tools will typically leave a trace on the network, and which could be detected for reconnaissance activities. Typically an organization would have standard signature detection methods to detect the scanning of IP addresses, TCP ports, and in the discovery of networked services. A company could then black-list, or lock down, the IP address which sourced the scan.

With passive scanning, an attacker might use open source information to better understand their target. This increasingly involves Open-Source Intelligence (OSINT) Reconnaissance. Increasingly, too, we all leave traces of our activities across the Internet, and as we do, we leak information that could be useful for an attacker. A spear-phishing attack may thus be targeted against a person who has leaked information about their next-of-kin or on their normal work times. Eve, for example, might know that Carol has a friendship with Trent, and that Carol also uses Pinterest. She then finds out that Carol always starts work at 9am, and that she has been associated with a given IP address. On checking her Twitter account, Eve sees that Carol attended a rock concert the night before. Eve then sends Carol an email just before 9am of:

Hi Carol,

Trent here. Hope you had a great time at the concert. Here are some photos from that I took [here].

— Trent

Eve then sets up a fake Pinterest site, and which asks for Carol’s login details. Carol then enters her password, but it is rejected, and then Eve’s fake Web page forwards Carol to the correct Pinterest site, and she logs in. Everything looks okay, and Carol just thinks that she has entered the wrong password in the first login attempt. But Eve now sees Carol’s username, password and IP address. If Carol uses the same password for many of her accounts, Eve can then move through sites that she is likely to use, and use the Pinterest-sourced password. Thus Eve has used a targeted spear-phishing attack, and where she had determined something about Carol, and then targeted her with something that she thought Carol will be tricked with.

Many criticise the kill chain model in cybersecurity as it does not cover all of the possible attacks, and is limited number in the number of stages. The MITRE ATT&CK(TM) extends these phases into: Reconnaissance, Resource Deployment, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact, and splits these up into techniques used in each phase [3].

Figure 7 outlines that the initial access phase could be achieved through methods such as Drive-by Compromise and Exploit Public-Facing Application, and which can then be used as a knowledge base for the tactics and techniques used. Within each of the techniques, the framework outlines real-life examples, detection methods, and possible mitigations.

In reconnaissance (Figure 8), we can see there are 10 basic techniques (active scanning, gathering victim host information, and so on). These techniques then split into sub-techniques (such as Scanning IP Blocks for Active Scanning).

Each sub-technique then has mitigations and detection methods (Figure 9).

Peter Polis [4] then brought together the approaches of the kill chain model and the MITRE ATT&CK(TM) knowledge base to create the Unified Kill Chain (UKC) model, and which defines 18 unique attack phrases. These are split into stages of an initial foothold and which pivots to network propagation and then with access to an action (Figure 8). The reconnaissance phases involve: Weaponization; Delivery; Social Engineering; Exploitation; Persistence; Defense Evasion and Command & Control (Figure 9); the network discovery phase involves Discovery; Privilege Escalation; Execution; Credential Access; and Lateral Movement, with an action phrase of Collection; Exfiltration; Target Manipulation; and Objectives.

I repeat, at the core of cybersecurity are: risks, costs, benefits and threat models. We need common definitions for our definitions and in defining a common knowledge base. The Unified Kill Chain model goes some way to achieving this.

[1] B. Woloch, “New dynamic threats requires new thinking: moving beyond compliance”,” Computer Law & Security Review, vol. 22, no. 2, pp. 150–156, 2006.

[2] T. Yadav and A. M. Rao, Technical aspects of cyber kill chain,” in International Symposium on Security in Computing and Communication. Springer, 2015, pp. 438–452.

[3] MITRE, Mitre’s attack,” 2019. [Online]. Available: https://attack.mitre.org/. Link.

[4] P. Pols, Unifed kill chain (ukc),” 2019. [On-line]. Available: https://www.csacademy.nl/images/scripties/2018/Paul-Pols — -The-Unied-Kill-Chain.

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).

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.

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.

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.

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).

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].

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).

These methods uses standard cryptographic methods such as symmetric key encryption and hashes. Typically they use AES and SHA3 — and which are quantum robust.

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.

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.

Lessons from the cybersecurity rule book for government:

• Lesson 1: If you have PII (Personally Identifiable Information), you should encrypt it.
• Lesson 2: Lock down access to encrypted data and require multifactor authentication for access.
• Lesson 3: All communications with citizens should be stored in an encrypted form.
• Lesson 4: The transmission of data between systems should be encrypted and authenticated.
• Lesson 5: All accesses to data should be logged, and restrict queries based on a policy.
• Lesson 6: Alerts on data access should be analysed — either automated or by a human.
• Lesson 7: Provide a strong identity governance framework and do not automatically assign rights.
• Lesson 8: Apply human checkpoints and tripwires on access control to sensitive documents.
• Lesson 9: Provide physical and virtual segmentation of data sources from access control.
• Lesson 10: Implement a dual-homed approach to the access to data — and where access to sensitive data sources is isolated from general areas through white-list firewalls.
• Lesson 11: Put a strongly authenticated API in-front of data and limit queries based on role.
• Lesson 12: Don’t use role-based security, and migrate to attribute-based systems based on time, location, hardware/software token access, and so on.
• Lesson 13: Don’t use a single key to encrypt all your data … use envelope encryption and where every data record and message can have a random encryption key.
• Lesson 14: Use a Hardware Security Module (HSM) to store your sensitive keys and restrict access to them.
• Lesson 15: Audit regularly and review access logs. Get external reviews from trusted entities.
• Lesson 16: Warn staff of tripwire approaches, and define HR procedures for breaches, eg three strikes, and you’re out!
• Lesson 17: Remove passwords wherever possible, and replace with multifactor authentication that includes tokens, time and location.
• Lesson 18: Implement file scanning processes and which aim to discover key identifiers of PII (including on work-based laptops).
• Lesson 19: Zero trust levels on access to citizen data.
• Lesson 20: Run only one service on one server, and minimise the surface area.

It’s as simple as that. In fact, governments could learn a great deal about coping with cybersecurity in the Cloud.

But now the Electoral Commission in the UK has revealed that information on around 40 million citizens was exposed from August 2021 to October 2022. This includes everyone who was eligible to vote between 2014 and 2022 and includes their names and addresses, along with information sent to the commission in the form for email and web forms.

https://www.bbc.co.uk/news/uk-politics-66441010

Very few details of the “complex cyber-attack” are given, but I bet, in the end, that it was the good old standard method of gaining a foothold in a system.

The risk of insiders leaking information is significant in this type of breach, and the best firewalls in the world will not protect us from insider threats. The banks have realised that they now need 24x7 SOC support, and this would be the case in government. While the information leaked is possibly not that serious, there is a basic trust issue here, and where data was exposed for over a year, and it was not detected.

In response, the Commission has said that it would lock out hostile actors, which doesn’t sound like a coherent plan to protect the data. I would hope encryption, and a zero-trust approach will also be used. Governments need to lead the way and not be stuck using the paper-based approaches of the 20th Century.

Blog: https://medium.com/asecuritysite-when-bob-met-alice/one-of-the-greatest-protocols-and-one-of-the-greatest-weaknesses-of-the-internet-meet-the-d8201a1e6e80

So the Internet isn’t the large-scale distributed network that DARPA tried to create, and which could withstand a nuclear strike on any part of it. At its core is a centralised infrastructure of routing devices and of centralised Internet services. The protocols its uses are basically just the ones that were drafted when we connected to mainframe computers from dumb terminals. Overall, though, a single glitch in its core infrastructure can bring the whole thing crashing to the floor. And then if you can’t get connected to the network, you often will struggle to fix it. A bit like trying to fix your car, when you have locked yourself out, and don’t have the key to get in.

As BGP still provides a good part of the core of the Internet, any problems with it can cause large scale outages. Recently Facebook took themselves off the Internet due to a BGP configuration errors, and there have been multiple times when Internet traffic has been “tricked” to take routes through countries which do not have a good track record for privacy.

BGP does the core of routing on the Internet, works by defining autonomous systems (AS). The ASs are identified with an ASN (Autonomous System Number) and keep routing tables which allows the ASs to pass data packets between themselves, and thus route between them. Thus the Facebook AS can advertise to other AS’s that it exists and that packets can be routed to them. When the Facebook outage happened, the Facebook AS failed to advertise its presence. Each AS then defines the network ranges that they can reach. Facebook’s ASN is AS32935 and covers around 270,000 IP address ranges [here].

The two main interdomain routing protocols in recent history are EGP (Exterior Gateway Protocol) and BGP (Border Gateway Protocol). EGP suffers from several limitations, and its principal one is that it treats the Internet as a tree-like structure, as illustrated in Figure 1. This assumes that the structure of the Internet is made up of parents and children, with a single backbone. A more typical topology for the Internet is illustrated in Figure 2. BGP is now one of the most widely accepted exterior routing protocol, and has largely replaced EGP.

BGP is an improvement on EGP (the fourth version of BGP is known as BGP-4), and is defined in RFC1772. Unfortunately it is more complex than EGP, but not as complex as OSPF. BGP assumes that the Internet is made up of an arbitrarily interconnected set of nodes. It then assumes the Internet connects to a number of AANs (autonomously attached networks), as illustrated in Figure 3, which create boundaries around organizations, Internet service providers, and so on. It then assumes that, once they are in the AAN, the packets will be properly routed.

Most routing algorithms try to find the quickest way through the network, whereas BGP tries to find any path through the network. Thus, the main goal is reachability instead of the number of hops to the destination. So finding a path which is nearly optimal is a good achievement. The AAN administrator selects at least one node to be a BGP speaker and also one or more border gateways. These gateways simply route the packet into and out of the AAN. The border gateways are the routers through which packets reach the AAN.

The speaker on the AAN broadcasts its reachability information to all the networks within its AAN. This information states only whether a destination AAN can be reached; it does not describe any other metrics. An important point is that BGP is not a distance-vector or link state protocol because it transmits complete routing information instead of partial information.

The BGP update packet also contains information on routes which cannot be reached (withdrawn routes), and the content of the BGP-4 update packet is:

• Unfeasible routes length (2 bytes).
• Withdrawn routes (variable length).
• Total path attribute length (2 bytes).
• Path attributes (variable length).
• Network layer reachability information (variable length). This can contain extra information, such as ‘use AAN 1 in preference to AAN 2’.

Routers within AS’s share similar routing policies, and thus operate as a single administrative unit. All the routers outside the AS treat the AS as a single unit. The AS identification number is assigned by the Internet Assigned Numbers Authority (IANA) in the range of 1 to 65,535, where 64,512 to 65,535 are reserved for private use. The private numbers are only used within private domain, and must be translated to registered numbers when leaving the domain.

BGP uses TCP segments on port 179 to send routing information (whereas RIP uses port 520). BGP overcomes routing loops by constructing a graph of autonomous systems, based on the information provided by exchanging information between neighbors. It can thus build up a wider picture of the entire interconnected ASs. A keep-alive message is send between neighbours, which allows the graph to be kept up-to-date.

ASs which have only one exit point are defined as single-homed systems, and are often referred to as stub networks. These stubs can use a default route to handle all the network traffic destined for non-local networks.

There are three methods that an AS can use so that the outside world can learn the addresses within the AS:

• Static configuration. For this, an Internet access provider could list the customer’s networks as static entries within its own router. These would then be advertised to other routers connected to its Internet core. This approach could also be used with a CIDR approach which aggregates the routes.
• Use an Interior Gateway Protocol (IGP) on the link. For this, an Internet access provider could run a IGP on the single connection, this can then be used to advertise the connected networks. This method allows for a more dynamic approach, than static configuration. A typical IGP is OSPF.
• Use an Exterior Gateway Protocol (EGP) on the link. An EGP can be used to advertise the networks. If the connected AS does not have a registered AS, the Internet access provider can assign it from a private pool of AS numbers (64,512 to 65,535), and then strip off the numbers when advertising the AS to the core of the Internet.

A multi-homed system has more than one exit point from the AS. As it has more than one exit point, it could support the routing of data across the exit points. A system which does not support the routing of traffic through the AS is named a non-transit AS. Non-transit ASs thus will only advertise its own routes to the Internet access providers, as it does not want any routing through it. One Internet provider could force traffic through the AS if it knows that routing through the AS is possible. To overcome this, the AS would setup filtering to stop any of this routed traffic.

Multi-homed transit systems have more than one connection to an Internet access provider, and also allow traffic to be routed through it. It will route this traffic by running BGP internally so that multiple border routers in the same AS can share BGP information. Along with this, routers can forward BGP information from one border router to another. BGP running inside the AS is named Internet BGP (IBGP), while it is known as External BGP (EBGP) if it is running outside AS’s. The routers which define the boundary between the AS and the Internet access provider is known as border routers, while routers running internal BGP are known as transit routers.

Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol (exterior routing protocol), which builds on EGP. The main function of a BGP-based system is to communicate network reachability information with other BGP systems. Initially two systems exchange messages to open and confirm the connection parameters, and then transmit the entire BGP routing table. After this, incremental updates are sent as the routing tables change.

Each message has a fixed-size header and may or may not be followed a data portion. The fields are:

• Marker. Contains a value that the receiver of the message can predict. It can be used to detect a loss of synchronization between a pair of BGP peers, and to authenticate incoming BGP messages. 16 bytes.
• Length. Indicates the total length, in bytes, of the message, including the header. It must always be greater than 18 and no greater than 4096. 2 bytes.
• Type. Indicates the type of message, such as 1 — OPEN, 2 — UPDATE, 3 — NOTIFICATION and 4 — KEEPALIVE.

The OPEN message is the first message sent after a connection has been made. A KEEPALIVE message is sent back confirming the OPEN message. After this the UPDATE, KEEPALIVE, and NOTIFICATION messages can be exchanged.

Figure 4 shows the extra information added to the fixed-size BGP header. It has the following fields:

• Version. Indicates the protocol version number of the message. Typical values are 2, 3 or 4. 1 byte.
• My Autonomous System. Identifies the sender’s Autonomous System number. 2 bytes.
• Hold Time. Indicates the maximum number of seconds that can elapse between the receipt of successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages. 2 bytes.
• Authentication Code. Indicates the authentication mechanism being used. This should define the form and meaning of the Authentication Data and the algorithm for computing values of Marker fields.
• Authentication Data. The form and meaning of this field is a variable-length field which depends on the Authentication Code.

BGP configuration commands are similar to those used for RIP (Routing Internet Protocol). To configure the router to support BGP the following commands is used:

With IGP’s, such as RIP, the network command defined the networks on which routing table update are sent. For BGP a different approach is used to define the relationship between networks. This is [here]:

where the network command defines where to advertise the locally learnt networks. These networks could have been learnt from other protocols, such as RIP. An optional mask can be used with the network command to specify individual subnets. With the BGP protocol neiphbors must establish a relationship, for this the following is used:

which defines the IP address of a connected BGP-based router, along with its AS number.

At its core, the Internet is not a decentralised infrastructure. It is fragile and open to human error and adversarial attacks. Too much of our time is spent on making our services work and very little on making them robust. We need to spend more time looking at scenarios and how to mitigate them. Previously it was Facebook taking themselves offline, the next time it could be a nation-state bring down a whole country … and that it is likely to have a devastating effect.

Now … I have setup more Cisco challenges for BGP for you, so go and learn more about BGP configuration here:

https://asecuritysite.com/cisco/bgp

Blog: https://medium.com/asecuritysite-when-bob-met-alice/my-five-favouriate-least-favouriate-computer-programming-languages-dd8a560c27a

I love programming and think that every child should be taught it at school at an early age — and, for me, coding is for everyone. As an artist uses paint and a canvas, programming allows me to practice my art — cryptography. I can then re-enforce my learning of theoretical methods into practice — and where the learning comes alive.

It also allows me to script things that would be extremely time-consuming. With the Cloud, for example, I can open and close ports on a firewall with a simple Python script — and which allows me to avoid logging into a system and using a silly GUI (Graphical User Interface, aka browser) to perform a simple operation.

Overall, I have taught programming in the past, but I have no desire to teach it as a subject on its own. Personally, I would rather teach cryptography or cloud computing and then show how code can be used to implement things practically. And, so, here are my favouriate programming languages and least favouriate ones.

My Web site (https://asecuritysite.com) has a range of programming languages. Sometimes I pick the language because it is easiest to implement a given method, but other times I might only be able to find a certain method within a given implementation. And, so, you will find lots of Python, Golang, Rust, and JavaScript, but not so much for Java. You will not find so much on C#, but that is the core language that I use to build the Web site, so it’s still one of my favouriate languages.

I know many people will disagree with me, but my five favouriate programming languages in order of how much I like them:

1. Golang. It just always works for me, and no real problems in finding libraries. C is my natural programming language, and I just find Golang so intuitive in its structure and the methods it uses to compile programs. I also love a command-line approach to compiling programs, and which can provide an alternative to complex GUIs. For prototyping, it is great and produces executables which can work across different platforms. It is, though, very much a back-end programming language and will produce fairly dependable code. I particularly like it, as it loads its libraries onto my machine with a Git pull, and it gives me some satisfaction that I am pulling a fresh version of a library.
2. C#/ASP.NET. It has (mostly) everything you need, and you can build systems in so many ways. With ASP.NET, we have a pure (M)odel, (V)iew and (C)ontroller approach and can properly code for the Web. I vividly remember changing from Microsoft Windows coding to ASP.NET, and it opened up a whole new world of Web coding. In less than a day, I covered 100s of thousands of C# code into an ASP.NET environment.
3. Python. The syntax is a bit horrible and can break easily, but it’s powerful and portable. It misses many things that I would think are natural, such as a proper for() loop and repeat … until(), but it is the fall-back language that many systems will use. As it is interpreted, it is fairly slow, and can lack a bit of robustness, but for its scope, its everywhere and can turn its hand from microcontrollers to cloud scripting.
4. Rust. If we were to start programming all over again, we would use Rust and not C. We fell into a large trap in using C programs with its usage of memory pointers, and pointers to pointers. Rust teaches you good programming and how not to rely on the garbage collector to get rid of your variables that you do not use anymore.
5. PowerShell. If you know C#, then you know PowerShell. While many think it is just tied to Microsoft Windows, it can now run on most operating systems. Basically, it is the command shell programming language that Microsoft Windows has always needed. But, watch-out, those cybercriminals can use it for bad purposes. It is a saint and a sinner.

And my least favouriate:

1. Java. So, sorry. I know it’s one of the top computer languages around and extremely powerful, but Java has just passed me by. I think it is all the hassle of building class files and defining class paths, but it just doesn’t work for me.
2. JavaScript. Well, it has very little to do with Java, but I still don’t like it. It is, though, extremely powerful and one of the few computer languages that can exist in the browser but also in the back (with Node.js). Many years ago, I predicted that JavaScript would die off as it was a horrible language and basically fossilised its version. But, I was wrong, and while Flash and all the other plug-ins for browsers have fallen, JavaScript has rebuilt the Web, and where code now runs in the browser rather than calling back to a server. And its version control is really terrible but powerful. With npm — its package manager — we have a quick way to install libraries, but also a convenient way for the delivery of back door trojans. And, for remembering the syntax? I have very little clue about that and often have to Google for the basics of a Writeline statement.
3. PHP/ASP. These are terrible and allow for the integration of mark-up code that can be rendered when delivered. Both PHP and ASP are bad, and lack any real debugging environment and proper code integration. Luckily, Microsoft saw the errors in the ways and updated ASP with the ASP.NET and allowed the integration of the Razor front-end code and C#/.NET as a backend and middleware. It provided a proper MVC (Model, View and Controller) solution. And, for PHP, I would never even consider it for a minute as a solution for anything. To me, I can often spot an old site with its use of PHP or ASP. There was a time when it opened up the Web for customisation, but it passed quickly.
4. SQL. Some would say it isn’t a programming language, but it is. It is the oldest programming language, and it is showing its age. I appreciate it is powerful and simple to use, but this power opens up so many security problems. And, too, the days are SQL are numbered with the rise of JSON objects and NoSQL databases.
5. C++. I grew up programming in C, and the languages I like most use a C-style syntax. But, C++ came along, and I just missed it completely. I appreciate that the world became object-oriented, but I just have never liked the basic syntax of C++, and so I avoid coding with it.

Oh, and I know many will disagree with me here, but Perl is a nightmare to debug and understand. Perhaps these are one of the reasons it is so powerful — as it can obfuscate the operation of the code.

And, there you go. Golang and Python for prototyping, PowerShell for pushing the operating system, C# for infrastructure building, and Rust for production code.

So learn some Golang:

https://asecuritysite.com/golang

and some Rust:

https://asecuritysite.com/rust

Which are your five favouriate and least favouriate programming languages?

Blog: https://medium.com/asecuritysite-when-bob-met-alice/the-wacky-world-of-javascript-and-npm-protecting-the-software-supply-chain-not-25662cfd1b66

JavaScript is the best and the worst of computer programming. It is able to exist in both the front end (the browser) and in the back end (with Node.js). It basically saved the Web as we moved from static Web pages to delivering dynamic content. With JavaScript, we could then enable direct interaction with the user but also capture and process data when required. It was a stroke of genius that allowed the same code in a Web page to be used on the back end (Node.js).

But, it is sloppy language and rather unpredictable. Many love its methods, as a simple npm (Node Package Manager) can install the required software and libraries without any fuss:

But this simplicity can lead to problems. And, for Python, the pip command makes it easy to install libraries:

But these can lead to back-door trojans if an adversary places a back door in one of the associated libraries. Along with this, we can get typosquatting, and where a developer might type:

and download a malicious library. For this, an adversary needs to get their code onto one of the trusted repositories for JavaScript and Python.

The SolarWinds attack should act as a lesson in the importance of protecting the software supply chain, as backdoors can be applied to trusted software. For this, an adversary could either break into a trusted software system and add a backdoor in the software and then, with a compromised private key, sign the update as being valid. Also, an adversary could add a backdoor to open-source software that might go unnoticed when built.

And, so, software languages tend to vary greatly in their control of libraries. With Rust, for example, we have Cargo, and which is a strongly versioned package manager. This will build a Rust program with a strict linkage of libraries to a given version — rather than taking the up-to-date version. All of the code is compiled strictly against versions of the binding to the code. Golang is less tightly defined and uses a git pull of the current version and stores it locally on a machine. A new git pull is required to update the version.

Now, it has been reported by Phylum that a new stealthy malware is spreading within npm [here]:

With this, they reported on 31 July 2023 that there were suspicious activities on npm, and that 10 “test” packages were published. The research team found that they were part of a targeted malware attack — and which focused on exfiltrating source code and confidential information. This involved several iterations of updates before the final malware was constructed, as it shows that adversaries can focus on small incremental updates rather than showing the complete code at a single instance. This can allow malicious code to go undetected — and where the increments look like sensible updates.

Overall, the packages had sensible-looking names —and an example of “npm typosquatting”. A recent example included the creation of a package named “aabquerys”, which is similar to the valid package of “abquery” [here]. With is it was found that it installs a legitimate EXE (wsc_proxy.exe) and which is digitally signed with a valid certificate but where is can be used as a side loader for malware. With a side loader, a valid and trusted program is run, but where it loads malicious code. In the malware version, a malicious file named wsc.dll is placed in the same place as wsc_proxy.exe, and which loads wsc.dll when invoked (Figure 1).

And pip, too, does not have a great track record for protecting against malicious packages. A recent report from ReversingLabs involves the integration of the Python Package Index (PyPI) repository and includes the identification of 24 malicious packages that link to three popular open-source tools: vConnector, eth-tester and databases [here]. The target for these seems to be for cryptocurrency-focused developers.

Watch the versions of your code, as you could be a trojan for others. A backdoor compiler, for example, is one of the most difficult threats to detect, and it can infect a whole lot of systems that you may be responsible for.

Blog post: https://medium.com/asecuritysite-when-bob-met-alice/only-51-have-been-found-heres-mersenne-primes-4c296a3d8091

And, so what’s the next number in the sequence 3, 7, 31, and 127? Well, it’s 8,191, and I will explain why in a little minute.

If you need to test with prime numbers — such as with public key encryption — how do you remember some large ones that you can test with? Well, one of the easiest ways is to remember the Mersenne prime numbers.

Mersenne prime numbers were first defined by Marin Mersenne and who was a 17th Century French Minim friar. His main contribution included his investigations of prime numbers, along with being seen as the father of acoustics. A Mersenne prime is defined as a prime number that is one less than a power of two. The general form is M_n=2^n−1 where n is an integer. The discovery of 2¹¹²¹³-1 was even given its own postmark:

The largest found is 2⁸²⁵⁸⁹⁹³³-1, and is the 51st Mersenne prime to be ever found). Since 1997, the Great Internet Mersenne Prime Search (GIMPS) distributed system has been used to find new Mersenne primes.

From Wikipedia, here are the first 20:

The Mersenne sequence becomes:

Some code to discover these is [here]:

and a sample run [here]:

We can see that 2⁶⁰⁷-1 is 531137992816767098689588206552468627329593117727031923199444138200403559860852242739162502265229285668889329486246501015346579337652707239409519978766587351943831270835393219031728127.

The core of the security you are using to access this page is probably provided with Elliptic Curve Cryptography (ECC), and where a session key is created through ECDH (Elliptic Curve Diffie Hellman). While there are a number of curves we can use, such as NIST P-256, Curve 25519 (as used in Tor) and Secp256k1 (as used with Bitcoin), there are some doubts about their security and their performance. And so Microsoft Research has produced the FourQ curve and which has 128-bit security. It is open source and runs efficiently on a number of platforms. At its core is the usage of the Mersenne prime of 2¹²⁷-1 [here]:

In tests, the Microsoft team showed that FourQ was four or five times faster than the NIST P-256 curve, and two or three times faster than Curve 25519. As so we turn to the wonderful Cloudflare, and their Circl library. Within this, Cloudflare has implemented FourQ, and is [here]:

With this, Alice produces her private key (a), and Bob produces his private key (b). We select a point on the elliptic curve (G), and Alice passes aG to Bob, and Bob passes bG to Alice. The shared key is then abG. A sample run is [here]:

And in the end Bob and Alice have the same shared key, and which they could use for a tunnel.

Another application of Mersenne primes is in the implementation of a random number generation and is known as the Mersenne twist. A typical exponent value used is 19,937 (2²¹⁹⁹³⁷-1). Overall, PRNGs are deterministic and periodic, but the core strength of the Twister method is the pseudo sequence is unlikely to repeat with 2¹⁹⁹³⁷-1 random numbers:

Overall the method uses sequential states, and where it should not be reasonably possible to know the next state from the current state. But some researchers have shown that “sparse” states can exist, and where there are very few ones or very few zeros, the next state will also be sparse.

The method has been criticized for using up so many bits (19,937) for the states, and that for security a state value of 256 bits would still be enough, but have a strong effect on the overall performance of the method. A pseudo sequence repeating in 2²⁵⁶ can still be seen as being secure.

If you want to try this, click [here].

The Lucas–Lehmer test (LLT) is used to test for the primality of Mersenne numbers. It was initially created Edouard Lucas in and then enhanced by Derrick Hentry Lehmer:

For this test, we initially define u_0=0 and we calculate:

If u_{s−2}=0 then it is a prime number. Here are some tests for Mersenne Primes:

• 2³−1 Try.
• 2⁵5−1 Try.
• 2⁷−1 Try.
• 2¹⁰⁷−1 Try.

The following is the code [here]:

And a sample run for 2¹⁹-1 [here]:

Great Internet Mersenne Prime Search (GIMPS) distributed system continues to try and discover the next Mersenne prime [here]. In April 2021, it stopped using the Lucas-Lehmer, and moved on to the Fermat PRobable Prime (PRP) Test. This uses:

a^{p-1} (mod p) = 1

and where p is a prime number.

If you want to discover more about the wonderful world of prime numbers, try here:

https://asecuritysite.com/primes

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:

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://medium.com/asecuritysite-when-bob-met-alice/lesson-1-in-secure-programming-dont-reuse-your-ivs-5666ddfa9a1c

I wrote up an article on a recent Samsung vulnerability [here], and one comment said … “it’s an old bug, reuse of IV (Initialisation Vectors) seem a very basic problem”. On the face of it, the comment perhaps doesn’t go into enough detail, so I’ll try and explain the “bug” and hopefully show that it is shockingly bad coding … almost negligent in terms of protection, and could even be seen as an intentional backdoor.

And for a “very basic problem”, it should perhaps be “extremely bad coding”, and this “bug” should never, ever be seen within trusted environments. It shows an almost complete lack of knowledge in how cryptography works, with a novice vulnerability. The paper is here [1]:

In fact, it’s like WEP all over again, and where the WEP Wifi method had a small IV (Initialisation Vector), and when it rolled out, it was possible to just XOR cipher streams, and discover the plaintext. The asleep program could crack any Cisco access point in less than a day. Luckily we now use WPA-2, and which does not have the reuse of the IV.

I hope to show that we should be worried if code such as this ever gets near a user’s device. In fact, if there was ever a back door in a mobile phone, it could be this one.

If you want to read about the “bug”, try here:

Now, I will explain how bad this “bug” is. If you are into cybersecurity, you should hopefully know that AES GCM is a stream cipher. With this, we take a secret key value and a salt value (an IV — Initialisation Vector) and generate a pseudo infinite keystream. Our plaintext is then simply XOR-ed with the keystream to produce our ciphertext:

The salt value should then always be random, as a fixed salt value will always produce the same keystream for the same plaintext, and where we can reveal the keystream by XOR-ing cipher streams, and eventually revealing the plaintext. In the case of the key wrapping, the plaintext is an encryption key, and thus the encryption key used by the TEE will be revealed.

If we reuse IVs, Eve will be able to XOR cipher streams together and reveal the keystream (K). From there she can decrypt every cipher stream, but simply XOR-ing the cipher stream with K.

AES GCM (Galois Counter Mode) is a stream cipher mode for AES. It is based on the CTR mode but converts to a stream cipher. This provides low latency in the encryption/decryption process and is fast to process. Along with this, it integrates AEAD mode for authentication. But as GCM is a stream cipher mode, it is open to a reuse IV attack. With this, the IV (Initialization Vector) of the cipher is the same for two cipher messages. We can then XOR to the two cipher streams together to reveal the cipher stream key (K). We can then reveal the plaintext by XOR-ing any cipher stream with K.

So, let’s try some code to do this. In this case, I will use Golang to show the basic principles of the method. I will use a static key in this case (as this would not change within the TEE) of “0123456789ABCDEF” (16 bytes — 128-bit key), and a static nonce of “0123456789AB” (12 bytes — 96 bits) [here]:

When we run with “hello” and “Hello” we get [here]:

If we try “hello” and “Cello”, we can see that there’s a variation in the first byte of the cipher stream:

The “bug” allowed a user program to request their own IV, which meant that a cracker would continually request the same IV, and then break the cipher, and reveal the encryption key used. This is because the TEE (Trusted Execution Environment) uses key wrapping to encrypt the encryption key with AES GCM, so a cracker can request these wrapped keys, but with their own IV. This then reveals the key that the TEE is using. This is extremely bad coding!

This is extremely bad coding, and I would not expect this level of implementation from a new graduate. If a development team creating code within a TEE doesn’t understand a reuse IV attack, they need to go on a secure coding training course before they ever touch any more trusted code. If this was an intentional backdoor, that’s a whole other story. I hope, it was just a bug, but we really need to improve our knowledge in the creation of TEEs, as these also run within Cloud-based systems.

[1] Shakevsky, A., Ronen, E., & Wool, A. (2022). Trust Dies in Darkness: Shedding Light on Samsung’s TrustZone Keymaster Design. Cryptology ePrint Archive.

Blog: https://medium.com/asecuritysite-when-bob-met-alice/the-art-of-the-backdoor-e39f001ea8b9

Do you ever worry that your locksmith may take a copy of your key when they fit a new lock? Or that your locksmith has defined a lock which they know they have a skeleton key for? Or that your locksmith modifies the lock so that they can compromise it?

And so we trust those that create locks to design them so that they cannot be broken easily, and that lock standard agencies around the world to set standards that promote good lock design, and, most of all, that locksmiths can be trusted to fit them without compromising them (and in giving us good advice).

Well, let’s look at software backdoors. Overall it’s not an easy thing to put in a backdoor in a piece of software. Well, let me re-phrase that … “it is not an easy thing to put in a backdoor in a piece of software and for it not to be seen”.

Computer security is a serious business, but you must smile a little when you see the lengths that some intruders will go to in order to compromise systems. Organisations such as the NSA have long been accused of applying backdoors into cryptography software, but the recent Apple login hack shows that there are lots of opportunities for others to get in on the act. The addition of a backdoor in the Apple compiler showcased the opportunity for large-scale compromises.

Overall there are a number of ways that a backdoor can be added to a piece of software:

• Escrow. In encrypted communications, one method is to keep of copy of the encryption key that could be used at some time in the future. Details [here].
• Defining a standard that you know you can crack. The NSA and law enforcement agencies around the world have been accused of helping to define a standard and setting various parameters, and they know they have the methods to crack them.
• Source code addition backdoor. This is the typical way that an intruder would add a backdoor, and where the additional code is added which will perform a task that allows the source code writer back into the system. Normally the code is added by the writer, but then an intruder finds out the backdoor and can exploit it.
• Injected code backdoor. With these, packages such as Metasploit insert some additional code into the application, which allows it to work the same, but creates a backdoor connection. Normally this is a call-out method, where the program calls out to the malware writer.
• Compiler backdoor. This is the best method for going undetected, and where the compiler, itself, adds the additional code to every program which uses the compiler. In terms of a mass exploit, the compiler backdoor will have the greatest scope as it will exploit a wide range of applications. The executable will also be signed to verify that it is a valid application.
• Vulnerability and XSS exploit. This involves compromising a system in order to create a backdoor, typically injecting code into a running application which causes the system to open up a backdoor connection.

The open-up of a network connection will obviously be detected on the system, but code writers have implemented a number of smart ways to cover this up, including passing secret passphrases for passwords, or with port knocking, where network packets are sent to a well-known open port, which then causes another port to open.

A key focus for law enforcement is the cracking of cryptography, especially for tunnels and VPN connections. Devices created by Juniper were found to have a flaw which allows agencies to decrypt VPNs traffic. The company may have also used Dual EC (Elliptic Curve) DRBG (Deterministic Random Bit Generator) for generating the random numbers required to create VPN tunnels. This method, which was promoted by the NSA, has a known weakness and can be cracked.

The possible backdoor in Dual EC DRBG has been known about since 2004, and the team who worked on it had the chance to plug the gap but failed too. It thus allows law enforcement agencies to crack SSL/TLS encrypted traffic which used the method for random number generation. It was thus assumed that no one would use the method, but, in Juniper’s case, it has been found in some of their devices.

In 2013, Edward Snowden showed NSA memos which indicated that the NSA had been the sole editor of the standard, whereas NIST responded that it did not deliberately weaken any cryptography standard. The following year, NIST recommended that companies stop using it, and withdrew it from its draft guidance on random number generation. In 2013, also, OpenSSL was found to be implementing the method, which allowed TLS/SSL connections to be decrypted.

The back door in the standard for Elliptic Curve method for Dual_EC_DRBY caused a great deal of suspicion on the definition of NIST’s P curve standards, and that they had selected them so they could have an advantage in breaking the public keys. Most of the industry has moved away from the P standards (such as P-256) and towards Curve25519 (which is shown in the graphic on the right-hand side and which was created by Daniel J Bernstein), and now used by Tor, Signal, What’s App, Facebook, OpenSSH, and many other standards. In 2013, Bruce Scheiner stated that he didn’t trust the values selected:

I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry

I have plotted some of the standard Elliptic Curve parameters [here].

It has long been the case where code writers have added additional code which allows them back into the code whenever required. They will often add debug functions which can be remotely enabled, but where they forget to switch-off. This backdoor method works well until the source code is read, and the additional code is revealed. With the rise of Git hub repositories, it can become obvious as to when the backdoor has been added. The following outlines a few backdoors:

A classic backdoor was added to an FTP server (vsftp), which has an intentional backdoor within the version running on it. The back door is exploited with the username ending with:

“:)”

and then the server listens on port 6200 and awaits a connection:

The UnrealRCD IRC daemon runs on port 6667. The version on Metasploitable has a backdoor where the user sends “AB”, and then follows it with a system command on a listening port (see demo above).

Cryptography cracking is often one of the most challenging areas for investigators to crack, so there have been many allegations of companies tampering with source code in order to create backdoors. While these are not necessarily network connections, the software is modified in a way which changes the functionality of the encryption function.

One company — Crypto AG, a Swiss cryptography company who make encryption machines — has been accused of modifying their software in collusion with intelligence agencies from Germany (BND), the UK (GCHQ) and US (NSA). This was highlighted, in 1986, when Ronald Regan announced that the US had intercepted encrypted diplomatic communications between Tripoli and the Libyan embassy in East Berlin, related to a bombing in Berlin. In 1992, the Iranian government even arrested Hans Buehler, a salesman for the company, but was released in 1993 without revealing any flaws in the machines (and after $1 million bail money was paid).

Crypto AG soon after dismissed Hans and requested he pay back the $1m. Since then Der Spiegel has interviewed former employees and concluded that the machine was indeed rigged. Even after several other investigations, there is still no conclusive proof of the rigging, but some suspect that the relationship with defence agencies goes back to 1954.

Juniper recently announced that there were two backdoors on their devices, and which allowed intruders to gain administrator access and also decrypt the encrypted content. It was the kind of shock that has not been seen since the asleep script was released, and which could crack most Cisco Wi-fi access points which used the LEAP authentication method.

With backdoors in cryptography being a hot topic, Juniper revealed that it had traced “unauthorized” code within its ScreenOS operating system on some of its firewalls, and which allowed an intruder to take complete control of Juniper’s NetScreen firewalls using a hard-wired password. This would allow them to decrypt all the encrypted traffic for VPN connections. There is a patch for this, but intruders can now determine the required password — which has been hard-wired into the code — by examining the ARM code used in the backdoor:

The strange thing is that the password is “

I often get asked about what makes a successful university spin-out, so here are my observation for any budding academic team looking to spin out:

1. You need a solid academic base. A PhD programme is often an excellent base for a spin-out, as it involves three or more years of extensive study into every aspect of a given field. This involves both a macro and micro viewpoint of a problem, and it develops the skills that support the articulation of new knowledge and new discoveries. A great team, too, often has a foundation of both theory and practice.
2. You need vision. Any company can innovate but fail to take things forward. A great team needs a visionary leader and who knows how to take something to the place which achieves this vision. They are a creator of a seed that is likely to sustain the company into its future.
3. Build a team, focus on quality and keep them. I know it sounds obvious, but it’s not easy to build a team in academia. There are too many barriers and academic structures that get in the way of team building. Try and create a team with complementary skills, and don’t just build with a single focus on one skill. You need testers, coders, cloud scalers, documenters, presenters, and many other things. Try to always focus on the quality of your work and not quantity. Quality gets recognised, but quantity often does not. Anyone can produce a 100 research papers, but it takes a great team to produce a single groundbreaking paper.
4. Get the right leader for the right stage. There are different types of leaders. Those who people respect for their technical expertise, those who understand how to make their offering to the market, and others who can scale a company. Get the right leader for the right stage — as they are often different people. Without a visionary, you will not need the next two leaders.
5. Protect your IP. I know many dislike patents, but it’s a dog-eat-dog world of innovation, and if you fail to protect your IP, others will come along and “borrow” from it or even “steal” it. Get a patent, if possible — not to attack others, but to defend yourself. The last thing you want is to licence your own invention from others.
6. Abstract your ideas. While words are great, pictures and abstractions are so much better. Draw your ideas and concepts in a way that engages others.
7. Research papers can be good. The importance of having peer review for any contribution to knowledge cannot be underlined enough, but, know that you have some IP protection in place and that you are further along the route than others in the development of your innovation. If your company wants to be a leader in its field, it needs to show that it has a strong scientific and technical base. And articulating complex thoughts in a research paper is a great way of showing that you have a core understanding of a field.
8. Have a log book. I know this sounds trivial, but I have seen the difficult side of managing IP — when something becomes successful. It does no good in the future to say that you invented something when you have no real evidence. So, keep a log book and write down your thoughts as you develop your research, and get it signed by a trusted person (and with a date). I am still a fan of hardback log books and love it when a PhD student takes one along to meetings and jots down ideas.
9. You need industry. A great invention will go nowhere without it being built at a production levels, and which matches to problems in the market. As early on, try to get industry involved, and focus the work.
10. Build a team with theory and practice. Do not have one without the other. A great research team has the knowledge to ground the work in academic practice, but it needs practical skills to implement it.
11. The leader is not the boss. The leader is not a role. The leader is whoever is sustaining the work.
12. Research grants are a vehicle to sustain your vision. Unfortunately, many academics see research grants as isolated projects which must be implemented and delivered. They are routes to career advancement, and where they can tot-up their total grant income and display it as a KPI. But, are also stepping stones to your true innovation — each grant sustains the work and the team but takes you forward one little bit.
13. Investors invest in people and not just innovation. Like it or not, investors are typically not investing in the great new invention but in the team that will take it forward. In most cases, this involves a break between the academic research and the spin-out.
14. Four slide rule, always. You only need four slides: the problem, you and your team, your innovation, and how you will execute. Don’t bore your audience; inspire them into your dream and vision, and listen to what they say. And, remember, it has a great simple opening slide — so dwell there as you introduce yourself and your vision. And end with a bang!
15. Define the culture at an early stage. This might not seem to be a core focus, but it is important to lay out the ethics and morals of the company and how it will share any success that it gains. Those who invest their time and energy at an early stage should see rewards, and where no one is seen to have more than the share they deserve.
16. Pick the right place and the right people. Don’t grow your company in a place where you cannot attract the best talent. Pick a great city, and place yourself there.
17. Get an amazing HR team in place. This is fundamental. Great companies are created by great people. Your recruitment should focus on those who focus on quality. They are people with an eye for detail but who can abstract things and who are able to focus on things. They are basically people who care more about responsibilities than their job titles. Recruit people for their talents and passion, and not because they have years of experience in given technologies. For example, it is often better to take an engineer or mathematician and train them in coding than to take a computer scientist and train them in engineering.
18. Remove bureaucracy and rigid structures. Committees, bureaucracy and rigid structures often stifle innovation and allow some people to hide from their responsibilities. Rigid structures stop people from working across departmental boundaries, so try and be flexible — and allow a cross-fertilisation of ideas.
19. No hiding place. There should be no place to hide a small and growing company. Those who fail to match up to the pace of the company and its vision should be allowed to leave. But, for those who do, the company should do as much as it can to retain them. Don’t let any good employee leave without trying your best to keep them. Know why people want to leave, and try and address these things at an early stage.
20. You need a common goal and purpose. A core part of a great team is that they have a core goal and purpose and where everyone shares this. A company must recruit for these purposes and find those who match them. A bad hire is a wasted opportunity and will only cost more money in the future. See №17.
21. Praise those who are successful. A great team celebrates the success of their members and does not see it as a threat to themselves. Don’t hide success in whatever form it appears.

And finally:

Success leads to more trust. When you write a research proposal, you have a long statement about why you should be trusted to gain the funds. A core part of this is defining and articulating your success. No one ever really defines all their failures, but for anyone who has been successful, this is probably been a core part of the reason they have been successful. So the more success you have, the more likely that you will be trusted with other people’s money and time. If you cannot articulate your success to others, you will often struggle to influence others. Document and capture your successes are you go along, and get others to make comments on them.

There’s one little program that I could not do my work without … Git.

And, so, our digital world needs to say a great thanks to the wonderful Linus Torvalds. In fact, without him, our digital world would be a whole lot more locked-down and controlled by large and faceless companies. Without Linus, we would probably now be dominated by Microsoft Windows, and your car and your mobile phone would probably be running Windows for its interface (yuk!). And if the software in your car crashed — as it would likely do on a regular basis — you might possibly have to connect a keyboard to your instrument panel and press Ctrl-Alt-Del.

Your TV, too, would possibly boot up into Microsoft Windows, and you’d need a mouse to control it. And our world of servers would possibly mainly be running on Microsoft IIS and use MS SQL databases. And, to back up your code, you would need a licence for Microsoft Backup 3.1, and where you dragged your folders over to make updates. Possibly, the command line terminal would have been dropped in favour of GUI (Graphical User Interface) approaches.

So, just as in the famous advert from Apple in 1984 which illustrated the smashing of a Big Brother screen, Linus smashed the world of Windows — sorry for the pun!

https://www.youtube.com/watch?v=2zfqw8nhUwA

And, so rather than a world of Microsoft Windows, our world is full of Linux and associated distributions. For this, he wrote the first version of the Linux kernel and wrote the original version of Linux with pure machine code. I suppose there is something in the DNA for the Finnish people, that wants to be open about things, and not close them down with patents and restrictions.

So, while the creation of Linux is possibly one of the greatest advancements in Computer Science. There is something even better … Git. With Git we have a version control system of code and documents. I use it every day, and it saves me so much time and effort. I use it in so many ways, including archiving my code and updating my Golang libraries. At its core is a smart way of keeping track of any version of a file and the difference between them.

Linus wrote Git in 2005 for his Linux kernel but is now maintained by Junio Hamano. At its core, each host maintains a complete repository of all the files it has archived and how they have been modified. This differs from the client-server-based approach of code repositories, as the tracking can be done independently from a server.

With Git, you end up with some commands that are hard-wired into your memory. We use “git add .” to add new files, then “git commit -m ‘New update’” to search for changes in the files, and then finally a “git push” to upload the new versions. Then a “git pull” to get things back. Anyone who has ever lost their code or created a bad version will know the power of using Git to recover things. Three basic commands are thus:

But, it’s not just code it can archive; it can archive many different document types, and it particularly likes mark-up documents such as LaTeX. Overall, Microsoft Word is terrible for version control, as the file is encapsulated in a Zip file. Many developers thus use LaTex and archive with Git. The great advantage of this is — just like Wiki’s — we can trace the updates through text. It also allows us to easily share documents and allow collaborative work (as Git can keep a track of the update). And, for large files which are more than GBs in size there is Git Large File Storage (LFS) — git-lfs.

And, so, if we were to start the Internet again, possibly LaTeX and Git would be used to create our documents, and we would have no Microsoft Word. In fact, we would probably not need Microsoft Windows, as our world would be open-sourced with the use of Linux. While Linux has always struggled to compete with Microsoft Windows and Mac OSX, it is open and free. The code for Linux, too, is open to all to examine and update. People often maintain open-source software as they have a real belief in its power and in how it frees us from the dominance of large and powerful companies.

There are so many use cases of using Git that are not just versioning code. For my own teaching, I use Git to push my PowerPoint slides, source code and labs. Students can easily download the whole module at the start of the course and thus just to a “git pull” for any updates. Students, too, can mark typos in the material. You can find this at:

Another interesting example is the District of Columbia and which publishes its laws through Git. This allows everyone involved to keep track of changes in the law and also spot errors and typos. If you are interested, the laws are marked up with XML and available at:

This, though, is the definitive source of the law, and not a copy from another system, and where a “pull request” allows someone to update a document, and then for the maintainer to review and change, if required.

To, me, Git is the one tool I could not do my work without. I love it, as I don’t need a fancy GUI, I just drop down to the console and let my fingers to the walking. And, so, just like smashing Big Brother, Linus smashed a closed digital world and free us from the control of software. If we were to start the computer and software industry again, it would be Linus’ route we would take and not the closed-source world of big business. If not for Git, we would probably be using Microsoft Backup 3.1 and dragging our files from one place to the next.

Chris Were is the CEO of the Verdia network. More details here.

YouTube video: here.

Blog: https://medium.com/asecuritysite-when-bob-met-alice/tetra-burst-42773a490b35 

Introduction

Anyone can create a cipher. Basically, Bob and Alice do some modulo maths and could encrypt their secret messages into ciphertext by multiplying by 10 and adding 5, and then to decrypt back into plaintext, they would just subtract the ciphertext by 5 and divide by 10. The maths involved could then be defined by a Galois Field (GF)— and which is named after Évariste Galois. Bob and Alice could then keep their method secret from Eve (their adversary), and where they believe their method is secure and thus do not ask Trent to evaluate its security.

But Eve is sneaky and tries lots of different ways to crack the cipher. Eventually, after trying to crack the ciphertext, she discovers the method, and can then crack all the future (and, possibly, previous) ciphers. Bob and Alice then carry on using the secret cipher method and would then have no way of knowing that Eve now knows their method.

This approach is often known as “cooking your own crypto”, and is not recommended in most implementations. Along with this, as Bob and Alice try to hide their method from Eve, the approach is “Security by obfuscation” rather than “Security-by-design”.

There are many cases of propriety cryptography methods being used in production. In 2013, for example, researchers at the University of Birmingham found flaws in the key fobs related to the Volkswagen group vehicles. In fact, the encryption used in the Swiss-made Megamos transponder was so weak that an intruder only needed to listen to two transmitted messages from the fob in order to crack the key.

The vulnerability related to the poor, proprietary cryptographic methods used by the device, and where the researchers found they could generate the transponder’s 96-bit secret key and start the car in less than half an hour. The vulnerability has been well known since 2012, and code to exploit the flaw has circulated online since 2009. Yet, at the time, there was no product recall for the dozens of models that were affected, including Audi, Porsche, Bentley and Lamborghini, Nissan and Volvo. The research team were even stopped from publishing their work through the threat of legal action from Volkswagen.

Along with the risk of discovering a secret method, the other major problem is that the method used to create a cipher is when it is not rigorously reviewed by experts. This can take years of reviewing and testing — both in the formal theory and in practice. Many companies, too, have bug bounties and which try to discover vulnerabilities in their code. To overcome this, NIST has created open competitions for the standardization of encryption methods. These have included standards related to symmetric key encryption (AES), hashing methods (SHA-3) and post-quantum cryptography (PQC). Once rigorously evaluated, the industry can then follow the standards defined, and where proprietary methods and implementations are often not trusted.

With symmetric-key methods (where the same key is used to both encrypt and decrypt), at one time, we used a wide range of methods, such as DES, 3DES, RC2, RC4, Blowfish, and Twofish. To overcome this, NIST set up an operation standardization process for the Advanced Encryption Standard (AES). In the end, and after extensive testing and performance analysis, the Rijndael method was selected. It is now used in most systems, with either a 128-bit, a 192-bit or 256-bit encryption key. Overall, the larger the key size, the more difficult it is to brute force the key.

This week it has been reported that the TETRA (TErrestrial Trunked RAdio) standard [here] has a number of vulnerabilities in its cryptography. Overall, TETRA is used by many police and military forces across the world for encrypted radio. These vulnerabilities have existed for over a decade and could have led to the leakage of sensitive information.

These vulnerabilities have been discovered by Midnight Blue and will be presented as “Redacted Telecom Talk” at Black Hat 2023 on 9 August 2023 [here]. As the work is so sensitive, there are many issues related to its disclosure, so the full details of the talk have not been released. But, it has involved over 18 months of responsible disclosure related to the cracking of TETRA-powered radios purchased from eBay.

TETRA was first standardised by the European Telecommunications Standards Institute (ETSI) in 1996 and used by many radio manufacturers, such as Motorola and Airbus. It does not have open-source software and relies on cryptography which is secret and proprietary.

Goverments around the world have generally used export controls on cryptography — in order to reduce security levels so that their own law enforcement agents have a good chance to crack encrypted traffic outside their own borders. One of the most famous was related to Netscape and who created the original version of TLS (Transport Layer Security) that created a secure channel for Web pages — the HTTPs that we see on most of our Web accesses now.

This, though, had reduced security levels because of export control — with the RSA method used set at only 512 bits (and which is now easily crackable). As this key was used to pass the encryption key that was used in the secure tunnel, it meant that agencies could break the communications channel for HTTPs communications. We have since paid for this weakening —and with vulnerabilities such as Freak and BEAST. The vulnerability in TETRA, too, relates to similar issues and where the cryptography was reduced to comply with export controls. Within TERTA, the TEA1 method reduces the key size down to 80 bits, and, along with other vulnerabilities, allows the encrypted traffic to be cracked within minutes on a standard laptop.

Along with this, researchers found other vulnerabilities with TETRA methods that released sensitive information — including within historical communications. The core vulnerability involved a jump-off from the main interface on the radio, and then which followed through with running malicious code execution on the process and then onto the signal processor and wifi hardware. This main chip on the device then contains a secure enclave, which stores the main encryption keys. The team were able to access this chip and discover the cryptography methods used and associated artefacts. For this, they have dubbed the vulnerability TETRA:BURST [here]:

The reduced security method of TEA1 was discovered as having an encryption key of just 80 bits (normally, we would use a 128-bit key size, at least). A key size of 80 bits puts it within a range which can be cracked using GPU clusters. But, the research team found a “secret reduction step” which supported lower levels of randomization for the encryption key and which significantly reduced the key strength. Using this, the team were able to crack the communication with consumer-level hardware and with inexpensive radio equipment. Ultimately, the researchers define the attack as fairly trivial to implement.

A number of CVEs have already been defined for the vulnerabilities. These are [here]:

• CVE-2022–24401. This involved the Air Interface Encryption (AIE) keystream generator allows for decryption oracle attacks.
• CVE-2022–24402. This relates to the backdoor of the 80-bit key on the TEA1 algorithm — and which allows a trivial cipher crack.
• CVE-2022–24404. This involves weaknesses in the AIE for malleability attacks.
• CVE-2022–24403. This is a weak cryptographic scheme that allows attackers to deanonymize and track users.
• CVE-2022–24400. This allows attackers to set the Derived Cypher Key (DCK) to 0.

On the CVE database [here], these vulnerabilities are marked as “** RESERVED **” and will be populated soon.

What we have here is “Security by obscurity” and not “Security by design”. It is difficult to keep anything a secret these days, and, as much as possible, methods should be open to assessment. Along with this, the reduction in the security level for TEA1 is causing major problems — just the Netscape restriction on TLS left us with a security legacy that took decades to address.

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

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:

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.

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

This exponential becomes point multiplication, and multiply/division becomes point addition/subtraction.

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]:

A sample run is:

And there you go, ElGamal using ECC:

https://asecuritysite.com/elgamal/go_elgamal_ecc

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}

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. 

Blog: https://medium.com/asecuritysite-when-bob-met-alice/passion-leadership-and-responsibility-ded697c73c76

Introduction

I have been involved in enterprise and innovation for quite a while. I love it, and where I have had the opportunity to think and dream and kick-start things that flourish in the future. Some things have worked, and other things have not. And, we have been so lucky to have spun out three highly successful cybersecurity companies, and each of which has come from a seed of an idea but has been built by great people.

And I am so pleased that people like Professor Mark Logan are now introducing words like enterprise and innovation back into academic approaches, as, for too long, it was all about research. Overall, research will go nowhere without adding some innovation and then some enterprise to take it to places where real people find real uses for it. In academia, there can be game-playing, and where the impact factor of a journal or the number of publications in the year can be seen as having an impact. But, the real impact happens in the real world and away from citation counts and impact factors. And, for grants, it is not the income that matters; it is what the grant actually does.

Over the years, too, I have seen many approaches to enterprise and innovation, and at the core of this is knowing what the problem is that you are solving and that there is a market in what you are creating — in crude terms, it is, “Know the market and your customer”.

At the core of a great company is the genuine passion for what you do as an organisation. It should never be false passion — but genuinely, from the heart — we love what we do. And I’ve observed that great companies focus on the quality of what they do and never dwell on what they have at the current time.

A great company, too, prizes leadership and responsibility, and where job roles have lesser importance than someone’s responsibility. I have never liked committees and bureaucracy; they are often created through a lack of trust in individuals. Few committees ever make strategic decisions, and few committees ever innovate anything.

And, so, to me, the best companies/organisations have leaders who are generally self-starters — they don’t need to be prompted to do something — they just know it is right to progress something. These leaders, hopefully, should be instantly identifiable in your organisation, and who you could communicate with in an instance. Great leaders should not hide behind administrative support but actively engage with those who have questions about their approaches.

To me, companies should always try to break down these barriers to advancement and try to minimise the time in meetings. For me, I despair at the two-hour meetings with fixed agenda — and with a growing list of attendees. I’ve always found that time spent discussing will grow exponentially with the number of people in a meeting. The best meetings for me, as those which communicate things and have an open place to discuss any concerns, and then they finish on time.

And great companies often do not pinpoint blame on individuals. They will investigate what went wrong but will never end up pin-pointing any individual. This approach allows individuals to feel confident that they can take responsibility without feeling that, if something fails, they will end up being blamed for the failure.

So, here’s my bluffers guide to creating a great company/organisation:

• Be passionate about what you do. Love your business.
• Understand the market and your customer’s needs.
• Promote leadership wherever possible.
• Do not blame individuals for mistakes.
• Recruit amazing staff, look after them, reward them well, and keep them.
• Break down the hierarchy.
• Focus on responsibilities rather than job roles.
• Promote enterprise and innovation wherever possible.
• Remove bureaucracy wherever you find it.
• Remove committees wherever possible.
• Be agile, move fast and execute quickly.
• Small teams often work best.
• Support the generation of ideas from every part of the business.
• Praise success wherever possible, and allow others to share in the success.
• Know when something fundamentally isn’t working, and stop it.

And, the signs:

• There is a genuine passion in the company/organisation.
• There is a core focus on quality.
• Leadership drives the company.
• Leaders are highly visible to all and are self-starters.
• There is a common and shared vision.
• There is accountability in decisions.
• There is open communication for debate within teams/company.
• Success is communicated within teams and where teams genuinely feel proud of their achievements.

Avoid hooking up with a company or organisation with followers which is full of committees and line managers. Oh, and get the best HR people possible! For a start-up, the HR function is likely a core part of the success or failure of a company.

For me, I love innovating, and I love teaching and researching cryptography, and my university has given me the space to do these things. I have a passion for education, and I love what I do. Go find your passion if you have not already found it …

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:

1. 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.
2. You should not trust a JWT unless it is cryptographically signed.
3. For authorization, a captured JWT can be replayed and “played back” to provide a malicious entry or rights into a system.
4. JWTs should never be trusted before their issue date and their not-before date and never trusted after their expiry.
5. JWTs have been defined as an RFC standard with RFC7519.
6. The format is URL friendly and is Base64URL encoded.
7. A JWT token has three main parameters separated by a period (“.”), and which are the header, the payload and the signature.
8. The header is typically not encrypted and defines the signature algorithm (“alg”) and the type (“typ”).
9. The payload is typically not encrypted and uses a Base64 format. The payload can typically be seen by anyone who captures it.
10. “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.
11. 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).
12. The claim fields are not mandatory and just a starting point for defining claims.
13. A claim is asserted about a subject, and where we have a claim name and a claim value in a JSON format.
14. With an HMAC signature, the issuer and validator must share the same secret symmetric key.
15. If you use HMAC to sign the tokens, a breached secret key will compromise the signing infrastructure.
16. The two main public key signing methods are RSA and ECDSA.
17. The time of a token is represented as the number of seconds from 1 January 1970 (UTC).
18. Each day of a JWT token is represented by 86,400 seconds.
19. 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.
20. 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:

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.

A JWT token splits into three files: header, payload and signature (Figure 1).

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:

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:

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:

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:

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 is:

We then have:

• Header: eyJhbGciOiJFUzI1NiIsICJraWQiOiJ3WHd6dVEifQ
• Payload: eyJhdWQiOiJxd2VydHkiLCAiZXhwIjoxNjkwNzU0Nzk0LCAiaXNzIjoiQVNlY3VyaXR5U2l0ZSIsICJqdGkiOiIxMjM0NTYiLCAic3ViIjoiaGVsbG8ifQ
• Signature: cAXunJHLRrqFfJStJTFlwkUTze6K8EpwOui9abDeiSBcR5WeOEpXCSUQBnS_VdVnLsmVV2AWUX0kOTqIWERcMQ

These are in Base64 format, and we can easily decode the header as:

and the payload as:

The signature value will be in a byte array format.

With Google Tink, we can create a token with the fields using:

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:

We can then create the public key from the private key, and validate the token with this key:

The full code is [here]:

A sample run proves the process [here]:

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:

Blog post: https://medium.com/asecuritysite-when-bob-met-alice/noyce-moore-and-grove-a-template-for-spin-out-start-up-success-b67d9795154a

Introduction

So, is there a formula for a successful start-up/spin-out — and if you followed it, you would be guaranteed success? For this, many people approach me and say, “I want to have a spin-out. What should I do?”. To me, this is a little like saying, “I want to fly, can you give me wings?”. So, let me lay out a few things that I have learned over the past two decades of being involved in spin-out companies.

Overall, we have been very lucky in our spin-outs, with three highly successful ones, and where two have been bought out (Zonefox and Symphonic), and the third is expanding fast within digital forensics (Cyacomb). But, as they say, “The Harder I Practice, the Luckier I Get”. We have had failures, but every time our team has licked their wounds and come back stronger. And the one thing, though, I’ve observed is that the leadership of an innovative company often needs to change as it evolves, and those leading it need to know when they need to move aside and let others take their place.

So, I’m going to define the three stages as: Visionary, Strategy and Grit, and where there are very different leaders at each stage. But, fundamentally, the first two stages set up the culture and approach of the company, and which are fundamental to its long-term beliefs and ideals. Overall, few companies in the third stage can turn their ship and travel in a different direction. The approach of IBM, for example, is still one of an engineering approach to their work and one built on rewarding innovation.

And, so I am a cryptography professor, and not a business one, so please forgive me for not covering the core literature in the areas of business. I am also highly technical, and that is what I love. I would never want to be a cut-throat business person and would never want to be. I love inventing things and seeing ideas grow from seeds. And one thing I know is when my role is complete as part of the innovation process and when to move aside.

But, deeply technical people are at the core of creating a successful spin-out, along with people with a vision. And, so, I would like to lay out a basic template of my observations in creating a successful spin-out — and based on the ones we have produced. To me, also, a great technical company should have a core of theoretical work, and where the best work can come from academic collaborations. In academia, there is an attention to detail and theory, and which makes sense of the complex world of invention and discovery. But, the magic comes from practical implements, and where the best collaborations mix practice with theory.

So, my basic template for success is to get the right leadership team in place, and get the right leader for the right time. A core part of this is knowing when the leader should move aside and let someone else take over. For this, I’ll map it to the success of Intel and its first three employees: Robert Noyce, Gordon Moore and Andy Grove.

If there’s a superstar of our digital era, it must be Robert Noyce. Imagine inventing the one thing that now drives virtually everything in our digital age: the integrated circuit. It all started in the late 1950s with John Bardeen and Walter Brattain at Bell Labs and who first invented the transistor. William Shockley advanced the concept with the creation of the bipolar transistor. Bardeen and Brattain were a great research team and has a great balance of theoretical skills with practical ones. Brattain did the theory, and Bardeen did the practical work. All three eventually received a Nobel Prize for their work — with Brattain being one of the few people to ever get two Nobel Prizes.

While Bell Labs was a hub of innovation at the time, Shockley wanted to take a good deal of the credit for the invention of the transistor and left Bell Labs to set up his own company in 1955: Shockley Semiconductor. For this, we recruited Robert Noyce and Gordon Moore to work on his ideas. But Shockley was a difficult boss and had an overbearing approach to his management style. This caused eight of Shockley’s employees — including Robert Noyce and Gordon Moore — to leave the company and start their own venture with the support of Fairchild Camera and Instrument. It was there, in 1961, that Robert created one of the most significant patents of all time:

It outlined a magical way of doping a semiconductor substrate and producing an integrated circuit:

This invention differed from Jack Kilby’s work at Texas Instruments, as Robert outlined a monolithic circuit while Jack defined a hybrid circuit approach. And, so, Fairchild grew fast as a leader in semiconductors, but as the company grew, Robert increasingly missed the days of true innovation and decided to team up with Gordon Moore to create Integrated Electronics (which would end up just being known as Intel).

And, so, Robert was the anchor for the creation of Intel. A true visionary and someone that people trusted and listened to. It was thus not difficult for Andy Rock to find the seed funding for the start-up — as it had Robert’s name on it. Those who invested in the company were not investing in the company and its projected product line but in Robert.

In Stage 1 we thus have the visionary leader. The person who can see beyond the near future and build a company that could scale towards their vision, and someone who both inspired people to believe and someone who others could trust with the vision.

And, so, Robert led Intel from 1968 to 1975 but knew the time that he needed to hand over to someone else. And, that needed to be someone who had a core understanding of the technology required to scale Intel: Gordon Moore.

In Stage 2, we move from the visionary leader to the strategic leader, and there was no better person than Gordon Moore (and who created the mighty Moore’s Law — and which is still relevant to this day). Gordon had an eye for detail and quality. For Intel to succeed, they needed someone to convert the vision shown by Noyce to something that matched the market. For this, he invested heavily in R&D and made Intel a world leader in the memory market. But, he showed his strategic brilliance by spotting the opportunity to initiate work in microprocessors.

As we all know, in 1969, Intel was designing some chips for Busicom and decided to integrate these into a single device, which could be programmed with software. The designer was Ted Hoff, and he produced the first microprocessor: the 4004. And, so, as the memory market became crowded and profits fell, Gordon moved Intel out of it and ramped up the development of the 8-bit and 16-bit microprocessors. The device that sprang out of this development was the Intel 8086, which — luck would have it — was the processor selected for the IBM PC. It was luck and strategy, and Gordon was a core part of this. Most CEOs would have pushed forward in the memory market, but Gordon focused Intel’s R&D on new markets.

Gordon Moore was thus the second phase leader and the one who could stop opportunities and be in the right place at the right time to exploit them. Without his technical genius, the company would have struggled to understand how to scale R&D into emerging markets.

And now we need the last piece of the puzzle … Andy Grove. Intel had grown up as a company of idealists and lacked a “Us and Them” approach to management. Noyce, Moore and Grove had led the company, but they were colleagues. Many remember that it was often difficult to find Gordon in the company when they visited him, as he sat in a cubical in the open plan set up and shared the same physical space with others in the company. There were no fancy trimmings for Gordon in his CEO role — he was as much a worker as any other.

And both Robert and Gordon had a gentle approach to their management style, but Andy brought an edge that the congenial Moore and Noyce could never give.

At eight years old, Andy escaped with his mother from the Nazis and left Hungary at the age of 20 during the Hungarian Revolution. He arrived in the US as a refugee with no money but with a passion for learning. Eventually, he gained his PhD from the University of California, Berkeley. 

And, so, Andy provided the grit and desire to succeed that Intel needed, and, as with Gordon, he had an eye for quality and in making sure that everything that Intel did was at the highest possible technical level.

And so it was Andy who had the grit to move Intel out of its core memory business and into microprocessors. He had a knack for taking complex problems and distilling them down into strategies that were easy for those involved to understand. Perhaps it was because he was an engineer first and then had to learn about management and strategic approaches.

His strategy was to move Intel out of memory and straight into the PC. The natural choice at the time for the processor in the PC was Motorola, but Grove managed to get the technical support in place for the Intel chip, and that allowed engineers to develop their prototypes. And, what did Grove do about the expertise in memory? He put it to good use in integrating SRAM caches into the processor, which massively speeded up their operation.

Andy thus had the grit that Intel required to take it into new markets and win:

The most important role of managers is to create an environment where people are passionately dedicated to winning in the marketplace. Fear plays a major role in creating and maintaining such passion. Fear of competition, fear of bankruptcy, fear of being wrong and fear of losing can all be powerful motivators.

Moore and Noyce drove Intel to become one of the world’s most powerful companies. The team had a perfect balance … Noyce inspired everyone he met and built an initial customer base, while Moore built technical excellence and then followed through. It was left to Grove to focus on detail and excellence. William Shockley failed in the market as he couldn’t share success with others, while Moore, Noyce and Grove built a culture of collaboration and in taking shared ownership of the company they built.

The first stages of a company are thus so important is building its culture into the future. If those involved in those first stages do not act in the right way, then the company may be doomed to have the wrong approaches to its employees and customers. The initial leaders are the ones that people should look up to and be inspired by. This is not often through business practice, but having core scientific and technical expertise in their field.

So, get your team in place … a visionary, a technical genius, and a true leader with grit. But, knowing the best leader at any given time and knowing when to hand over to someone else can take the next great step forward. And, go do something wonderful …

Blog: https://medium.com/asecuritysite-when-bob-met-alice/a-soft-target-are-higher-education-infrastructures-at-risk-4ff323fd73c5

Academia was one of the first infrastructures to build and use the Internet — in fact, they built ARPANET and which morphed into the Internet. And so, you will find that they often have privileged IP address ranges, such as for Class A or Class B. With this, when IPv4 address ranges were initially given out, universities and research organisations were granted large address spaces to allocate to their growing networks. No one, at the time, could have ever envisaged in how much the Internet has grown since then. To make things easy, nearly every computer that was allocated a public address could be connected to directly — these were routable Internet addresses. To overcome these direct connections, firewalls filtered data packets and tried to stop malicious access.

We might call this the “Happy Phase” of the Internet, where it basically interconnected trusted organisations and where there was no real concept of many people outside this trust circle having access to a computer. It was a new frontier in technological development and seemed to be a nice way to send emails between academics and researchers and to showcase their latest research work.

By a public address, we have the concept that it is possible to route data directly to a computer. As you connect to this article, you are likely to be using a non-routable IP address, which is hidden between a NAT (Network Address Translation) router. These privileged academic address spaces supported public IP address spaces for thousands or even millions of hosts — and where a Class A IP address can allow over 16 million computers to have a public IP address.

The University of California, Berkley, for example, has an IP address and subnet of 104.247.81.71/8, and where 104.0.0.0 is the network address, and where 24 bits in the address can be used for subnetworks and hosts. This means that the host part can be used to create subnetworks with an extension of the subnet field. Ultimately, a Class A address can give up to 16,777,216 publicly addressable hosts. And, so, while most organisations put their computers in private address spaces (though NAT), universities had enough IP addresses to allow many computers to be publicly addressable.

In fact, at one time, an academic’s desktop computer was likely be allocated a public address and could thus be directly contacted. And, so, as long as the computer was powered on, it could be addressable. Along with this, a log of any sites visited would leave a trace of the public IP address. In fact, it was all too common to add a DNS entry of Bob’s computer as “Bob.uni.edu”. But, this was all created in a time of little concern about cybersecurity, and it allowed academic infrastructures to grow dynamically — and under their own control.

This was all set up before any real concept of requiring cybersecurity — as the networks were often just used to interconnect networks. So while other infrastructures have closed themselves to external threats, universities — in places — can still support legacy applications and have security support which ends after the working day.

I have observed the rise of the SOC (Security Operations Centre) in the finance industry — in fact, many of our graduates go into jobs that relate to this. I’ve also toured many of the SOCs in Glasgow and Edinburgh and love to see the fusion of data from inside and outside the companies. Basically, these companies had to move from being a Monday to Friday, 9am-5pm company to looking after security 24x7.

But what about Higher Education (HE) as a sector? Well, I might be wrong, but higher education has not adopted the concept of 24x7 SOCs, and at 5 pm, many networked infrastructures hand over to support staff. There is very little in the way of sharing security resources across HE, too. Like it or not, our adversaries don’t work 9–5pm (GMT), and are most likely to be on a different time zone in the world.

And, so, we see the University of Manchester and the University of the West of Scotland (UWS) being subject to a cyber attack in the last few weeks, and this could be the start of a targeted offensive against network infrastructure with weaker support for security. The attack on the University of Manchester was part of a vulnerability around the usage of the MOVEIt protocol:

The attack on the UWS site happened around 6 July 2023, and now it is suspected data from the breach where it is reported that the ransomware gang of Rhysida [here] is selling breached data to the highest bidder for 20 bitcoins (£450,000):

The site went down for around a week, and it affected a range of internal systems. At the current time, it is thought that the breached data includes bank details and national insurance numbers, along with internal documents from the university. Presently, there is no real information on whether these documents are real or not.

The breach happened around the first week in July 2023, and when the UWS site started to show the message of:

At first sight, this could be a standard domain take-over, and where the HTTPs certificate is valid:

But, with a lookup, we see that the domain name has been parked at 3dqkz9i.x.incapdns.net:

Overall, Incapsula is a cloud-based hosting company — it may be that the university is using the cloud provider for their hosting. Generally, it is not recommended to actually log into the site (even though the password hint is ‘Google’), as the main page seems to have a redirected site on the redirected site:

Generally, there is a sign of the usage of WordPress, and which may be used to deliver the UWS Web pages (wp-content is a typical folder used to store digital content on a Word Press site) — this might point to a WordPress site take-over:

If we go to the Way Back engine, the last recorded site archive was on 1 July [here]:

Overall, the HTML is there is signs of WordPress being used:

If we try some of the links above, we get:

Academic information infrastructures have grown independent of each other — and were a key part of building the Internet. Those, though, were the “nice” days, but where we have massively grown our digital footprint. The exposure is now massive, especially with the rise of SaaS, and where many universities use third-party applications for contacts and HR systems. We need to move into a world in which shared cybersecurity and setting up 24x7 SOCs for universities is a must … as it is for most other sectors.

I believe that university security teams should work together, and merge resources for defence, and bring in companies who are well used to running SOCs in the finance sector. At least, every institute should look at running SOC on the basis that we would see in the industry — as the data contained in the network — and the risk to student’s education — is too great a risk. To me, the University of Manchester and UWS data breaches are just the start of a targeted offensive against softer targets. And the ability to recruit and keep cybersecurity staff in academia is going to be a major problem.

Related blog post: https://billatnapier.medium.com/cryptography-fundamentals-commutative-encryption-19ba4c4c2173

Introduction

What’s at the core of cryptography? Well, the simple EX-OR holds a special place, as we can do not lose any information when we apply it. For a bitwise operation of 0 EXOR 0 gives 0, 0 EXOR 1 gives 1, 1 EXOR 0 gives 1, and 1 EXOR 1 gives 0. 

And, so, cryptographers dream of the perfect cipher. And that cipher is a one-time pad. Basically, we generate a one-time use key for our plaintext, and then EX-OR them together, and then just EX-OR again with the same key and we will get our plaintext back. Unfortunately, we can only use it once and need to generate another one. So, let’s see if we can generate something similar but just use the simple XOR method for our encryption and decryption.

In the Tor (The Onion Router) network, data is encrypted with a key from each of the Tor routing nodes. Thus, if we have three nodes of A, B and C, with A as the entry node and C as the exit node. For this, the user will generate a separate key for each node to use and encrypt with the key of A, then the key of B, and then the key of C. The encrypted data is passed to A, and which will decrypt with its key, and pass the encrypted data onto B, and who will decrypt with its key. Finally, C will decrypt with its key, and the data will be decrypted. This protects the data as it is routed. But we have to remove the keys in the reverse order they were applied. One way to do this is with commutative encryption.

When I worked as an electrical engineer, we had a hasp to isolate the electric power on a device we were working on:

With this, each person who was working on the equipment, would put on their own padlock, and where we could not put the power back on, until all the padlocks had been taken off. The padlocks could be put on in any order, and taken off in any order, but there was no way to putting the power back on, until everyone had taken their padlock off.

So how could we do this with data. Let’s say that Bob, Alice and Carol want to apply their “data hasp”, so that the data cannot be revealed until they have all taken off their padlock. Well, with symmetric key block ciphers, such as AES, we cannot do this, as we must decrypt in the reverse order of they keys being applied:

To encrypt: Bob → Alice → Carol … and then to decrypt: Carol → Alice →Bob

There are ways to do it with RSA, such as with SRA [here], but these methods significantly reduce the security of the process. The solution is to use a stream cipher, as we basically just X-OR the data when we are encrypting, and then X-OR again with the same key when we decrypt. We can apply multiple keys to the data, and in any order and it will always decrypt properly once we have applied all the keys.

What we need with commutative encryption is to have an encryption string which is the same length as the data string. To make the encryption string, we can use an XOF (eXtendable-Output Functions) and where we can create a hash value of a given size. For this, rather than the fixed hash of SHA-3, we can use the SHAKE. Or with With BLAKE2b we have an XOF of BLAKE2XB, and for BLAKE2s we have an XOF of BLAKE2XS. We can then basically have a secret passphrase, and which generates an output which matches the length of the plaintext. Another method we can use, is to generate an pseudo infinitely long encryption key which is the same length as the plaintext — in the same way that a stream cipher works.

With the ever increasing number of breaches, we are moving to a world where companies should not hold any personally sensitive information, as it is just too risky. So how could we create a trustworthy system, where someone can show up with a ticket, and where we can trust it, without actually revealing any personal information about where the person has booked their seat?

So how can we generate a receipt of the booking, but not give away your identity, or the details of the booking? Let’s take an example of booking a seat in a theatre at the festival, and how your privacy can be respected, but where the theatre will trust the ticket.

Let’s say there are 100 seats in a theatre, and I want to book one of them, but I don’t want the theatre company to know which seat I’ve booked, or my identity. I also want a receipt of purchase that they can verify my booking. One way would be to get a trusted agent to look after the bookings, but I don’t trust them either. So how can we do this?

Well it can be done with commutative encryption.

The steps would be:

• Initially the theatre company generates 100 receipts for each of the seats, and then encrypts them with its public key.
• Next when I want to make a booking they send me the encrypted receipts that they have left, and I select one at random, and then encrypt it with my public key.
• I send them all back, including the one I’ve encrypted.
• The theatre checks to see which one has been changed, and then decrypts it with its private key, and sends it back to me.
• I decrypt with my private key, and I can now view the receipt for my booking, and the theater company cannot determine which seat I have, but I will have the receipt of my booking.

So here is an example where the theatre encrypts all the seats with its key, the person then selects one, and encrypts with their key, and sends them all back again. Then the theater decrypts the one that has changed, and sends it back for the person to decrypt, and we have a booking. The theatre thus does not know who has booked the seat:

ChaCha20 is a stream cipher, and where we created pseudo infinitely long encryption key, and the just XOR it with the plain text.

With commutative encryption, we can decrypt with the keys in any order. Normally we would encrypt with Bob’s key and then encrypt with Alice’s key, and then we must decrypt with Alice’s key and then Bob’s. In commutative encryption, we can decrypt in any order.

With a stream cipher, we can automatically apply commutative as we basically just EX-OR with the key stream. In the following we use Go code, and where Bob encrypts, Alice encrypts, Bob decrypts, and then Alice decrypts [here].

And a sample run [here]:

We can easily extend the method to Carol, Trent, and so on. In my simple example I have used the same nonce for Bob and Alice, but in real life they would use different values, and these would be random for every transaction.

NIST chose Keccak as the standard for SHA-3. But, it’s all a bit confusing, as there are two main versions of this: Keccak and SHA-3. Many systems, such as Ethereum have adopted Keccak, while others go for SHA-3. The only real difference between them is a difference in the padding of data. An eXtendable-Output Function (XOF) produces a bit string that can be of any length. In fact, we can create an infinitely long bit string, if required. The main methods are SHAKE128, SHAKE256, BLAKE2XB and BLAKE2XS. With the SHA-3 hashing method, we have four different cryptographic hashing methods (SHA3–224, SHA3–256, SHA3–384, and SHA3–512) and two XOF functions (SHAKE128 and SHAKE256). 

With commutative encryption, we can decrypt with the keys in any order. Normally we would encrypt with Bob’s key and then encrypt with Alice’s key, and then we must decrypt with Alice’s key and then Bob’s. In commutative encryption, we can decrypt in any order. While our symmetric key block ciphers cannot be made commutative, we can use stream ciphers, as they perform an EX-OR function. In this example we will use the SHAKE128 or SHAKE256, and generate Bob and Alice’s key.

https://asecuritysite.com/commul/comm_stream

With maths, operators such as multiplication are commutative, such as:

In encryption, most operations are non-commutative, so we need to modify the methods. One way is to use RSA, but generate two keys which have shared p, q and N values. So we generate Bob and Alice’s keys using the same two prime numbers (p and q), so that they share the same N value (modulus).

So let’s start with Bob:

The calculation of n and PHI is:

We need to make sure that our encryption key (e) does not share any factors with PHI (gcd(PHI,e)=1). We can select e as:

Next we can calculate d from:

The answer is 29 [Solve]

Now for Alice. We have:

We can select e as (and should not share any factors with PHI):

Now we must solve:

For this we get 31 [Solve]

Alice’s keys are then:

An example of this is here:

https://asecuritysite.com/commul/comm2

As we have seen, commutative encryption allows us to decrypt in any order. For this we can use Massey–Omura Cryptosystem and generate encryption keys which share a prime number.

One classic patent for commutative encryption was written by James Massey and Jim K. Omura created the Massey–Omura Cryptosystem in 1982 [1]. It took over three years to be assigned and was assigned to Omnet Associates [here]:

It uses exponentiation in the Galois field GF(2^n) for both the encryption and decryption functions. In this, if we have a message of M, the encryption is:

and

This are operated on with the Galois field. For this we define e within:

and we make sure that e does not share a factor with 2^n-1 using:

The decryption exponent d is defined as:

This works because the multiplicative group of the Galois field GF(2^n) has order 2^n−1, and where Lagrange’s theorem defines that m^{de}=m for all the values of m in GF(2^n). The coding is here [link]:

A sample run is [link]:

One of the advantages of the Massey–Omura Cryptosystem is that we can apply commutative encryption. In this way, Bob may have keys of (e_b,d_b) and Alice has keys of (e_a,d_a). We can then apply the keys in any order, such as encrypting with e_a and then encrypting with e_b, and where we can then decrypt with d_a and then decrypt with d_b, or decrypt with d_b first and then decrypt with d_a (as we would normally do).

To encrypt:

Cipher=E(a_b,E(e_a,M))=E(e_a,E(e_b,M))

To decrypt:

E(d_b,E(d_a,Cipher))=E(d_a,E(d_b,Cipher))

Here is an example:

https://asecuritysite.com/commul/massey2

Communative encryption is a great way of applying multiple keys to encryption data, and then for them to be removed in any order that is required. It is a little like how data is encrypted in the Tor network, but that requires the keys to be removed in the reverse order they were applied. In a future podcast, I will explain how the Tor network works.

Blog: https://medium.com/asecuritysite-when-bob-met-alice/can-privacy-and-traceability-exist-together-tracing-keys-and-jurisdictions-bfc395d502a

Introduction

Privacy and traceability are two sides of the same coin, and where the coin will never land on its side. If you want privacy in a transaction, you have to hide the payer and payee and the transaction value. All that needs to happen is that there is proof that the payer has enough currency to pay the payee. We can do this with a range proof — so that Bob can show that the sum of his previous transactions minus the current one is greater than zero. But, this stops any traceability and stops investigators from investigating the trail of an illegal transaction. It’s a dilemma that can keep cybersecurity professionals awake at night and where a few bad apples can spoil the whole bunch.

But, if we add traceability — such as in Bitcoin — we remove the privacy aspect, and if someone links your Bitcoin address to you and the others you trade with, they will be able to see all your transactions. “Ah, I see”, they might say, “That Bill has just bought a ticket for a bus journey in Edinburgh at 10:03 am”.

Along with this, we have different requirements in different jurisdictions and where we might want to limit the investigator power in one jurisdiction to others.

For this, John Gilmore — one of the original Cipher Punks — wrote:

“We are literally in a race between our ability to build and deploy technology, and their ability to build and deploy laws and treaties. Neither side is likely to back down or wise up until it has definitively lost the race”

And, so, the tension between strong cryptography, which protects privacy, and the ability to monitor and investigate remains as open as ever. In the UK, the Online Safety Act could aim to insert backdoors in cryptography in order to monitor communications.

So, is it possible to keep things private but also make them traceable? For this, a new paper outlines the TRCT (Traceable Anonymous Transaction Protocol for Blockchain) protocol [1]:

The focus of the paper is on the anonymous cryptocurrencies such as Monero, Dash and ZCash. It uses an Extractable Proof of Knowledge (EPoK) to produce a Zero Knowledge Proof (ZKP) for a transaction. This can then be added to the RingCT method of anonymity to produce traceable transactions for the participants and the amount transacted. The transaction, though, is still kept anonymous.

The paper pinpoints the usage of Monero in a number of crimes, such as for the Wannacry ransomware attack and where the adversaries converted their Bitcoin rewards into Monero tokens [here], and which has not been since been traced. This problem has become so difficult for law enforcement that privacy-protecting cryptocurrencies have been banned in Canada, South Korea and Australia.

An overview of TRCT is defined in Figure 1. With this, we have a miner which collects broadcasted transactions, and creates a consensus with other miners. An Authority is then responsible for linking account addresses and transactions and which can trace anonymous account addresses of the actual payer and payee and resolve the transaction amount.

For TRCT, the payer generates a long-term key pair and then creates a one-time address (Figure 1). This can then be sent to the payer. The transaction is then anonymised for the payer address, payee address and transaction value using the Ring CT protocol, and which integrates the EPoK scheme. The miner then receives this and checks that it is valid and that the payer has enough currency in their account to make the payment. Next, the miner will check the EPoK so that it can be traced by the authority — and without discovering the secret details in the transaction. The authority can then trace the hidden content in the transaction (Figure 2).

While applied in RingCT, the TRCT can be generally applied to any permissionless and permissioned blockchain, as it does not affect the underlying logic of the blockchain. In this, a trusted authority creates a tracing key and publicises its public key to the miners and whether these miners may be enabled or not for the integration of EPoK. In a permissioned blockchain, there are typically fewer nodes that create the consensus, and where it is thus easier to broadcast and update the tracing key. Overall, the authority is then used to oversee all the transactions, and decide whether there are illegal transactions, and also trace them.

The control of the tracing key can then use attribute-based encryption to control its usage and using threshold-based sharing to control the usage of the key. For example, the FBI, CIA and GCHQ could agree on a 2-from-3 share approach, where two agencies have to come together to regenerate the tracing key. This approach allows for different jurisdictions to generate their own tracing key and where they cannot trace within any other jurisdiction. The addition of tracing tags also allows the tracing of high-value transactions.

Next, let’s cover ring signatures and RingCT.

And so there has been a leak of information at the White House. Donald Trump calls in his Cyber Security leads and tells them, “I know one of you leaked the information, but I can’t tell which one”. How can Donald tell that one of his leads has leaked the information but does not know which one? Well, this can be achieved with a ring signature, and which provides anonymity, unforgivably and collusion resistance.

A ring signature is a digital signature that is created by a member of a group which each has their own keys. It is then not possible to determine the person in the group who has created the signature. The method was initially created by Ron Rivest, Adi Shamir, and Yael Tauman in 2001, and in their paper, they proposed the White House leak dilemma.

In a ring signature, we define a group of entities who each have their own public/private key pairs of (P1, S1), (P2, S2), …, (Pn, Sn). If we want an entity i to sign a message (message), they use their own secret key (si), but the public keys of the others in the group (m,si,P1…Pn). It should then be possible to check the validity of the group by knowing the public key of the group, but not possible to determine a valid signature if there is no knowledge of the private keys within the group.

So let’s say that Trent, Bob, Eve and Alice are in a group, and they each have their own public and secret keys. Bob now wants to sign a message from the group. He initially generates a random value v, and then generates random values (xi) for each of the other participants, but takes his own secret key (si) and uses it to determine a different secret key, which is the reverse of the encryption function.

He now takes the message and takes a hash of it, and thus creates a key (k). This key will be used with symmetric encryption to encrypt each of the elements of the ring (Ek), and then each element of the ring uses an EX-OR function from the previous element:

Each of the random values for the other participants is then encrypted with the public key of the given participant. Bob then computes the value of ys in order to create the ring (the result of the ring must equal v). He will then inverse this value to produce the equivalent private key (xs). Bob now releases the overall signature, and the random x values, along with the computed secret key. To check the signature, the receive just computes the ring and checks that the result matches the sent signature.

The basic method are:

1. Generate encryption with k=Hash(message).

2. Generate a random value (u).

3. Encrypt u to give v=Ek(u).

4. For each person (apart from the sender):

• 4.1 Calculate e=si^{Pi} (mod Ni) and where si is the random number generated for the secret key of the ith party, and Pi is the public key of the party.
• 4.2 Calculate v=v⊕e

5. For the signed party (z), calculate sz=(v⊕u)^d (mod Nz) and where d is the secret key of the signing party.

We will end up with the signature (v=Ek(u)), and which completes the ring.

The basic method involves creating Bob creating fake private keys for the other people in the ring:

The verification of the ring is then:

The major problem with the Bitcoin network is that the amount of a transaction and the sender and receiver of the funds are not private, and someone who knows someone’s address can trace their transactions. This is the case because the blockchain needs to check that the sender has enough funds to pay the recipient. Thus many cryptocurrencies are looking for ways of anonymising the transaction. Ethereum, for example, uses zk-Snarks to hide identities.

One method of preserving identity was proposed by Rivest et al and used RSA encryption. Unfortunately, it is not efficient for modern systems, thus, Greg Maxwell’s defined an elliptic curve method as a new way of creating the ring signature: the Borromean ring signature [paper].

The cryptocurrency Monero then adopted the method for anonymising transactions but has since migrated to a new method: Multi-layered Linkable Spontaneous Anonymous Group signature. This method hides the transaction amount and the identity of the payer and recipient [paper]. It is now known as RingCT (Ring Confidential Transactions), and was rolled out in January 2017 and mandatory for all transactions from September 2017.

TRCT provides a roadmap for the integration of tracing keys and the segmentation of rights of access. It is unlikely that we will see the implementation of this method is Monero anytime soon, but it could be applied to new methods. It is only interesting to see it applied to permissioned blockchains, and it could be useful in banking applications which require privacy but traceability.

[1] Duan, J., Wang, L., Wang, W., & Gu, L. (2023). TRCT: A Traceable Anonymous Transaction Protocol for Blockchain. IEEE Transactions on Information Forensics and Security.

Blog: https://medium.com/asecuritysite-when-bob-met-alice/did-you-buy-a-ring-doorbell-from-2015-to-2019-then-you-could-get-compensation-c8434916b2da 

I know the title sounds like one of those adverts that say,

Before COVID-19, I used to demonstrate live at conferences the Ring doorbell and showcase weak practices. The video wasn’t encrypted at all, and where I could easily view it. Along with this, user credentials were left unencrypted. But, after we went into lockdown, it was not so easy to give practical demonstrations, so I’ve not done a demo for a few years. But you will be glad to know that I’m all set up for hacks on electrical sockets, doorbells, kettles, door locks, and many other things, so if your company wants a demo, please get in contact.

Overall, I have found that for the balance between useability/ease of setup, and security, most companies go for useability/ease of setup, as they know their users are often not that technical. Now, it has been shown that there are thousands of customers of the Ring doorbell that have been affected by cyberattacks.

For this, Amazon will have to pay out $5.8 million in payments to around 55,000 customers for its weak data security practices. For this, it has been well known that some employees at Amazon had been spying on user videos:

It was also found that there was no encryption on the video streams and that credentials were sent in a plaintext format. There were also attacks on previously breached passwords or in using repeated attempts at guessing credentials. Normally, this type of practice would be defended with a lock-out policy or by monitoring password usage, and which was weakly implemented. The case was brought by the FTC (Federal Trade Commission) in a federal court [here]:

It is thought that 1,250 devices were breached with passwords, that the live stream was compromised, and that there were at least 20 cases that involved a breach of over one month. The suit outlines cases involving screaming obscenities, demanding ransoms, and threatening murder and sexual assault [here], and covers those who bought Ring doorbells between 2015 and 2019 — even if they have not been hacked. These will be used to pay for refunds for the doorbell and requires that Amazon delete all the video information gathered and any user credentials. Amazon will also have to inform the FTC about future incidents.

Along with this, the FTC reported that Amazon failed to encrypt video streams from 2016 and 2020, along with no encryption for user credentials and details, and failed to get user consent for the viewing of video streams. Also, they failed to provide adequate training for their staff in supporting the Ring doorbell. In 2021, though, Amazon finally implemented encryption and proactive monitoring on the product [here]:

Alongside this, Amazon will also have to pay $25 million for Alexa with the FTC Act and Children’s Online Privacy Protection Act by retaining children’s information without parental permission. Amazon will also be required to stop using geolocation, voice information, and children’s voice information for any product improvement purposes.

When ease of use and usability are placed before cybersecurity, there’s likely to be a storm brewing. I like Apple devices, as they seem to be able to span both sides of this. My demos for Ring, though, don’t work anymore, but I’ve got many other things to showcase.

Overall, one bad product implementation can taint a whole brand. Amazon needs to watch that its Ring doorbell doesn’t give the company a bad name, as it has its e-commerce and cloud infrastructure to look after.

A guest talk on  Quantum Computing and Impact On Public Key Encryption  by Professor Alan Woodward.

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.

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]:

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:

A sample run is [here]:

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):

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]:

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).

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]:

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.

[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.

Related page: https://medium.com/asecuritysite-when-bob-met-alice/clocks-latex-byzantine-generals-and-post-quantum-crypto-meet-the-amazing-leslie-b-lamport-b2ade4b590d7

Demo: https://asecuritysite.com/hashsig/lamport 

Introduction

I write this article in Medium and with its limited text editor, but I really would love to write it in LaTeX. Before the monopoly of Microsoft Word, there were document mark-up systems such as Lotus Manuscript, and where we had a basic editor to produce publishing-ready content. The GUI came along, and all the back-end stuff was pushed away from the user. For many, this is fine, but for those whose output is focused on sharing and dissemination of research, it is often the only way to work.

In research, LaTeX is King and is a fully formed method of laying out — and sharing — research outputs. In the past few years, we have published over 100 research papers, and not one of them has been created in Microsoft Word. And for this, I thank Leslie Lamport.

In fact, ask our kids about Newton, Faraday or Einstein, and they could probably tell you something about them. But ask them about Whitfield Diffie, Shafi Goldwasser, or Leslie B Lamport, and they would probably look quizzical? Their future world, though, is probably going to be built around some of the amazing minds that built the most amazing structure ever created … The Internet.

So, I am so privileged to be an academic researcher. For me, teaching, innovation and research go hand-in-hand, and where the things I research into gives me ideas for innovation, and which I can then integrate these things into my teaching. The continual probing of questions from students also pushes me to think differently about things, and so the cycle goes on. But, we are all just building on the shoulders of true giants, and there are few larger giants than Leslie Lamport — the creator of LaTeX.

For me, every time I open up a LaTeX document, I think of the work he did on creating LaTeX, and which makes my research work so much more productive. If I was still stuck with Microsoft Office for research, I would spend half of my time in that horrible equation editor, or in trying to integrate the references into the required format, or in formatting Header 1 and Header 2 to have a six-point spacing underneath. So, for me, the contest between LaTeX and Microsoft Word is a knock-out in the first round.

And one of the great things about Leslie is that his work is strongly academic — and which provides foundations for others to build on. For this, he did a great deal on the ordering of task synchronisation, in state theory, cryptography signatures, and fault tolerance.

I really can say enough about how much LaTeX — created in 1984 — helps my work. I am writing a few books just now, and it allows me to lay out the books in the way that I want to deliver the content. There’s no need for a further mark-up, as I work on the output that the reader will see. But the true genius of LaTeX is the way that teams can work on a paper, and where there can be async to GitHub and where version control is then embedded.

Overall we use Overleaf, but we’re not tie-in to that, and can move to any editor we want. But the process is just so much better than Microsoft Word, especially when creating a thesis. Word is really just the same old package it was in the 1990s, and still hides lots away, and which makes it really difficult to create content which can easily be changed for its layout. With LaTeX, you create the content and can then apply whatever style you want.

Many in the research community think that the quality measure of a paper is the impact factor of the journal that it is submitted to, or in the amount of maths that it contains. But, in the end, it is the impact of the paper, and how it changes thinking. For Leslie, in 1978, his paper on clocks changed our scientific world and is one of the most cited papers in computer science [here]:

In 1981, Leslie B Lamport defined the Byzantine Generals Problem [here]:

And in a research world where you can have 100s of references in a paper, Leslie only used four (and which would probably not be accepted these days for having so few references):

Within this paper, the generals of a Byzantine army have to agree to their battle plan, in the face of adversaries passing in order information. In the end, we aim to create a way of passing messages where if at least two out of three of the generals are honest, we will end up with the correct battle plan. So why don’t we build computer systems like this, and where we support failures in parts of the system, or where parts of the system may be taken over for malicious purposes? And the answer is … no reason, it just that we are stuck with our 1970s viewpoint of the computing world, and everything works perfectly, and security is someone else’s problem to fix.

So, we need a system where we create a number of trusted nodes to perform a computation, and then an election process at the end to see if we have a consensus for a result. If we have three generals (Bob, Alice and Eve), we need two of them to be honest, which means we can cope with one of our generals turning bad:

In this case, Eve could try and sway Trent by sending the wrong command, but Bob and Alice will build a better consensus, and so Trent will go with them. The work can then be defined as MPC (Multiparty Computation) and where we have multiple nodes getting involved to produce the final result. In many cases, this result could just be as simple as a Yes or No, and as to whether a Bitcoin transaction is real or fake, or whether an IoT device has a certain voltage reading.

Sometime soon we perhaps need to wean ourselves of our existing public key methods and look to techniques that are more challenging for quantum computers. With the implementation of Shor’s algorithm [here] on quantum computers, we will see our RSA and Elliptic Curve methods being replaced by methods which are quantum robust. One method is the Lamport signature method and which was created by Leslie B. Lamport in 1979 [here]:

At the current time, it is thought to be a quantum robust technique for signing messages. When we sign a message we take its hash and then encrypt it with our private key. The public key is then used to prove it and will prove that we signed it with our private key. The Lamport signature uses 512 random hashes for the private key, and which are split into Set A and Set B. The public key is the hash of each of these values. The size of the private key is 16KB (2×256×256 bits) and the public key size is also 16 KB (512 hashes with each of 256 bits).

The basic method of creating a Lamport hash signature is:

• We create two data sets with 256 random 256-bit numbers (Set A and Set B). These are the private key (512 values).
• Next, we take the hash of each of the random numbers. This will give 512 hashes and will be the public key.
• We then hash the message using SHA-256, and then test each bit of the hash (0 … 255). If it is a 0, we use the ith number in Set A, else we use the ith number from Set B.
• The signature is then 256 random numbers (taken from either Set A or Set B) and the public key is the 512 hashes (of Set A and Set B).

This process is illustrated below:

We can use the Lamport method for one-time signing, but, in its core format, we would need a new public key for each signing. The major problem with Lamport is thus that we can only sign once with each public key. We can overcome this, though, by creating a hash tree which is a merger of many public keys into a single root. A sample run which just shows the first few private keys and the first public keys:

In this case, we take the random number and then convert it to a string. So the SHA-256 signature of “6f74f11f20953dc91af94e15…0db03ebdf06d59556c” is 7f2c9414db83444c586c…49d9b4f03e9ba9. If can be seen that the hash of the message (“The quick brown fox jumps over the lazy dog”) has a hex D value at the start, which is 1101 in binary, and we see we take from SetB [0], SetB [1], SetA [2] and SetB [3]. A demonstration is given here.

The Internet we have now built on the foundations that Leslie applied. On 18 March 2013, he received the AM Turing Award (which is like a Nobel Prize in Computer Science). At the time, Bill Gates said:

Basically, much of our computing world is still using the amazing foundation that was created in the 1970s and 1980s. We tip our hats to Diffie Hellman, Shafi Goldwasser, Ralph Merkle, Ron Rivest, Adi Shamir, and, of course, Leslie B Lamport. As a note, that while Leslie’s paper on Clocks is cited over 12,000 times, the Diffie Hellman paper is cited over 19,300 times:

We really should be integrating computer science into our school curriculum, and show that it has equal standing to physics, biology and chemistry, and it will shape our future world as much as the others. Why not teach kids about public-key cryptography in the same way that we talk about Newton?

Related material

• Main page: https://billatnapier.medium.com/cryptography-fundamentals-8-rsa-rivest-shamir-and-adleman-445b91932bd0
• RSA: https://asecuritysite.com/rsa 

Introduction

In August 1977, The Stranglers were in the music charts with “Something Better Change” and something really was changing, and it was something that would change the world forever. This was the month that Martin Gardner in his Scientific American column, posted a challenge of a method that has stood the test of time: RSA. It related to the work of R(ivest), A(dleman) and S(hamir) and was a puzzle on their discovery of a method which allowed two keys to be created, where one could encrypt and the other to decrypt. Their work had been based on a proposal from Whitfield Diffie and Martin Hellman on trapdoor functions that could be used to create the key pair.

In order to explain the RSA concept, Martin’s provided a background the Diffie-Hellman method for which he outlined:

Overall the Diffie-Hellman method has had a good run, but it has struggled in recent years to keep up with the processing power for computers, and the millions of years of running is not quite the case in the modern area, and where the original ciphers could now easily be broken with the simplest of computers within minutes.

With the RSA method, Martin Gardner outlined:

On receipt the requesters eventually (it took over four months in many cases) received a precious piece of history (Figure \ref{fig03}).

It seems unbelievable these days, but the original methods were based on two 63-digit prime numbers that would be multiplied to create a 126-digit value:

A 256-bit number, at its maximum, generates 78-digits:

Web: https://asecuritysite.com/encryption/keys3

The 40 quadrillion years has not quite happened, and where 512-bit keys are easily broken in Cloud. If you are interested, here is a 512-bit integer value and which has 148 digits, such as:

web: http://asecuritysite.com/encryption/random2

The search for prime numbers, too, has been progressive since 1977, and by 2014, the world discovered a 17,425,170-digit prime number. The finding of prime numbers make the finding of them in the RSA method must easier.

So the RSA method has been under attack for years, from both discovering prime numbers and also in factorizing. Along with this computing power has increased massively. If think that 40 years that have passed, and take a quick assumption that computing power doubles every year then we get:

and if we get a GPU card with 4,000 processors, we take it to less than a year, and we get of few of them today into a cluster, and we crack it within one day! The FREAK vulnerability was actually caused by the limiting of RSA keys, due to US Export controls, to 512-bits.

The factorising of prime numbers too has generated methods which can quickly find the prime number factors 

Once Martin had published the article, the requests for the article came rushing in, especially as the paper had not yet appeared in the Communication of the ACM. 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.

Why did it take so long to get the paper published and also to send them out? Well the RSA method caused significant problems within the US defence agencies. This was highlighted in a letter sent from J.A.Meyer to the IEEE Information Theory Group on a viewpoint that cryptography could be violating the 1954 Munitions Control Act, the Arms Export Control Act, and the International Traffic in Arms Regulations (ITAR), and could thus be viewed equivalent to nuclear weapons. In even went on to say that:

The main focus of the letter was that any work related to cryptography would have to be cleared by the NSA before publication. In fact, the letter itself had been written by Joseph A Meyer, an employee of the NSA.

Joseph had already been embroiled in controversy with a proposal to fit a tracking device to the 20 million US citizens who had been associated with crime. The tag would then be used to monitor the location of the “subscriber”, and to detect when they broke a curfew or committed a crime. In this modern era of GPS tracking of everyone’s phones, Joseph’s dream has actually become a reality, but now everyone is monitored.

The RSA team thus had a major dilemma, as many of the requests for the paper come from outside the US. Martin Hellman, who was a co-author of the Diffie-Hellman method, had already had problems with ITAR, and even decided to present thep aper himself in 1977 at Cornell University rather than the practice of letting his PhD students present the work.

His thinking was that the court case would be lengthy, and that it would damage his PhD student’s studies (Ralph Merkle and Steve Pohlig), and so he stood up for academic freedoms. Initially the students wanted to present their work, but their families did not think it a good idea. Eventually though, Ralph and Steve stood beside Hellman on the stage to present the paper, but did not utter a word.

With this stance the cryptographers held ground, and hoped that a stated exemption on published work within ITAR would see them through. The worry, though, did delay the paper being published, and for the posting of the article. In reply to Meyer’s letter, the IEEE stood its ground on their publications being free of export licence controls, with the burden of permissions placed on the authors:

and then additional response from the IEEE saying they put in place safeguards for the publishing of material.

The scope of the impact of RSA was perhaps not quite known at the time with Len Adleman stating:

In fact, Adleman has said that he did not want his name on the paper, as he had done little work on it, but he did insist that his name went last. Often papers, too, have an alphabet order, and if so the method could have been known as the ARS method … not the kind of thing that you would want to say to audiences on a regular basis.

Within cryptography we typically use non-negative integer values, and perform integer operations. The challenge in public key encryption is to find a method which is computationally difficult for a computer to solve, if it does not know a given secret (normally the private key). One such problem is the difficulty in factorizing a value made up of the multiplication of two large prime numbers. In RSA, we take two large prime numbers — typically at least 512 bits long — and then multiply these together to create a modulus value, (N) (often at least 1,024 bits long). From this, we then derive a public exponent (e) and a modulus. The modulus N is thus determine by multiplying the two prime numbers (p and q):

The core challenge here is that it should be extremely difficult (and costly) to determine the two prime numbers which make up N. Next we select the value of our encryption key value for the public key (e). This is selected so that N and e do not share any factors: gcd(e,PHI)=1, and where 

PHI = (p-1)(q-1)

This is known as Euler’s totient function.

The most typical value we use for e is 65,537 (0x10001). To produce a cipher (C), we convert our message into the form of an integer (M) and then use e and N to give:

To decrypt this, we take the cipher (C), and recover the message value using the decryption exponent (d) and the modulus (N):

To make RSA work, we then need to calculate the private exponent (d) to obey:

and where phi is:

We determine d by determining the inverse of e modulus phi:

So let’s take p=11 and q=7, and pick e of 3. N will be:

N=p.q = 77

PHI is 6x10=60

We can’t pick e of 3 or 5, so we will pick e=7. Now we compute the decryption exponent of

d = e^{-1} mod (PHI)

>>> pow(7,-1,60) 43

If we select a message of 19, we get a cipher of:

C=19⁷ (mod 77) = 68

Now to decrypt:

M= 68⁴³ (mod 77) = 19

Our public key is then (e,N) and the private key is (d,N). The usage of the (mod N) operation is the magic that makes this work. Unfortunately, the RSA method has suffered from performance issues as we have increased the size of the prime numbers used. Thus, if researchers can crack a modulus of 1,024 bits, they will factorize the two 512-bit prime numbers used. At the current time, a public modulus of 2,048 bits is recommended. So while a modulus of this size is acceptable within a powerful computer, devices which have limited CPU resources often struggle in creating the keys, and in the encryption and decryption process.

With the mathematical operations involved, RSA is hardly ever used for core encryption, as symmetric key methods are much more efficient in their implementation. But it is fairly efficient when dealing with relatively small data sizes, such as for a symmetric key (typically only 128 bits or 256 bits long). For this, Alice might protect a symmetric key with her public key, and whenever she needs to use it, she will decrypt it with her private key. Another area where we use RSA is to take a hash of a message, and then encrypt this with the private key. As the hash is relatively small (such as 128 bits, 160 bits or 256-bits), it is relatively efficient on the use of the computing resources.

Where public key encryption methods come in most use is within creating digital signatures, and where Bob can take a hash of a message, and then encrypt this hash with his private key. Alice can then also take a hash of the received message, and decrypt Bob’s encrypted hash with his public key, and compare the values produced. If they match, she determines that it was Bob who sent the message and that it has not been changed by anyone. 

In Figure \ref{fig_trust03} we see that Bob has a key pair (a public key and a private key). He takes a hash of the message and encrypts with his private key, and then appends this to the message. This and then message will be encrypted by the symmetric key that Bob and Alice share (typically this is either a long-term shared key, or has just been negotiated through a hand-shake). When she receives the ciphered message, she decrypts it with the shared symmetric key, and then takes her own hash of the message. She also decrypts the encrypted hash using Bob’s public key, and then compares the hashes. As the public key and the private key work together, only the signing by Bob’s private key will reveal the hash with his public key. Alice can then tell that the message has not been changed — as the hash would change if Eve has modified it — and that it was produced by Bob (and not by Eve pretending to be Bob). Obviously, we now have a problem in how we get Bob’s public key. An important element here, is that they have to find a way for Bob to send Alice her public key in a trusted way, so that Eve cannot intercept it, and change the keys. For this, we introduce Trent, and who is trusted by Bob and Alice to prove their keys. For this Trent signs the public key of Bob with his private key, and then Alice uses Trent’s public key to prove Bob’s public key.

For a few decades, RSA has been the main method in supporting public key encryption. We often use it when we connect to a secure Web site, and where the RSA method is used to prove the identity of the Web site. In this case the RSA public key of the site is presented to the user in the form of a digital certificate — and which is signed by a trusted source. The Web site can then prove its identity by signing a hash of the data with its private key, and the client can check this. A typical size of the public modulus is now 2,048 bits (created by two 1,024 bit prime numbers), and with some sites supporting 4,096 bits. So while desktop computers have the processing power to cope with these large numbers, less able devices (such as for low processing powered IoT — Internet of Things — devices) will often struggle to perform the necessary calculations.

So let’s take a simple implementation of RSA key generation, encryption and decryption. In this case the code is:

Web: https://asecuritysite.com/encryption/rsa12

In this case, we generate two random prime numbers ($p$ and $q$) for a given number of bits. The more bits we use, the more secure the method is likely to be, as an increase in the number of bits increases the number of prime numbers that can be searched for. Once we have these, we then determine the public modulus ($N$) by multiplying the prime numbers together. The difficulty of the problem is then factorizing this modulus back into the prime numbers. If we have the public modulus, it is fairly simple to then find the decryption exponent value. In most modern examples of RSA, we select a public exponent value ($e$) of 65,537, and so our encryption key becomes $(65,537,N)$. The decryption exponent ($d$) is then the inverse of $e \pmod {\phi}$ (and where $\phi=(p-1)(q-1)$).

A test run using 60-bit prime numbers is:

RSA has been around for over 46 years, and is still going strong. It can encrypt and it can sign. While the prime numbers involved has got larger, and it needs to have padding applied, it is still one of the best public key methods around, and well used on the Web.

Cybersecurity Cloud Lesson 1 rule book in key management for companies:

1. Your encryption keys are the keys to your castle. So protect them with your life!
2. Your enemy is you! The main threat is insiders, so beware of yourself and others in your company.
3. Beware of those that you trust and who you partner with. They can be your enemies, too.
4. For sensitive data, try not to let Amazon or Microsoft manage your keys.
5. 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.
6. If you are audited for your keys, you may need an on-premise HSM to link to your Cloud instance.
7. 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.
8. Log the usage of your keys everywhere and link to people, roles, services and applications. Log, log and log some more.
9. Watch out for those keys being deleted … it is one of the easiest hacks for a disgruntled employee to perform.
10. Watch out for key wrapping from your insiders and your key exports. See Point 1.
11. Use a tiered alerting system which escalates the severity of the key usage, but make sure you keep those logs.
12. Use envelope encryption.
13. Test, test, and test some more.
14. Audit, audit, and audit. On a daily basis, if nescessary.
15. Test those encrypted backups.
16. We all make mistakes. If you delete a key, please say, as we have 60 days to undelete it.
17. Use key rotation wherever possible.
18. Just because ECDSA and EdDSA sound all fancy and brand new doesn’t mean that RSA is not an option.
19. RSA is still your friend. Forget about those doom sayers on quantum cracking.
20. MD5 and SHA-1 should never, ever, be seen.
21. 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.

Demos

These are:

• Quadratic residues: https://asecuritysite.com/primes/q_res
• Jacobi symbol: https://asecuritysite.com/primes/jac
• Jacobi and Legendre symbol: https://asecuritysite.com/primes/jacobi

Introduction

Remember at school that class where the teacher taught you about how to square something? It was great, and where we loved to take the square of 3 and get 9, and the square of 5 gave us 25. But, in the next lesson, we came back to earth with a bump, as it was time for the nasty little square root. Now, we have to find two numbers which when multiplied together, gave us 121, or 196. Luckily, there was a convenient button on the calculator that give us our quick answer. In the time before calculators, though, working out more complex square roots involved tables of logarithms. And, so, in this podcast, I will outline a difficult problem … find a square root in a modulo n world … aka quadratic residues.

In cryptography, we look for hard problems to solve. For this, we can create a backdoor into the problem and solve the problem. With discrete logarithms, we have a hard problem of:

Y=g^x (mod p)

and where it is difficult to determine x, even though we know g, Y and p, but as long as the prime number if large enough. Another hard problem is used in the RSA public key method, and this involves the difficulty in factorization at modulus (N) which is made up of two prime numbers. 

Another hard problem is quadratic residues modulus n, and uses the form of:

x²=a (mod p)

and where we must find a value of x which results in a value of a (mod p). If a solution exists, the value of a is a quadratic residue (mod n). 

In modular arithmetic, this operation is equivalent to a square root of a number (and where x is the modular square root of a modulo p). In the following, we will try and solve for the value of x, and also generate the Legendre symbol value.

For example, if we have a=969 and p=1223, we get:

Solve x²=968 (mod 1223) [Ans: 453] Try!

and:

Solve x²=1203 (mod 1223) [Ans: 375] Try!

Thus 968 and 1203 are quadratic residues modulo 1223.

The form of x²=a (mod p) is not always solvable. For example, if we have a=209 and p=1223 , we get:

x²=209 (mod 1223)

Also, if a shares a factor with p it is also not solvable. For example:

x²=39 (mod 13)

will return a zero value for x.

If we take a value of p=53, we get the following values [here]:

A sample run of the code gives:

In this case, we see that 10 is a possible quadratic residue for a p of 53. The solution is thus:

10²=47(mod 53)

You can see a demonstration here and here are some examples:

• Solve x²=12 (mod 13) [Ans: 8] Try!
• Solve x²=968 (mod 1223) [Ans: 453] Try!
• Solve x²=1203 (mod 1223) [Ans: 375] Try!
• Solve x²=47 (mod 53) [Ans: 10] Try!
• Solve x²=209 (mod 1223) [No solution!] Try!
• Solve x²=888 (mod 1223) [No solution!] Try!
• Solve x²=39 (mod 13) [No solution!] Try!

In science, it is difficult to avoid Adrien-Marie Legendre, as there are so many things named after him: Fourier–Legendre series; Gauss–Legendre algorithm; Legendre chi function; Legendre duplication formula; Legendre–Papoulis filter; Legendre form; Legendre polynomials; Legendre sieve; Legendre symbol; Legendre transformation; Legendre wavelet; Legendre–Clebsch condition; Legendre–Fenchel transformation; Legendre’s constant; Legendrian knot; and Gamma function–Legendre formula.

And, so, where does Legedre help with your online security? Well, you will find his method used in elliptic curve methods, which are used to protect your online identity, and the security of the communications that you have with this Web page. So, let’s look at the Legendre Symbol.

For this, we turn to Legendre who, in 1798, defined the Legendre symbol. In the following, we will try and solve for the value of x, and also generate the Legendre symbol value [link]:

Solve x²=12 (mod 13)

With his method, we can determine that the answer is 8, as 64 (mod 13) is 12. Some sample code is [here]:

A quadratic residue relates to the solving of the form: y=x² (mod n), and where we need to find values of y for different values of x and for a given modulus (n). For n=11, we get Z∗p={1, 3, 4, 5, 9}. This is because, 1² (mod11)=1, 2² (mod11)=4, 3² (mod11)=9, 4² (mod11)=5, 5² (mod11)=3, 6² (mod11)=3, 7² (mod11)=5, 8² (mod11)=9, 9² (mod11)=4, and 10² (mod11)=1.

To find the quadratic residues for a given modulus, we can use the Jacobi symbol is:

and is defined as:

The legendre_symbol returns:

• 1. When a is a quadratic residue of p.
• -1. When a is a quadratic nonresidue of p.
• 0. When a shares a factor of p.

The Jacobi symbol was defined by Carl Gustav Jacob Jacobi as a generalized form of the Legendre symbol.

While we have a trivial example here, we can use it for more complex ones, such as finding a point on the elliptic curve [here]. A sample run is:

The code for this is [here]:

Please note, I slippled up a little in the podcast, and where the army size if 187,000. I have updated below.

Web page: https://billatnapier.medium.com/cryptography-fundamentals-6-chinese-remainder-theory-ctr-2d1874943f15

And so a large army met. The general asks the collected troops to arrange themselves into groups of 50. He counts that there are four troops left without a group. He then asks for groups of 60, and there are 14 left, and finally, he asks for groups of 70, and there are 24 left. The general stands up and tells the army that they are 201,554 strong. So how did the general do it?

>>> army%50

4

>>> army%60

14

>>> army%70

24

>>> print (army)

187000

Solution: https://asecuritysite.com/principles_pub/crt02?val1=4,14,24&val2=50,60,70

The Chinese remainder theorem was first published by Chinese mathematician Sun Tzu. It determines a number x so that, when divided by some given divisors, leaves given remainders. As public key encryption typically involves this type of operation, CRT is well set up to help to crack encrypted messages. So what value will x equal in the following [Soln]:

The answer is 23, as 23 divided by 3 gives 21 remainder 2, 23 divided by 5 gives 4 remainder 3, and 23 divided by 7 gives 3 remainder 2.

If we capture enough RSA encrypted messages with the same e value and different modulus values (N), we can crack the message using the Chinese Remainder Theorem (CRT). For example, if we have an e value of 3 we just need to capture three cipher messages to be able to recover the message.

In this case, we will use the following (where p1 and q1 generate N1, p2 and q2 generate N2 and p3 and q3 generate N3):

The run then gives:

The equations we have to solve are then:

If we now use Chinese Remainder Theorem we get a result of:

Result (M^e) is: 188,1676,377,431,587,319,857,436,861,793,600,904

And then we just use: 10^(log10(M^e)/e)

and recover the message of 1234567891234

Try here.

A more detailed example is [here]:

We can also use:

Well, in RSA, we can use Chinese Remainder Theory to simplify the decryption process. We will cover this in more detail when we look at RSA encryption. For now, all we can say that for RSA keys we also generate values of dQ, dP and InvQ to use CRT to speed up decryption.

CRT is a widely used cracking technique in cryptoanalysis. Werner Schindler [here] defined a timing attack on RSA which involves a factorization on the RSA modulus if CRT has been used. The work goes back to 1996 when Arjen Lenstra defined an attack against an optimization (called the CRT). If a fault was generated in calculating a signature (using RSA-CRT optimization), the attacker could recover the associated private key from a signature. This is known as the “RSA-CRT key leak”.

Many systems have been immune from this attack as TLS did not use an RSA signature. Unfortunately, the forward security option in TLS is now being recommended, and this has re-introduced the problem.

Researchers at Red Hat [here] also now found many Web sites which were not hardened against this type of attack and found quite a few with RSA-CRT key leaks (none of which were code repositories). They found that the private key of a Web site can be leaked to the intruder, who can then decode all of the encrypted communications with the site and also impersonate it.

Forward secrecy is used with a key-exchange method and uses a session key which derives itself from a given set of long-term keys and which will not reveal the session key even in the long-term keys are breached.

There are two ways to defend against this attack. The first is to make sure that e always exceeds the copies of messages that can be copied, and the other is to pad messages with random bits. In most applications, now e is 65,537.

This podcast will outline a few building blocks of cryptography: GCD (Greatest common divisor), extended GCD and group generators. These you will find in many related cryptography papers, and any weaknesses in these can cause significant problems to the overall security of a method. 

A fairly simple concept that is used within public key encryption is the greatest common divisor (GCD). With this, we take two integer values and determine the largest factor that they are. Overall, every non-prime number is made up of the multiplication of prime numbers. For example:

32,128 = 2 x 2 x 2 x 2 x 2 x 2 x 2 x 251

36,281 = 7 x 71 x 73

So, the GCD of 56 and 42 is 14, as both of the values can be factorized into 4 x 14 and 3x14, respectively. https://asecuritysite.com/principles_pub/gcd

Normally we use this function to find values which do not share a factor, as we will see when selecting the public exponent (e) in the RSA method. The method to determine the GCD is fairly simple, and where we take two values (a and b) and use the modulus operation to find the GCD:

A sample run shows that 679 and 99 do not share any factors:

Web: https://asecuritysite.com/encryption/gcd

GCD is the greatest common divisor. For two integers (x and y), the extended GCD method solves ax+by=v for a and b, and where v=gcd(x,y). One example of using the Extended GCD method is to determine the modulo inverse of a value (the inverse value of n (mod p) so that:

n⋅n^{−1}=1 (mod p) ).

30a+20b=gcd(30,20). Soln: a=1, b=−1. Try!

35a+15b=gcd(35,15) . Soln: a=1, b=−2. Try!

In reading about cryptography, have you ever come across the term of a cyclic group G of order p and with a generator g? With a discrete log mapping, we map x to Y with

Y=g^x (mod p)

where we have a generator value (g) and a prime number p. The challenge is that even though we know Y, g and p, it is extremely difficult to determine the x value if we use a large prime number.

But can we use any value of g, and should it be as large as possible? The answer to both of these questions is no. If we select a prime number of 11, and then select g values of 2, 3, 4 …10, and then calculate the results we get [spreadsheet]:

Now look at g=2 and p=11, for 2¹ (mod 11) we get 2, 2² (mod 11) we get 4, 2³ (mod 11) we get 8, and so on. As we see {1,2,3,4,5,6,7,8,9,10} gives {2,4,8,5,10,9,7,3,6,1}, and where all the input values give a 1-to-1 mapping to another value in the group. But if we try g=3 and p=11, we get x=1 gives 3, and for x=6 also gives 3. The mapping is now {1,2,3,4,5,6,7,8,9,10} to {3,9,5,4,1,3,9,5,4,1}, and so we are not using the full range, and where there would be a confusing for mapping back to our original value. 

But, in order to demonstrate the principle, I have done this in a long-handed way, so how do I find out all the possible values of G for a given prime number (p)? Well, here’s a nice simple method in Python that I created to test up to p):

A sample run with an unsafe value is:

and where the only output value is 1, 3 and 9. For a safe value, we get:

So, how does this work in practice? Well, rather than picking the prime number and then finding a g value which will work, we typically pick the g value we want, such as for g=2, g=3 or g=5, and then find a prime number of a given size to work with that value. This will slow down the process, as we might have to pick a few prime numbers before we find one that will work. An example command in OpenSSL to generate the Diffie-Hellman parameters for g=3 and a 512-bit prime number is:

https://asecuritysite.com/openssl/dh

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.

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.

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.

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).

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.

The speed of the transactions and the ease of access to digital currency could enable economic risks

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.

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.

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]:

The enablement of a CBDC brings many technical challenges.

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.

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).

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.

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.

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.

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.

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.

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.

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.

[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.

Scott Helme is a Security Researcher, Entrepreneur and International Speaker. He is the creator of the Report URI and Security Headers Web site. More details:

https://scotthelme.co.uk/

I will bet you, that you have a memory of school where you had the “pleasure” or, most likely, the “nightmare” of performing long addition or long subtraction, and where you had carry overs between columns. The units carried over in the tens, the tens into the hundreds, and so on. And, then, you encountered long multiplication with those ever growing list of numbers. 

And, please forgive me, you progressed to long division, and you had that divisor dividing into your number and with the bar along the top, and where you put your result, and which those pesky remainders. “Oh, teacher, 61 divided by 9 is 6 remainder 7”. And, didn’t you love throwing away that remainder and just making the answer 6. But, in cryptography, the remainder is the bit we like, and we throw away the other bit. So for us, 61 mod 9 is 7. 

So, just take a pause now to just calm yourself for those memories. If you want to leave now, please do so, as we will revisit some of these memories, but, hopefully, we will make things a whole lot more simple.

To these additions and multiplications in an electronic circuit or some software code can take many operations. But, just imagine a world where you did not need to carry over values from one column to another, and even where all you had to add or multiply was a 0 and 1, life would be so much easier, and these school nightmares would end for you, and life would be so much happier for your kids in learning maths.

For example, if we have a binary adder we have 0+0=0, 1+0=1 and 1+1=0. As we see a simple binary adder just throws away that pesky carry. If we add 1+0+1+1+1+0, we see an answer of 0. But in our normal maths, to add 7+4+3+9+8 requires us to add up the units, and carry over in the 10s column. For simplifying things we turn to Évariste Galois.

Évariste Galois — who lived from 1811 to 1832 — died of duelling wounds at the age of 20 but left a great legacy. While he was a teenager, he worked on polynomials and laid down the principles of Galois’s theory — along with defining the concept of a finite field. 

As we have seen from the previous podcasts, we have values in a group, and then can operate on these to get another value in the group. So, if we have a group of 0 to 16, we can constrain our values with a (mod p) operation, and where p is a prime number. 

For example, if we use a prime number of 17, and we take a value of 2 and then raise that to the power of 5 and take the mod of 17, to get 15:

For all of the values from 0 to 16, we should (hopefully) get different mappings for the output. This will then allow us to reverse back by taking the inverse operation to the modulo power. This, as we have seen from a previous podcast, is to subtract one from the prime number (PHI=p-1), and perform an inverse of the base modulo of the prime number minus one. A simple Python program gives us the result for the inverse:

If we now multiply our result of 15 by 13 and take (mod 17), we magically get our value back again:

In this way, we aim to reverse our mathematical operations, and where there is no confusion about the reverse operation. 

Up to now, we have seen that we have operated on our normal arithmetic operations for the (mod p) such as add, subtract, multiply and divide, but we can simply things even more if we have a field which has 2^n elements, and where if n is 8, we can have 256 elements. 256 elements, for example, is the number of values we can have for a byte of data in a computer system. If so, we can convert our bit values of our integers into a polynomial, and then operate on them as polynomial operations, such as:

 (x²+1)+(x) = x²+x+1

This, as we will see, significantly reduces the complexity of our arithmetic operations, and rather than have complex circuits for adding (with carry overs) and multiplying (and where we end up with a value which has more bits than the inputs values), we constrain the calculation within our finite field. Along with this we then just need simple 1-bit adder or multiplication operation. So from complex adding and subtraction circuits in hardware or with software operations, we end up with simple bit operations. This vastly increases the speed of our cryptographic operation. 

This is a Galious field, and defined more generally as GF(p^n), and where p is a prime number. But, in most cases, p will be 2.

Within a finite field, we limit the number of possible values in a group. As we have seen this can be a prime number and where we get a group from 0 to p-1, and where we can perform our mathematic operations with the (mod p) operation. And, so, even though we have a finite field, we still want our maths to still operate as normal. The rules for every element in the group is:

• Commutative law. This is where (a+b) equals (b+a), and (a*b) equals (b*a).
• Associative law. This is where a.(b.c) is equal to b.(a.c).
• Distributive law. This is where a(b+c) is equal to ab+ac.
• Additive and Multiplicative Identifies (0 and 1). This means that a+0=a, and a times 1 is equal to a.
• Additive and Multiplicative Inverses. This means that there is an additive inverse where there is a value of b for a so that a+b=0. For multiplicative inverse, there is a value of b for a so that a.b=0.

Within our finite field in cryptography, we want all of these to work, so that we can reverse any operation that we can apply. 

Within a field, we can operate on values in the field using arithmetic operations. We can thus have an infinite field and where we could include all of the possible integers. A Galois field of GF(p^n) has p^n elements. Typically we use GF(2^n). And so GF(²⁴) has 16 values in the field. Let’s say we have GF(2^n) and have a number a∈{0,…,2^n−1}, we can represent it as a vector in the form of a polynomial:

a=a0+a_1 x+a_2 x²…a_{n−1} x^{n−1}

If we use a_n∈{0,1}, this is exactly the same as representing a binary number modulo 2^n. In this, x^n represents bit position n and a_n is the value of the bit at position x^n. If a bit is a zero at a given position, it will be not included in the polynomial equation.

First, let’s talk about modulo-2 operations. For this, an addition is:

0+0 = 0, 0+1 = 1, 1+0 = 1, 1+1 =0 (an EX-OR gate)

and for multiply we have:

0*0 = 0, 0*1 = 0, 1*0 = 0, 1*1 =1 (an AND gate)

So, 1011 can be represented by x³+x+1 and 1010 is represented as x³+x. We can then perform arithmetic operations on these polynomial values. So, to add two values of 1010+1100 we can represent this as (x³+x)+(x³+x²) and which is x²+x as we are using modulo 2 addition, and where x³+x³=0. With modulo 2 addition, 0+0=0, 0+1=1, 1+0=1, and 1+1=1.

An example of Galois Fields is within AES (Advanced Encryption Standard) and which uses a finite field GF(²⁸). With AES we operate on bytes (8 bits) in the form of b_7 b_6 b_5 b_4 b_3 b_2 b_1 b_0 and which are operated on a a polynomial of b_7x⁷+b_6x⁶+b_5x⁵+b_4x⁴+b_3x³+b_2x²+b_1x¹+b_0.

Oh, and we don’t have prime numbers any more, we have irreducible polynomials or primitive polynomial, and which are polynomials that cannot be factorized into polynomial factors.

https://asecuritysite.com/gf/gf2

This operatives in a similar way to our (mod p) operation, and where we can reduce a result into the group, and just take the remainder from a division.

Let’s take a few examples to illustrate this.

Example 1. For a=x²+x+1 (7–111b) and b=x+1 (3–011b) with a primitive of x⁴+x+1 (GF(2⁴)), for addition we get x² (4–100b), and for multiplication we get x3+1(9–1001b):

Add=(x²+x+1)+(x+1)=x²

Mult=(x²+x+1)×(x+1)=x³+x²+x²+x+x+1=x³+1

As we are using modulo 2 addition, then x+x=0 and x²+x²=0. As the power of the multiplication is not greater than x⁴ and above, there is no need to divide by the primitive polynomial. The following is a sample run:

For the division, we determine the inverse of b and then multiply by a. In this case we have a×b^{−1} = (x²+x+1)×(x³+x²+x)=x⁵+x⁴+x³+x⁴+x³+x²+x³+x²+x=x⁵+x³+x. As we have a higher power that the field, we now need to divide by the primitive (x⁴+x+1) and get the remainder:

This the result of the divide is then the remainder value of x³+x². You can try the example here.

Example 2. For a=x³ (8–1000b) and b=x²+1 (5–101b) with a primitive of x⁴+x+1 (GF(²⁴)), for addition we get x³+x²+1 (13–1101b), and for multiplication we get x³+x²+x (14–1110b).

Add=(x³)+(x²+1)=x³+x²+1

Mult=(x³)×(x²+1)=x⁵+x³

Now we divide x⁵+x³ by the primitive (x⁴+x+1) and get the remainder:

Thus the result of the multiplication is the remainder of x³+x²+x.

You can try the example here.

Example 3. For a=x³+1 (9–1001b) and b=x²+1 (5–101b) with a primitive of x⁴+x+1 (GF(2⁴)), for addition we get x³+x² (12–1100b), and for multiplication we get x³+x+1 (11–1011b).

Add=(x³+1)+(x²+1)=x³+x²

Mult=(x³+1)×(x²+1)=x⁵+x³+x²+1

Now we divide x⁵+x³+x²+1

by the primitive (x⁴+x+1) and get the remainder:

Thus the result of the multiplication is x³+x+1 (11- 1011b).

You can try the example here.

Example 4. For a=x²+x+1 (7–0111b) and b=x³+1 (5–1001b) with a primitive of x⁴+x+1 (GF(2⁴)), for addition we get x³+x²+x (14–1110b), and for multiplication we get x³+x (11–1010b).

You can try the example here.

Example 5. For a=x²+x (6–110b) and b=x⁴+x²+1 (21–10101b) with a primitive of x⁶+x⁵+x⁴+x³+x²+x (GF(2⁸)), for addition we get x⁴+1x+1 (19–10011b), and for multiplication we get x⁶+x⁵+x⁴+x³+x²+x.

With addition, there will be no need for the irreducible polynomial.

You can try the example here.

The code is:

Within polynomials, the prime number equivalents are known as irreducible, as they cannot be factored. I will come back to irreducible polynomials later in this series, but for now, you can read up on them at:

https://asecuritysite.com/gf/gf2

And, so, you made it to the end of this podcast. If you managed to understand everything here, you deserve a crypto medal. If not — for most — you should try and read over and eventually, it will sink in — slowly at first, and then you will get bits and pieces of knowledge, and eventually, it will make sense. This is one of the reasons I love cryptography — and teach and research the field — as, every day, I learn, but my learning was so much deeper once I really understand why we did all these complex-looking things, and to get behind the maths. I hope I have not given you nightmares of school and with long multiplication and division, but if I have, I can calm you that the maths we use in cryptography is so much simpler, and where you just have to know how to count just a 0 and a 1. Life is so much more relaxed in crypto space. 

In previous podcasts, I outlined the usage of discrete logarithms in the form of a=g^x (mod p). Unfortunately, we now need a relatively large prime number to make sure it is now possible to discover x from a, g and p. This slows down the creation of the discrete log value. One method which has been used to replace them in some applications is to use elliptic curve points. Later in this series, I will explain how elliptic curve cryptography actually works, but in this one, we will just look at the fundamentals of the elliptic curve points.

So what is a group in elliptic curve cryptography (ECC)? Well with this, we will map one group of points to another with a one-way function, and which should be difficult to reverse or find the method we have used to perform the mapping. As we will find, the basic operation is to either add two points in a group to create another point in the group or to double the point to get another point. With these simple operations, we should be able to perform point multiplication. The method of ECC was created independently by Neal Koblitz and Victor Miller.

So, how did I create this mapping? Well, a basic elliptic curve has the form of: 

y² = x³ + ax + b 

For y² = x³ + 7

If x=1, we get:

y² = 1+7

and where y is the square root of 8, which is 2.82. But, in cryptography, we only deal with integers, so we must modify this with a modular form of:

y² = x³ + ax + b (mod p)

For example, if a is zero, b is 7, and the prime is 11, we get:

y² = x³ + 7 (mod 11) 

The possible points are (2, 9) (2, 2) (3, 1) (3, 10) (4, 4) (4, 7) (5, 0) (6, 5) (6, 6) (7, 3) (7, 8). e can try it, and where:

9² (mod 11) = 4 and 2³+7 (mod 11) = 4

https://asecuritysite.com/ecc/ecc_pointsv?a0=0&a1=7&a2=11

As we see, not all the points for an x-coordinate value are possible. This then leads to the order, which is the number of valid x-axis points — which is 6 in this case. W

In ECC, we then add points together (P+Q) or double them 2.P and get a new point. With this, it is difficult to reverse back the addition or doubling and find the original point. 

For y²=x³+7 (mod 11)

The valid points are (2, 9) (2, 2) (3, 1) (3, 10) (4, 4) (4, 7) (5, 0) (6, 5) (6, 6) (7, 3) (7, 8). Now let’s take a point of (2,9) and add another point. So this, we get:

https://asecuritysite.com/ecc/ecc_points_add3?a0=2&a1=0&a2=7&a3=11

P1=(2,9) P2=(2,9) P1+P2=(5,0) P1=(2,9) P2=(3,1) P1+P2=(4,7) P1=(2,9) P2=(4,4) P1+P2=(3,10) P1=(2,9) P2=(6,5) P1+P2=(4,4) P1=(2,9) P2=(7,3) P1+P2=(3,1)

and so we see when we do a point add, we always get another point on the curve, but where it is difficult to reverse back to the points which resulted in this point.

So, can we multiply points in an efficient way? Let’s say we have G, and want to add it to itself n times. We could represent this as n.G. For this, Peter Montgomery created a method known as the Montgomery Ladder.

The basic method is:

For a=100 we have a binary value of 1100100:

• 1100100, thus we double the point (N=2G).
• 1100100, thus we double the point (N=4G).
• 1100100, thus we add the point (Q=4G), and then double the point (N=8G).
• 1100100, thus we double the point (N=16G).
• 1100100, thus we double the point (N=32G).
• 1100100, thus we add the point (Q=4G+32G=36G), and then double the point (N=64G).
• 1100100, thus we add the point (Q=36G+64G=100G), and then double the point (N=128G).

The result is then Q=4G+32G+64G=100G. Overall, the great advantage of this method is that we will always take the same time to compute the answer, no matter the size of the value of n. This is useful, as some cryptographic operations leak information from the time they take to compute the result. The only problem here is that the double point and point adding will have a different amount of time to compute than just the point double, and where Eve could determine if there was a 0 or a 1 in the value of n.

https://asecuritysite.com/ecc/ecc_kr2

So how is this used in public key encryption? We first pick a base point (G) on the elliptic curve. For our example, we could pick (2,9). Next, we then pick our private key (sk). Our public key is then pk=sk.G, and where G is added to itself sk times. Our private key is thus a scalar value, and our public key is an elliptic curve point. We use this in terms of digitally signing a message, and where the private key (sk) is used to create a digital signature, and the public key validates it. The most popular methods for this are ECDSA (Elliptic Curve Digital Signature Algorithm and EdDSA (Edward Digital Signature Algorithm). I will explain these more in a future podcast.

And, so, for our elliptic curve, we don’t always have a valid (x,y) point, but for our Weierstrass curve, sif we do, we end up with two y values for every x coordinate. With our points, we conduct two simple operations, a point addition and a point doubling. 

A fundamental element in cryptography is the mapping of one group to another and then being able to map back again. In this, there should be no confusion about the mapping and where it should be deterministic in the mapping — that is, no matter how many times we do it, we will always create the same mapping. Obviously, we can add some randomisation into the process, but with the same randomization, we always get the same mappings.

In the previous podcast, I showed how a group of A={1,2,3,4} will map to B={2,4,3,1} using a mapping of b=g^a (mod p). We see that every element of A has a one-to-one mapping from A to B. We then aim to have a mapping back from B to A, and recover the original value.

And, so, encryption (the mapping of A to B) can become a mathematical operation, and then where the decryption (the mapping of B to A) is basically just the reverse of our encryption process. And, so, remember those puzzles as a child.

Think of a number. Now add 10 and double it. Take away 7. Add 5, and half it. The answer is 9. Of course, this is a trick, and where we get:

[(2(x+10)-7+5)/2]-x =[(2x+20–7+5)]-x = [(2x+18)/2 ]-x= [x+9]-x = 9

For this, we are basically just reversing back the method we quote in the track. And so, for encryption, we could multiply by 9, and add 14 to get our cipher value. To decrypt, we would reverse the operations so that we subtract by 14 and then divide by 9. But, in cryptography, we have a finite field in our group and thus use the (mod p) operation to constrain our integers. Luckily, all our arithmetic operations still work if we use the modulo of a prime number.

Let’s try to add, with x=8 and y=12, and use a prime number of p=11.

If we do: (x+y) (mod p) is it the same as x (mod p) + y (mod p). And, so:

8 (mod 11) + 5 (mod 11) = 13 (mod 11) = 2

Now we will try:

(8+5) (mod 11) = 13 (mod 11) = 2

So can we now subtract b from the result?

2–5 (mod 11) = -3 (mod 11) = 8

Thus if we had an operation to add to values in a group and then reverse them. This goes for modulo multiply and then divide. 

Now let’s try to multiply and divide. For this, we will multiply our values by four modulo 5. This will get:

We ignore the zero for the set in A, as we will always get the same result. Thus we map {1,2,3,4} to {3,1,4,2}. Now we need to divide by three modulo 3. For this, we create the inverse mod of the value and then just multiply. This is basically:

a/b (mod p) = a* b^{-1} (mod p)

Basically, it is the value of x which will make this true:

b.x (mod p) = 1

This x is thus the multiplicative modular inverse value of b. So, let’s find the inverse of 3 (mod p):

Note that the pow(x,y,p) function is x^y (mod p). Thus to divide by 3 (mod 5), we multiply by 2. Let’s try it:

and so we get our original values back. Thus we use an inverse mod to reverse a modulo multiplication.

And, so, we can see that adding, subtracting, multiplying and dividing work with the modulo operations. Let’s try exponentiation. For this, we can have:

b = a^x (mod p)

If we try x=3 and p=5, we get:

Thus {1,2,3,4} maps to {1,3,2,4}. But what about the reverse? Well, we need to use an inverse log modulo p function. With this, as in the RSA (Rivest Shamir Adleman) public key method we find a value for a^x (mod p) so that:

x*y (mod PHI) = 1

and where PHI is (p-1). Now we compute:

So we can go ahead and now reverse and find the inverse log for {1,3,2,4} (mod 5):

And, so, we have reversed our modulo logarithm. Overall, the magic of PHI is at the core of the RSA method and where we can reverse the exponentiation operation. For this, we have a cipher of:

C= M^e (mod N)

and then can reverse with a value of d which is computed from:

d = e^{-1} mod PHI

and where PHI is (p-1)(q-1). We recover the message with:

M=C^d (mod N)

In this case, we actually have two prime numbers (p and q), and which are multiplied together to give the modulus (N).

And, so, all we need to constrain our mathematical operations on our groups is the (mod p) operation.

The problem with cryptography is that many miss some fundamental knowledge that will allow them to fully understand the key operations that are used. So, in this series of blogs, I try and explain some of the core concepts that secure our online world. Every single time that you connect to the Internet, the privacy and trustworthiness of your connection are dependent on some magical cryptographic operations. 

In our world of numbers, we have N (natural numbers — positive or negative integer values), Z (integers), R (real numbers) and C (complex numbers). for this. Natural numbers can go from minus infinity to plus infinity, while integers constrain these into a ring. A ring might be from 0 to 16, and the 17 goes back to 0, and so on. If we go to -1, that is 16, -2 is 15, and so on. 

For cryptography, we use the Z double-struck or blackboard bold symbol, where we typically define a group of numbers.

For this, we represent Z_n as the numbers from 0 to n-1. So, Z_7 is {1,2,3,4,5,6}. There is another group we use; the multiplicative group of integers modulo n Z_n*. This excludes the values which are a factor of n.

Z_7 will be {1,2,3,4,5,6}

Z_{12}* will be {1, 5, 7, 11} [here]

[Note: In the podcast, I said Z_16* and which will be: {1, 3, 5, 7, 9, 11, 13, 15}. 16 is 2x2x2x2, so any value with a factor of 2 in it will not be included. I will outline this in a future episode.]

So a group is basically a set of integers, and where we map from one group to another one. If we think about two sets A and B, and then create a mapping between the numbers in A to B, and vice-versa. For encryption, we want a 1-to-1 mapping from every value in A to B, and then for us to be able to reverse back from B to A. 

So, if we have a set of numbers of A={1,2,3,4} we might map these to B={2,4,3,1}. If we have a value of 1 in A, it will map to a 2 in B. Then, in B, we would map back from 2 to 1. In cryptography, we typically want to make it easy to go from A to B (encrypting), but difficult to go from B to A (decrypting) — unless we know a secret.

In this example, I have used a discrete logarithm mapping with a base generator of g and a prime number:

b=g^a (mod p).

 For the mapping of {1,2,3,4} to {2,4,3,1}, I have used g=2, and a prime number of 5. 

b = 2¹ (mod 5) = 2 (mod 5) = 2 b = 2² (mod 5) = 4 (mod 5) = 4 b = 2³ (mod 5) = 8 (mod 5) = 3 b = 2⁴ (mod 5) = 16 (mod 5) =1

This will be cyclic, and where {1,2,3,4,5,6,7,8} will map to {2,4,3,1,2,4,3,1}. For this, we have constrained within a finite field of between 0 and 4 (or p-1).

We can see that this gives us a 1-to-1 mapping for each of the elements of our first set to the other set. Every value in B can be reversed back to its original value in A. 

To reverse, though, we would need to compute the inverse log of the value in B for mod p — this is not so easy:

a =log_g(b) (mod p)

And this is the core difficulty of the discrete logarithm problem. It is this problem that secures the Internet.

To show you the difficulty of this, if I use a prime number of 2²⁵⁵-19 and a g value of 2. You will find it extremely difficult to find the x value I have used for:

b=25446473684081445734643481619349383496577344937808306324243206897292518839288

If you are interested, the answer is a=431342352456346734652345427573451341234132414341365756845234234234523

In Python, here’s the solution:

So, watch out for the next podcast…

How did you get started in this industry?

What are the three key tech/software tools that you depend on the most?

What is your favouriate book or podcast?

What is the most important thing you have learned in your career?

What advice would you give your younger self?

Who inspires you?

Steve is a Professor of Cyber Security in the School of Computer Science at the University of Nottingham, as well as an Adjunct Professor at Edith Cowan University in Western Australia and an Honorary Professor at Nelson Mandela University in South Africa. He is also the Chair of Technical Committee 11 (Security and Privacy Protection) within the International Federation for Information Processing, as well as a board member of the Chartered Institute of Information Security and chair of the academic partnership committee.

His main research interests are broadly linked to the intersection of human, technological and organisational aspects of cyber security. Within this, specific themes of interest include the usability of security technology, security management and culture, cybercrime and abuse, and technologies for user authentication and intrusion detection. Related to this, he has authored over 330 papers in refereed international journals and conference proceedings, as well as various books, chapters, and professional articles. 

https://www.nottingham.ac.uk/computerscience/People/steven.furnell

Never in the history of humankind have we advanced so fast. In just 40 years, we have built a new era and have said goodbye to the industry age. But will our future be an amazing world of opportunity where every citizen has the same opportunity as any other, or will we end up in a 1984 Big Brother world? At the core of this is the debate around privacy. Bruce Schneier sees this as a core element in building our digitally focused societies:

“Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect. It is about choice, and having the power to control how you present yourself to the world.”

and:

“Google knows more about what I’m thinking of than I do, because Google remembers all of it perfectly and forever.”

and for our new digital world:

“One hundred years ago, everyone could have personal privacy. You and your friend could walk into an empty field, look around to see that no one else was nearby, and have a level of privacy that has forever been lost.”

In my career, there was a time before I read Secrets & Lies … and there was a time after I had read it. It completely changed my focus. In fact, no other author (apart from George Orwell) has had an effect on my thoughts on the future world:

Bruce showed me a vision of the most trusted world. He made public key encryption interesting, and I could immediately see how cryptography could be used to rebuild our flawed digital world. I now teach and research cryptography, and I love the subject. I thank Bruce for taking me away from network switching and routers and showing me the beauty of a subject where you learn every single day.

We live in a strange world of cybersecurity. An auditor might ask a company if they encrypt their data? And the company may reply that they do, and so the auditor would tick that off. But encryption does not just involve the privacy of data; it also involves integrity checking and setting up digital trust. Along with this, there are many ways to implement methods, including key derivation, public key integration, hashing methods, and encryption modes. And, so, last week I outlined how some AES modes can be easily modified.

And so, someone asked me why I recommended GCM (Galois Counter Mode)? Well, GCM integrates integrity into the cipher. It is built on CTR (Counter) mode and is a stream cipher. This makes it fast. Along with this, we can add additional data into the ciphertext — and which defends against playback attacks. At the core of this is the Galois Message Authentication Code (GMAC).

In cybersecurity, you get those who pedal snake oil, and others that just try to scare you. The gap is that the advice is not given in an educated way, and basically just scares people (or gets them to buy the latest security product).

These days, the chances of someone cracking your password from a hashed version is likely to be minimal. For one, the chances of getting access to the hashed version of a password is extremely low, and for two, the password is typically stored in a way that will make it extremely costly — such as requiring the cost of electricity to boil a lake (or loch, in Scotland) — to crack it.

But, still, we get them from those who aim to “educate” (aka “preach”) us on Cybersecurity. Telling us not to share our passwords or to not click on spear-phishing links are better approaches than asking us to use long and complex passwords. As humans, we kinda lose it once we go over 10 characters. And, HashCat, too, knows all our little tricks for passwords (eg we typically always have one upper case letter and put it at the start) — where so-called complex passwords can be just as easy to crack as short and simple ones.

And, too, the days of Microsoft Windows XP are past, but some still think we are living in that world. These days, even Microsoft uses encrypted passwords with a slow hashing method. Linux, too, uses the best of breed for its password hashing, and where it would cost you your mortgage for a single brute force password crack. The industry has moved on — and has learnt from its mistakes, but some are still stuck in the past.

Ask anyone who has forgotten their Bitcoin wallet password — and I get continual questions from many people about this — about how difficult it is to recover it through brute force methods. A nine-character password, for example, on a Bitcoin wallet will take you over 59 million years — and inflation is likely to have made your Bitcoins worth very little — and you will be dead!

Link: here

The worm is turning!

C and C++ have ruled the core of our digital world for a long time and still do. But, they do not handle memory well, where we get buffer overflows (Morris Worm, SQL Slammer, and so many more) or buffer underflows (Heartbleed). This can involve a stack overflow attack, and where the program writes too much data to the stack that has been allocated for a given buffer, and for a heap overflow attack, where we overrun the memory into a space that is not allocated for a buffer.

These problems often allow adversaries to write data into places that it was not intended for or can cause an exception in the handling of the code (and thus cause a problem to act unreliable). A typical area is to overwrite memory that is allocated for other purposes and then cause a Denial of Service (DoS) against the code — and where it just stops working.

Along with this, developers often do not clean up their variables, so a garbage collector must come in and free up memory that is not being used anymore.

But, Rust just doesn’t allow you to do these things. It has strict checks on the usage of variables at compile time, and if you do something bad with them, it will tell you and refuse to compile the code.

In 2015, Rust was born, and in eight short years, many of the major software companies have adopted it as the core of their systems. Google was one of the early adopters but is now joined by Microsoft, who are developing their core code with Rust.

But, there are many questions … how long will it take to learn the language and will it make developers more productive? The following relates to research conducted in Google which answers these questions [here]. For this, Google did a survey of 1,000 of their developers.

Some Rust and Cryptography is [here].

We are human, and, like it or not, we lie. Why? Because we might not want to admit to some truth, or where we might want to seem knowledgeable. It is a human attribute, and it defines us. Overall, our intelligence weighs up the cost and reward and makes a decision as to whether we should tell the truth or not. Ask a child about who eat a biscuit, and there’s a chance they will lie because they do not want the punishment or do not want to tell tales about their friend. And so, as we go through our lives, we all lie, and sometimes it gets us in trouble; sometimes, it saves us from punishment; and sometimes, it makes us look smart.

Overall, lying is a weakness of our character, but, at other times, it is our intelligence showing through and making good guesses. At the core of this is often trust, and where someone who lies too much becomes untrustworthy, and if someone lies about someone else for a malicious reason, they can taint their own character. One of the least liked human attributes is where someone lies about someone else. But what about machines, can they lie?

But, a machine lying is a little like you getting asked, “who won the match between Manchester United and Grimsby Town?” If you don’t know the answer but want to look smart, you might “lie” and say that it was Manchester United — as they are most likely to win. If they didn’t win, you might be called a liar, but in most cases, you will seem knowledgeable.

And, so, there’s a dilemma in the usage of LLM (Large Language Models) … what happens when the AI doesn’t know the answer to something and where it hasn’t learnt it. While it may know the capital of Germany, it is unlikely to know the town you visited last Tuesday. With LLM, the machine obviously takes a guess based on probabilities. If I know that a person lives in Edinburgh, then in all probability, the most probable city will be Glasgow, and the next being London — as the probabilities will show that for travels, Edinburgh is most linked to Glasgow and then to London.

In a previous article, I outlined how Chat-GPT provided some false statements on me, including that I invented the Hypervisor and that I was a Fellow of the Royal Society of Edinburgh (RSE). But, if someone in the newspapers published false statements about someone, you might consider suing them or at least asking for an apology. But what about machines? What happens when they define “an untruth”?

In human terms, we would define an untruth as a lie. But a machine is just weighing up probabilities. It, too, has little concept of the truthiness (veracity) of the data it has received. For my RSE award, it perhaps looked at my profile and computed that there was a high probability that I would have an RSE Fellowship based on me being a Professor in Scotland, having an OBE, and having an academic publishing record.

But, if someone in the newspapers published false statements about someone, you might consider suing them or at least asking for an apology. But what about machines? What happens when they define “an untruth”?

And, so, ChatGPT — created by OpenAI — could be one of the first pieces of software to stand trial on the way it collects, uses and protects its data. For this, the Washington Post reports that the FTC (Federal Trade Commission) has initiated a wide-ranging set of questions against its LLM (Large Langage Model) [here].

I receive a good deal of incorrect emails on my Gmail account. Most of it relates to the gathering of war veterans in the US or church events in Illinois that I must attend. Why? Because someone, somewhere, has a similar email address to me. Perhaps it is Bill Buchan or Will Buchanan? Who knows, but I get them constantly, and where I discretely decline the invite and ask them to check the email address.

Overall, I never embarrass those who send me these emails by responding back to the whole group. Many times, there can be over 50 people that are copied into the email. It is all part of the silly world of email. But, when incorrect emails go to places with sensitive data, we must worry.

And, so, the Financial Times [here] has now disclosed that a typo in the definition of an email address has sent 100s of thousands of emails from its military domain (.MIL) to the Mali domain (.ML).

This includes sensitive documents, tax returns, travel information and password resets. It is thought that this has existed for over a decade and was discovered by Johannes Zuurbier (and who is in contact with those who managed the .ML domain), but only now is it being taken seriously by the US military. For this, he found over 117,000 misdirected email messages, which increases by over 1,000 messages by the day.

Postscript

Note, I support good journalism. The FT supports “Authority. Integrity. Accuracy.” Please consider a subscription, and keep good journalism alive:

https://subs.ft.com/subscription

Rock singers often say that it was their adversity that drove them to create their classics, such as heartache, sorrow, or losing something in their lives. And, so, we might quote:

Sweet are the uses of adversity — William Shakespeare

One such person who had considerable adversity is Leonhard Euler and who lived from 1707 to 1783. Leonhard was truly one of the greatest minds who has ever graced this planet:

“Read Euler, read Euler, he is the master of us all” — Pierre-Simon Laplace

But, he suffered great adversity in his life and eventually went blind. His blindness, though, seemed to just increase his outputs — as it allowed him to focus his mind on core problems. In fact, in 1775 — four years after he had gone blind — he proposed a mathematical paper every week. On going blind, he was quoted:

“Now I will have fewer distractions.”

Leonhard output of truly original thought in his time of adversity has possibly never been equalled by any mortal soul. And, his legacy lives on and is part of virtually every single transaction on the Internet. In fact, his maths has made our digital world so much safer.

This article could in no way define all of Leonhard’s contributions, but one of the most fundamental is that he took the basics of integral calculus — as sketchily defined by Newton and Leibniz — and perfected it. In our modern world, so many things in our lives depend on calculus for their solutions, such as where we see changes in the physical parameters in our world. Calculus, for example, links the distances we travel over time to speed, and then changes in our speed to acceleration and deceleration. Overall, it basically makes sense of the dynamics of our world — an ever-changing and sometimes chaotic world.

Further reading here.

So while there is much debate around people like Tim Berners-Lee and Vint Cerf, we should also include “The Editor of the Internet”: Jon Postel.

Jon was born on 6 August 1943 and died in October 1998. Even up to his death, he was the editor of the Request for Comment (RFC) documents and administered the Internet Assigned Numbers Authority (IANA). In 2012, he was inducted into the Internet Hall of Fame by the Internet Society, and the foundation he has left is as strong as any foundation ever created, in fact, it’s the foundation for our Cyber Age.

Before the Internet, companies such as IBM held a stranglehold on the industry, and typically defined the standards for others to follow. Along with this, we had standards agencies, such as ISO and the IEEE, which were comborsome entities which took years, if not decades, to standardize anything. With these standardization agencies, a standard could take years to develop, and often involved the tinkering from countries, in order to protect their industries, and thus often stifled innovation.

Overall the Internet was built around many of the systems and protocols that grew up in the early 1980s. It then grew without the constraints of governments and standards agencies. The core part of this growth was the quick method of publishing a new standard: the RFC.

RFC (Request For Comment) documents are a way to quickly define standards. With this HTTP and email quickly become standardized. Developers could then go ahead and implement the system against the standards, without the massive overhead of taking them to international standards agencies like the ISO (International Standard Organisation) or the IEEE.

While first published in 1969 (with RFC1), the classics first started to appear in 1981, and which now provide the core of the Internet:

• RFC 791 which defines the format of IP packets (IPv4)
• RFC 793 which defines TCP (Transport Control Protocol), and the foundation of virtually all of the traffic that exists on the Internet.

Many protocols, although now limited, became de-facto standards, and have moved on little since, including HTTP (HyperText Transmission Protocol) 1.1, which was initially created as RFC 1945.

So, it was in September 1981, that the true foundation of the standardisation of Internet communications was born:

For RFC 783 we have:

September 1981 Transmission Control Protocol

PREFACE This document describes the DoD Standard Transmission Control Protocol (TCP). There have been nine earlier editions of the ARPA TCP specification on which this standard is based, and the present text draws heavily from them. There have been many contributors to this work both in terms of concepts and in terms of text. This edition clarifies several details and removes the end-of-letter buffer-size adjustments, and redescribes the letter mechanism as a push function.

Jon Postel Editor

Sandwiched in-between the two classics, was another one, which did not have the same impact, but has helped to debug a billion systems: Internet Control Message Protocol (ICMP) — RFC 782. So RFC791, RFC792 and RFC793 have since changed the course of our societies.

The impact of the IP and TCP standards cannot be underestimated in terms of their impact on our society, and certainly rate alongside “The Wheel” and “The Transistor” as some of the most disruptive technologies ever created. Its standardization supported a whole range of activities and basically allow the Internet to boot up quickly. If nation-states had controlled the Internet, it would have ended up being licensed, and locked down in its growth. Without the massive growth of the spread of the protocols, the Internet would have died as quickly as it had been created. With standards and government agencies controlling its every move. For Jon, he just gathered the required methods for the standards and posted them for everyone to review. If you missed it, you really couldn’t contribute until the next version came along.

For something like HTTP, which provides the core of most of what we do on the Web, it started with 1.0 (with the input from Tim Berners-Lee) with RFC1945 (in 1996) and then developed on HTTP 1.1 as RFC2068 (in 1997). Basically in the 18 years since, very little has changed with the core HTTP protocol, as it quickly becomes as standard. New methods of using in — such as with REST Web services — actually made use of all the things that were not really used when accessing static Web pages.

The lack of thought to security is highlighted by the fact that it took to RFC 1508 before the word “Security” was included in the title (Sept 1993), which was more than 12 years since the IP packet definition (Sept 1981).

So it was 1981 when TCP and IP were created, and two major other things happened around the time that supported the growth of the Internet. The first was the release of the PC by IBM, and the other was when Leonard Bosack networked the Stanford University computer science department’s computers, along with Sandy Lerner. Their knowledge was then used to create the router, and the formation of Cisco in 1984. At its core was the implementation of the IP and TCP standards.

It’s not just TCP, IP and HTTP that we have to thank Jon for, it’s all the other protocols he helped standardize. The way that we use Web addresses, such as http://asecuritysite.com/challenges, was standardized in RFC 1738 — Uniform Resource Locators (URL), and which is something that we just take for granted, but without it, we really couldn’t create our integrated infrastructure.

And without Jon, we would have to remember the IP address of every Web site we wanted to visit — for that, he standardised domain names and their mapping to IP addresses with RFC1035.

And how can I connect a computer to the Internet, and every computer in the whole knows it’s there — well that one is a shy little protocol — ARP — Address Resolution Protocol — the most horrible and beautiful of all the protocols. It was published as RFC826 (standardized in 1982), and allows the discovery of computers on a local network by a network gateway. Without ARP, we would have to create a massive database that kept a copy of all the computers which connect to the Internet. With it, computers are discovered and connectable.

In the early phases of the Internet, it was not the Web that was the “killer app”, it was electronic mail. The large-scale adoption of email was indebted to Jon with standards around sending emails (SMTP — Simple Mail Transport Protocol — RFC821 — defined in 1982) and reading it (POP — Post Office Protocol — RFC960) — defined in 1985). Often, though, the first, and even the second version, was not enough, and some protocols, such as POP-3 (RFC1939) and IMAP-4 (RFC1730), went through a few major iterations to become the worldwide de-facto standard.

The greatest challenge for the Internet, when it was first created, was how it would scale, so that new computers and networks could be added, and discovered by the rest of “The Internet”.

I must here define “The Internet”, as it is different from “the internet”. Basically, “The Internet” uses publicly defined IP addresses, whereas “the internet” is not publicly routable.

The key to this, along with IP Version 4, was routing protocols, which were used to find the best way to a destination, and involved routers intercommunicating to discover new networks. The first of these “routing protocols” were fairly simple, just measuring the number of hops that it took to get from one network to another. And so Jon posted RFC1058 for RIP (Routing Information Protocol) Version 1.

Before RFCs, large companies often defined the standards, especially IBM, and who could force the market to abide by their interface and who could thus control the market. This monopoly was completely broken by Jon, and few companies could release new standards unless they had been standardized by RFCs.

We should all have a magic switch that pushes aside our worries and replaces them with something that takes our woes away. So, when I’ve had a long and tiring day, and there are things buzzing in my head — I don’t count sheep, I ponder the wonder of discrete logarithms, and in the magical ways they have solved our many online security. It relaxes me and pushes out all of those academic stresses.

This academic year, we were so lucky to speak to some of the people who properly built the foundations of our online security. This included Marty Hellman (co-inventor of the Diffie-Hellman method), Tahir ElGamal (inventor of the ElGamal encryption method), and Neal Koblitz (co-inventor of Elliptic Curve Cryptography — ECC). In this article, I will trace the roots of this security, and outline how discrete logs paved the way for the rise of ECC.

So, if we go back to school, you will remember that:

g^x . g^y

is equal to:

g^{x+y}

and that:

{g^x}^y

is:

g^{x.y}

That’s the beauty of logarithms.

Our online world is secured with discrete logs. While we have moved away from discrete logs for key exchange (Diffie-Hellman), encryption (ElGamal) and digital signatures (DSA), at the core of the security of elliptic curves is the Elliptic Curve Discrete Logarithm Problem (ECDLP):

Can we find n such that Q = nP?

and where P and Q are points on an elliptic curve, and where we have a finite field defined by a prime number. The curve itself can be the form of:

y²=x³+ax+b (mod p)

The (mod p) part defines a finite field, and which basically constrains the values of x and y to between 0 and p-1. But, I’d like to look back at a time before elliptic curves and see where we started with this: the discrete log. Basically, discrete logs built the security of the Internet, and without them, we would have struggled to advance from a digital world that used physical cables and padlocks to secure itself.

I love wireless (wi-fi) communications. In fact, I did my PhD around the propagation of radio waves using Maxwell’s equations. The beauty and perfection of radio waves will never leave me. The first thing you often learn about wifi is how the frequency of the wave relates to its wavelength (lambda=speed of light divided by the frequency) and how dipole antennas have to be around half a wavelength long. For AM, there are long antennas (such as, with the ones that wrap copper around a core) or can be short ones (like the dipole antenna on your wireless router). Much of the magic happens around 2.4GHz.. and which gives a wavelength of 12.5cm, and where if you measure the dipole antenna, it will be around 6cm high. Once you learn about this, you are often hooked on the wonderment of radio waves. It has solid mathematics, but is also a black art (ask any RF engineer, and they will tell you this)! Overall, too, wi-fi has freed us from those pesky twisted pair of cables and those troublesome RJ45 and RJ11 connectors. And, at the core of wifi, is signal strength, and where the stronger the signal, the more chance we have of creating a good network connection. For this, with most IEEE 802.11x standards, the bandwidth that you can use often relates to the signal strength that you have — so the further away you are from the transmitter, the more likely it is that you will have a lower bandwidth capacity. I, too, love all the different antenna shapes and designs and try to imagine how they spread their signals. But those pesky metal things get in the way and can bounce signals in other directions (which is sometimes a good thing, of course), and the other materials, such as concrete, will reduce the signal strength. For all the maths of Maxwell’s equations, a lot comes down to measurements and simulations. At home, you might have a MIMO (Multiple In, Multiple Out) transmitter, and which bounces signals of objects and transmits on multiple channels. This might give up to 540Mbps. But, the further you go away from this, the bandwidth reduces until it will drop to nearer 11 Mbps. And, so RSSI (Receiver Signal Strength Indicator) is an important measurement as it defines how good your signal strength is — at a point in time. This will obviously vary as you move and as other things move around you. But, at the other end, if you have too much signal strength, you can breach health and safety regulations. Currently, this is around 100mW, and you need to have a good reason if you need higher power levels than this, as too much radio power — especially around 2.4GHz — might affect someone’s health. So, let's talk about that troublesome (and powerful) unit called dBm, and where it is all about adding and subtracting, and not those difficult maths operations of multiplying and dividing. Believe in John Napier's logs to help our wifi systems:

I have a secret. And you have a secret. And together, we can merge our secret into another secret. What I am outlining here is the beauty of the Elliptic Curve Diffie Hellman (ECDH) method, and it is protecting your rights to privacy in the access that you have to this podcast. And what about trust? Well, there’s a chance that the Web site that you are receiving this podcast from is using the ECDSA (Elliptic Curve Digital Signature Algorithm) to verify that you can trust the site.

And, so, in this podcast, I’m going to outline something that is pure mathematical beauty: the Elliptic Curve. 

There are more information on ECC [here] and the text to this Podcast is [here].

 Here Harry McLaren talks with Rich Macfarlane and Bill Buchanan. What's the key to finding a job within Cybersecurity? A balance of technical competencies (networking, OS, services, programming, and so on) and human intelligence (self-awareness, self-regulation, motivation, empathy and social skills).

The slides are here.

For Splunk/Cyber&Data: here.

This is a basic introduction to the Building Trust podcast.

In this episode Professor William Buchanan OBE takes us back through the patents that gave rise to the security for the internet as we know it.

In this podcast, we will outline some of the design choices that Satoshi Nakamoto made for the hashing of the private key to the public ID, especially on the selection of the two hashing methods of SHA-256 and RIPEMD160.

So how do we create a world where we can store our secrets in a trusted and then reveal them when required? Let’s say I predict the outcome of an election, but I don’t want to reveal my prediction until after the election. Well, I could store a commitment to my prediction, and then at some time in the future, I could reveal it to you, and you can check against the commitment I have made. Anyone who views my commitment should not be able to see what my prediction is.

This is known as Pedersen Commitment, and where we produce our commitment and then show the message that matches the commitment. In its core form, we can implement a Pedersen Commitment in discrete logs [here]. But blockchain, IoT, Tor, and many other application areas, now use elliptic curve methods, so let’s see if we can make a commitment with them.

Note: TeamViewer is not a malicious piece of software when normally used. The scammer wanted to install a remote desktop on my machine with it.

Jean-Philippe (JP) Aumasson is a true innovator in cryptography, and especially in the creation of fast, secure and light-weight hashing methods. He co-designed the BLAKE hashing method [here], and which is currently the fastest secure cryptographic hashing function. Along with this, he worked with Daniel J Bernstein on SipHash [here], and created the Cryptography Coding Standard. JP also created the Quark light-weight hashing method, and is also the author of "Serious Cryptography: A Practical Introduction to Modern Encryption" [here].

Neal I. Koblitz is a Professor of Mathematics at the University of Washington. He is a co-inventor of Elliptic Curve Cryptography (ECC). His original paper was published in 1987 and entitled "Elliptic curve cryptosystems" [1]. Overall, ECC is one of the greatest breakthroughs in cryptography and which has largely replaced discrete logarithm methods in key exchange and has replaced the RSA method in many applications for digital signing. Overall, elliptic curve methods are now used extensively with digital signing (ECDSA/EdDSA) and for key exchange (ECDH), along with applications into Bitcoin and Ethereum. Neal was recently recognized for his work with the Levchin Prize at the real-world cryptography conference. His recent work has included applications for lattice cryptography and random oracles. Neal is also the author of several leading textbooks:

[1] Koblitz, N. (1994). A course in number theory and cryptography (Vol. 114). Springer Science & Business Media.

In this episode Professor William Buchanan OBE talks with Professor Keith Martin, from the Royal Holloway, about the intersection of information security and academia, privacy and digital footprints.

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.

In this episode Professor William Buchanan OBE talks with by Dan Shumow, Senior Software Development Engineer in the Security and Cryptography group, about cryptography, RSA and the researcher’s mindset.

Len is a co-creator of the RSA encryption algorithm [1] and received the 2002 Turing Award (often defined as the Nobel Prize of Computer Science). The RSA paper is one of the most significant computer science papers ever published and has received over 25,695 citations. Len is also known for the creation of DNA computing. He is a professor at the University of Southern California and a member of the National Academy of Sciences.

[1] Rivest, R. L., Shamir, A., & Adleman, L. (1978). A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2), 120-126.

In this episode Professor William Buchanan OBE talks with Professor Martin Hellman, a world-renowned cryptologist and a founder of public key encryption, about cryptography and ethics.  

In this episode Professor William Buchanan OBE talks with Professor Leonard Adleman, from the University of Southern California, about the endurance of RSA, DNA as a computational substrate and the contention between national security and privacy.

In this episode Professor William Buchanan OBE talks with Professor Alan Woodward from University of Surrey about his illustrious career as a Physicist, Consultant, Researcher and Professor.  

In this episode Professor William Buchanan OBE is joined by Nick Sullivan, head of research at Cloudflare, to discuss the mathematics of cryptography, public key encryption, and the implications of quantum computing.

In this Episode Professor William Buchanan OBE talks with Federico Charosky about the past, present and future of the information security industry, what it takes to innovate as an entrepreneur and his view on the intersection between industry and academia.