ASecuritySite Podcast

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: