ASecuritySite Podcast

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

In cybersecurity, there are so many acronyms, and to be an expert, you really need to dig underneath the methods and understand how they work. One weak area of the industry is in the usage of MACs (Message Authentication Codes). With the public-key signing, we use a public key and a private key, where the private key will digitally sign a hash of the message, and where the public key is verified the signature. With a MAC, we use a shared symmetric key, and where Bob and Alice will share the same secret key (Figure 1). https://medium.com/@billatnapier/cmac-or-hmac-which-is-better-8e1861f744d0

Article: https://medium.com/asecuritysite-when-bob-met-alice/the-brainpool-curves-f2f865b88191

Article: https://medium.com/asecuritysite-when-bob-met-alice/our-current-hardware-architectures-are-often-not-fit-for-a-world-of-ml-and-homomorphic-encryption-1df5a4a45a4d

Article: https://billatnapier.medium.com/nist-looks-to-the-future-of-cryptography-sha-1-3des-and-sha-224-on-naughty-step-7295d03fdc54

Read more: https://medium.com/asecuritysite-when-bob-met-alice/goodbye-google-and-the-microsoft-and-openai-partnership-fraying-8c35e35cd814

Read more: https://medium.com/asecuritysite-when-bob-met-alice/the-wonderful-world-of-proxies-818c196290ff

Details: https://billatnapier.medium.com/the-largest-prime-number-ever-found-and-the-52nd-mersenne-prime-65348546b651

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

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. The Pedersen Commitment 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: Interview 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

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. AES method 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. Round 1 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 S

In research, the publishing of high-quality papers is often critical for the development of a research career: "I am an academic. It's publish or perish." Daniel J Bernstien. But often we measure the work in terms of quality rather than quantity. One high-quality research paper is probably worth more than the millions of papers published in predatory journals. A great researcher should be able to measure the quality of their work by the known impact and contribution of their research papers, and not by citation count or journal impact factor. In fact, review papers often contribute little to the development of new methods, but are some of the most highly cited papers. A research paper thus has a life. Authors might have a dream that their work is going to fundamentally change a given field, but it ends up never being read much and withers. Overall, most papers just bob along with a few citations in a year, and where you are lucky if you get more than 10 citations. An academic often follow the impact of their papers on Google Scholar, and which can give you an idea of whether their work is rising or on the wain. If you are interested, here's mine showing a nice exponential rise over the past few years: Some papers might rocket with many initial citations, and where researchers cite them heavily, but then either the research area just dies off with a lack of interest, or problems are found with it. Isogenies within post-quantum methods is one example of this, and where a single crack on SIDH (Supersinglar Isogeny Diffie-Hellman) stopped some of the advancements in the field [here]: Up to that point, isogenies were the poster child and the great hope for competing with lattice methods. While they were still slow, researchers were gearing up their research to address many of their performance weakneses. They were much loved, as they used elliptic curves, but one paper stalled the isogeny steam train. I do believe they will return strong, but it will take a while to recover from such a serious crack. Cryptography is often about reputation, and a single crack can bring the whole method down. Other papers, though, can be slow burners. The core papers in ECC (Elliptic Curve Cryptography), for example, did not take off for a few years after the work was published. When Neal Koblitz published his paper on "Elliptic curve cryptosystems" in 1987, it was hardly cited, and few people picked up the potential to replace RSA signatures. In 1997 (10 years after the publication of the paper), it is still only achieved 41 citations. But things really took off around 2005, and especially when Satoshi Nakamoto adopted ECC for Bitcoin around 2009. It now sits at nearly 400 citations per year, and where ECDSA and EdDSA have made a significant impact in replacing our cumbersome RSA methods: Test-of-Time (ToT) Award Now Chris Peikert, Brent Waters, and Vinod Vaikuntanathan (Via-kun-tan-athan) have been awarded the International Association for Cryptologic Research (IACR) Test-of-Time (ToT) Award for a paper entitled "A Framework for Efficient and Composable Oblivious Transfer" and presented at the Crypto 2008 conference [here][1]: Overall, the Test-of-Time Awards is awarded to papers published over 15 years ago, with the three IACR general conferences (Eurocrypt, Crypto and Asiacrypt). The developed framework integrates "universal composability" and which provides strong security properties. Basically, a protocol P1 is secure if another protocol (P2) emulates P1, and where it is not possible to tell the two apart. It introduced a simple method of "dual-mode cryptosystem". The work has been fundamental in creating Oblivious Transfer protocols, and which are used in Multi-Party Computation (MPC). A great advancement of the paper is in the usage of Learning with Errors (LWE) — and which is now used within lattice cryptography methods. The paper has since laid a foundation for lattice cryptography. As with the ECC method, the paper was a slow-burner [here] with only 11 citations in 2008, but rose to more than 10 times that number: MPC So, let's see if we can build a model where we can securely distribute value and then get our nodes to perform the result of a calculation. None of the nodes should be able to compute the result without the help of others, and where Trent is trusted to distribute the inputs, watch the broadcasts, and then gather the results. For this, we can use Shamir secret shares, and where a value can be split into t-from-n shares and where we need t shares to rebuild our value. So, we could distribute a 2-from-3 to Bob, Alice and Eve, and they Bob and Alice, or Alice and Eve, could rebuild the value back again. So let's say we have two values: x and y, and we want to compute x×y. We then initially start with n parties, and where we define a threshold of t (the minimum number of shares required to rebuild any value. Initially, Trent (the trusted dealer) splits the input values of x and y into shares: Sharesx=x1,x2,…xn

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

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): Domain Name: bbn.comRegistry Domain ID: 4240240_DOMAIN_COM-VRSNRegistrar WHOIS Server: whois.corsearch.domainsRegistrar URL: Updated Date: 2023-05-09T19:30:10ZCreation Date: 1985-04-24T05:00:00ZRegistrar Registration Expiration Date: 2024-04-25T04:00:00ZRegi

In cybersecurity, the teaching of Cloud security is often weak. So, here are my Top 100 things about encryption in the Cloud. I've focused on AWS, but Azure is likely to also be applicable. Keys are created in the AWS KMS (Key Management Store). In Azure, this is named KeyVault. The cost of using a key in KMS is around $1/month (prorated hourly). When a key is disabled, it is not charged. With AWS KMS, we use a shared customer HSM (Hardware Security Module), and with AWS CloudHSM it is dedidated to one customer. For data at rest, with file storage, we can integrate encryption with Amazon EBS (Elastic Block Storage) and Amazon S3. Amazon EBS drives are encrypted with AES-256 with XTS mode. For AWS-managed keys, a unique key is used for every object within S3 buckets. Amazon S3 uses server-side encryption to store encrypted data. The customer can use client-side encryption to encrypt data before it is stored in the AWS infrastructure. AWS uses 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) for its symmetric key encryption. In AWS S3, by default, all the objects are encrypted. A customer can use client-side encryption to encrypt data before it goes into the AWS infrastructure. For data at rest, for databases, we can integrate encryption with Amazon RDS (AWS's relational database service) and Amazon Redshift (AWS's data warehousing). For data at rest, we can integrate encryption into ElastiCache (AWS's content caching service), AWS Lambda (AWS's serverless computing service), and Amazon SageMake (AWS's machine learning service). Keys are tokenized and have an ARN (Amazon Resource Names) and alias. An example ARN for a key is arn:aws:kms:us-east-1:103269750866:key/de30e8e6-c753–4a2c-881a-53c761242644, and an example alias is "Bill's Key". Both of these should be unique in the user's account. To define a KMS key, we can either use its key ID, its key ARN, its alias name, or alias ARN. You can link keys to other AWS Accounts. For this, we specify in the form of "arn:aws:iam::[AWS ID]:root", and where AWS ID is the ID of the other AWS account. To enhance security, we can use AWS CloudHSM (Hardware Security Module). For simpler and less costly solutions, we typically use AWS KMS (Key Management Solution). For CloudHSM, we pay per hour, but for KMS, we just pay for the usage of the keys. The application of the keys is restricted to defined services. Key identifiers and policies are defined with a JSON key-value pair for data objects. Each key should have a unique GUID, such as "de30e8e6-c753–4a2c-881a-53c761242644". Users are identified and roles are identified with an ARN, such as : "arn:aws:iam::222222:root". With the usage of keys we have Key Administrative Permission and a Key Usage policies. There is an explicit denial on a policy if there is not a specific allow defined in a policy. For key permissions, we have fields of "Sid" (the descriptive name of the policy), "Effect" (typically "Allow"), Principal (the ARN of the user/group), "Action" (such as Create, Disable and Delete) and "Resource". A wildcard ("*") allows or disallows all. To enable a user of "root" access to everything with a key would be : "Sid": "Enable IAM User Permissions", "Effect": "Allow","Principal": {"AWS": "arn:aws:iam::22222222:root"},"Action": "kms:*", "Resource": "*"}. The main operations within the KMS are to encrypt/decrpyt data, sign/verify signatures, export data keys, and generate/verify MACs (Message Authentication Codes). Key are either AWS managed (such as for the Lambda service), Customer managed keys (these are created and managed by the customer). Custom key stores are where the customer has complete control over the keys). The main use of keys are for EC2 (Compute), EBS (Elastic Block Storage) and S3 (Storage). AES symmetric keys or an RSA key pair are used to encrypt and decrypt. RSA uses 2K, 3K or 4K keys, and with either "RSA PCKS1 v1.5" or "RSA PSS" padding. RSA PCKS1 v1.5 padding is susceptible to Bleichenbacher's attack, so it should only be used for legacy applications, and for all others, we should use RSA PSS. For RSA, we can use a hashing method of SHA-256, SHA-384 or SHA-512. In RSA, we encrypt with the public key and decrypt with the private key. For signatures, we can use either RSA or ECC signing. For RSA, we have 2K, 3K, or 4K keys, whereas ECC signing uses NIST P256, NIST P384, NIST P521, and SECG P256k1 (as used in Bitcoin and Ethereum). For MACs (Message Authentication Codes), Bob and Alice have the same shared secret key and can authenticate the hash version of a message. In the KMS, we can have HMAC-224, HMAC-256, HMAC-384 and HMAC-512. KMS uses hardware security modules (HSMs) with FIPS 140–2 and which cannot be accessed by AWS employees (or any other customer). Keys will never appear in an AWS disk or backup, and only existing the memory of the HSM. They are only loaded when used. Encryption keys can be restricted to one region of the world (unless defined by the user). With symmetri

Well, here are a few tips for PhD students and ECR (Early Career Researchers): 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. 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! Two years of a PhD pass by fast. Be ready for the "last year of research" spike. 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. 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! 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. Doodles with pen and paper are great for getting your mind in gear. Have a thick skin — both from your supervisors, others around you, and, most of all, peer reviewers and your external examiner. 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. 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. 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. 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). 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. 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. Throughout your work, especially in the 2nd and 3rd year of a PhD, continually run small experiments and get some results. Have a hypothesis about experiments, and prove or disprove this. Know the top people in your field, and be able to quote their work. Be inspired by other researchers. Be humble about your own work, and help others. 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. Don't ever copy and paste work from others into your own work. Rephrase in your own words. Don't use AI tools for descriptions. The reader will typically spot these — as the writing style often changes. Be consistent in your writing style. Read the work of others — especially great science/technical writers — and understand the methods they use to engage readers. 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". Explain your work to your family and friends. If they can't understand the problem and your solution, refine it until they can. 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. Know the potential impact of your work. Is it technical advancement? Is it social change? 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? Protect your IP when you need to. Patents are one way to do this, so just don't blindly publish every you have. 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 t

Here are my 100 interesting things to learn about cryptography: For a 128-bit encryption key, there are 340 billion billion billion billion possible keys. [Calc: 2**128/(1e9**4)] For a 256-bit encryption key, there are 115,792 billion billion billion billion billion billion billion billion possible keys. [Calc: 2**256/(1e9**8)] To crack a 128-bit encryption with brute force using a cracker running at 1 Teracracks/second, will take — on average — 5 million million million years to crack. Tera is 1,000 billion. [Calc: 2**128/100e9/2/60/60/24/365/(1e6**3)] For a 256-bit key this is 1,835 million million million million million million million million million years. For the brute force cracking of a 35-bit key symmetric key (such as AES), you only need to pay for the boiling of a teaspoon of energy. For a 50-bit key, you just need to have enough money to pay to boil the water for a shower. For a 90-bit symmetric key, you would need the energy to boil a sea, and for a 105-bit symmetric key, you need the energy to boil and ocean. For a 128-bit key, there just isn't enough water on the planet to boil for that. Ref: here. With symmetric key encryption, anything below 72 bits is relatively inexpensive to crack with brute force. One of the first symmetric key encryption methods was the LUCIFER cipher and was created by Horst Feistel at IBM. It was further developed into the DES encryption method. Many, at the time of the adoption of DES, felt that its 56-bit key was too small to be secure and that the NSA had a role in limiting them. With a block cipher, we only have to deal with a fixed size of blocks. DES and 3DES use a 64-bit (eight-byte) block size, and AES uses a 128-bit block size (16 bytes). With symmetric key methods, we either have block ciphers, such as DES, AES CBC and AES ECB, or stream ciphers, such as ChaCha20 and RC4. In order to enhance security, AES has a number of rounds where parts of the key are applied. With 128-bit AES we have 10 rounds, and 14 rounds for 256-bit AES. In AES, we use an S-box to scramble the bytes, and which is applied for each round. When decrypting, we have the inverse of the S-box used in the encrypting process. A salt/nonce or Initialisation Vector (IV) is used with an encryption key in order to change the ciphertext for the same given input. Stream ciphers are generally much faster than block cipers, and can generally be processed in parallel. With the Diffie-Hellman method. Bob creates x and shares g^x (mod p), and Alice creates y, and shares g^y (mod p). The shared key is g^{xy} (mod p). Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method). Adi Shamir defines a secret share method, and which defines a mathematical equation with the sharing of (x,y), and where a constant value in the equation is the secret. With Shamir Secret Shares (SSS), for a quadratic equation of y=x²+5x+6, the secret is 6. We can share three points at x=1, x=2 and y=3, and which gives y=12, y=20, and y=20, respectively. With the points of (1,12), (2,20), and (3,20), we can recover the value of 6. Adi Shamir broke the Merkle-Hellman knapsack method at a live event at a rump session of a conference. With secret shares, with the highest polynomial power of n, we need n+1 points to come together to regenerate the secret. For example, y=2x+5 needs two points to come together, while y=x²+15x+4 needs three points. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled "Cryptographic Communications System and Method". In public key encryption, we use the public key to encrypt data and the private key to decrypt it. In digital signing, we use the private key to sign a hash and create a digital signature, and then the associated public key to verify the signature. Len Adleman — the "A" in the RSA method — thought that the RSA paper would be one of the least significant papers he would ever publish. The RSA method came to Ron Rivest while he slept on a couch. Martin Gardner published information on the RSA method in his Scientific American article. Initially, there were 4,000 requests for the paper (which rose to 7,000), and it took until December 1977 for them to be posted. The security of RSA is based on the multiplication of two random prime numbers (p and q) to give a public modulus (N). The difficulty of RSA is the difficulty in factorizing this modulus. Once factorized, it is easy to decrypt a ciphertext that has been encrypted using the related modulus. In RSA, we have a public key of (e,N) and a private key of (d,N). e is the public exponent and d is the private exponent. The public exponent is normally set at 65,537. The binary value of 65,537 is 10000000000000001 — this number is efficient in producing ciphertext i

Interview here: https://podcasts.apple.com/us/podcast/talking-with-tech-leaders/id1533642699 https://open.spotify.com/episode/11PmWm0mlGQNAhVn8wYnIn

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: DigitalScotland 2023 DigitalScotland 2023 is designed for public sector leaders whose goal is to drive transformational change - both within… futurescot.com 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. The Problem 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. The Vision 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 for this to happen? 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: GLASS: Control your own data with EU Digital ID Wallet The GLASS Consortium came together on 14-15 June 2022 in Lisbon, Portugal for the 5th Plenary Meeting of the Project… tages.biz

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: A lack of training and awareness from those handling the FoI request. A lack of checking and sign-off within the process. Documents should be marked with the security classification, and access rights defined properly to highly confidential documents. 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. So, what's wrong with spreadsheets? 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. Conclusions 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: Blockchains use public key methods to integrate digital trust. Bob signs for a transaction with his private key, and Alice proves this with Bob's public key. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled "Cryptographic Communications System and Method". Blockchains can either be permissioned (requiring rights to access the blockchain) or permissionless (open to anyone to use). Bitcoin and Ethereum are the two most popular permissionless blockchains, and Hyperledger is the most popular permissioned ledger. Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method). David Chaum is considered as founders of electronic payments, and, in 1983, created ECASH, along with publishing a paper on "Blind signatures for untraceable payments". Miners gather transactions on a regular basis, and these are added to a block and where each block has a Merkle hash. The first block on a blockchain does not have any previous blocks — and is named the genesis block. Blocks are bound in a chain, and where the previous, current and next block hashes are bound into the block. This makes the transactions in the block immutable. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment. Craig Steven Wright has claimed that he is Satoshi Nakamoto, but this claim has never been verified. Most blockchains use elliptic curve cryptography — a method which was created independently by Neal Koblitz and Victor S. Miller in 1985. Elliptic curve cryptography algorithms did not take off until 2004. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass ("Vier-strass") curve. The prime number used with secp256k1 is ²²⁵⁶−²³²−²⁹−²⁸−²⁷−²⁶−²⁴−1. Satoshi published a 9-page paper entitled "Bitcoin: A Peer-to-Peer Electronic Cash System" White Paper on 31 Oct 31, 2008. In 1997, Adam Black introduce the concept of Proof of Work of Hashcash in a paper entitled, "Hashcash — a denial of service countermeasure." This work was used by Satoshi in his whitepaper. Satoshi focused on: a decentralized system, and a consensus model and addressed areas of double-spend, Sybil attacks and Eve-in-the-middle. The Sybil attack is where an adversary can take over the general consensus of a network — and leads to a 51% attack, and where the adversary manages to control 51% or more of the consensus infrastructure. Satoshi used UK spelling in his correspondence, such as using the spelling of "honour". The first Bitcoin block was minted on 3 Jan 2009 and contained a message of "Chancellor on brink of second bailout for banks" (the headline from The Times, as published in London on that day). On 12 Jan 2009, Satoshi sent the first Bitcoin transaction of 50 BTC to Hal Finney [here]. A new block is created every 7–10 minutes on Bitcoin. In Aug 2023, the total Bitcoin blockchain size is 502 GB. As of Aug 2023, the top three cryptocurrencies are Bitcoin, Ether, and Tether. Bitcoin has a capitalization of $512 billion, Ether with $222 billion, and Tether at $83 billion. The total cryptocurrency capitalisation is $1.17 trillion. The original block size was 1MB for Bitcoin, but recently upgraded to support a 1.5MB block — and has around 3,000 transactions. Currently the block sizes are more than 1.7MB. Bitcoin uses a gossip protocol — named the Lightning Protocol — to propagate transactions. A Bitcoin wallet is created from a random seed value. This seed value is then used to create the 256-bit secp256k1 private key. A wallet seed can be converted into a mnemonic format using BIP39, and which uses 12 common words. This is a deterministic key, and which allows the regeneration of the original key in the correct form. BIP39 allows for the conversion of the key to a number of languages, including English, French and Italian. A private key in a wallet is stored in a Wif format, and which is a Base58 version of the 256-bit private key. The main source code for the Bitcoin blockchain is held at https://github.com/bitcoin, and is known as Bitcoin core. This is used to create nodes, store coins, and transactions with other nodes on the Bitcoin network. A 256-bit private key has 115,792 billion billion billion billion billion billion billion billion different keys. A public Bitcoin ID uses Base58 and has a limited character set of '123456789ABCDEFGHJKLMN PQRSTUVWXYZabcdefghijkmno pqrstuvwxyz', where we delete '0' (zero), 'l' (lowercase 'l'), and 'I' (capital I) — as this can be interpreted as another character. In Bitcoin and Eth

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. CrashOverRide and Titon 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. DM-PLC 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

Kerckhoff's principle defines that "a Cryptographic system should be designed to be secure, even if all its details, except for the key, are publicly known", but there aren't too many other rules defined. So here are my 100 Basic Rules of Cryptography (and Secure Programming). First, my Top 10: Cryptography is both an art and a science. Cryptography needs to be both theoretical and practical — one without the other leaves gaps. The maths is not actually that difficult — it is just the way that researchers talk about it that is a problem. Know your knowledge gaps — and plug them. Your university education is unlikely to have properly set you up for the serious world of cryptography. Crypto is cryptography and not cryptocurrency. Few methods are perfect — know the limits of any method you use. Don't cook your own crypto! How many times do you have to say this to yourself? Security-by-obfuscation never works that well. Confidentiality, Integrity and Assurance are different things and require different methods. Don't merge them all together into one thing. And the rest: Digital certificates and PKI (Public Key Infrastructure) are two of the least understood areas of cybersecurity — don't expect many people to understand them. For public key encryption, you encrypt with Alice's public key, and she decrypts with her private key. For public key signatures, you sign a hash of the message with your private key, and Alice proves your public key. Your baseline hack is always brute force. Know how many dollars it would cost the NSA to crack something. Machine code can reveal your secrets. A hack of one key should not lead to the loss of all the previous keys. A key should only exist for the time it was meant to exist for. Use session keys wherever possible, and watch out for long-term keys. Your role is typically to protect the user and not reveal things to the NSA. Listen to experts, and be a teacher to others. Be open with your knowledge, and don't pretend you know something that you don't. Try and understand the basics of the maths involved — otherwise, you are trusting others. Understand entropy, and know how to calculate it and prove it with experiments. Run entropy calculations before pushing related code to production. Don't use a method unless it has been peer-reviewed and published. Understand the strengths and weaknesses of your methods. No method is perfect —but at least know what problems it might cause and try and mitigate against these. Know why you have chosen X over Y, and be able to defend the reason to others. The maths may be sound, but human is typically the main weakness. Everything will work fine until it doesn't. Test for out-of-band conditions as much for good conditions. Zero is not your friend in cryptography, so always know what it will do to your system. Don't just catch exceptions; action them. Do not allow to progress unless everything checks out okay. Log good and bad. Catch good things, along with bad things. Monitor your security logs for exceptions and bad operations. Remove debugging code from your production version. Keep up to date with the latest research. Beware of backdoors in methods and code. Side channels are smart ways to reveal the 1s and 0s, and every bit discovered reduces the security level by two and makes it so much less expensive to crack. Every bit drops the price tag for a crack by a half. The core security of your system is likely to depend on the generation of random oracles (seed values). Make sure they are generated so they do not repeat within a given time and cannot be brute forced by the NSA. If you can use real randomisation and not pseudo-randomness. If you generate pseudo-randomness, take the randomness from several sources. Continually review your code, and get external experts to review it. Don't push your code in production until you have tested it — fully! Check the code in the libraries you use, and perhaps, don't use them if there are no open-source repositories. If you can, open source your libraries. Watch out for version updates on your code, and try and lock a given (known) version to your code. Encrypt anything that looks like PII (Personally Identifiable Information) at rest and over the air. Remember that running memory can reveal keys and cryptographic artefacts, so know the risk. Learn a new method every day, and don't get stuck with the same old crypto! Quantum computers will happen one day and will disrupt our life, so start thinking about the impact they might have. Revealing your private keys is like giving someone the keys to your castle, so know where they are and restrict access to them. Only give access to private keys to those you most trust to use them properly. Air your development environment from your production environment, and don't let private keys propagate. The best systems use zero trust. No rights to anything unless they can be proven. You will — at times — need to revoke your public keys. Be aware of the processes involve

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]: % bx seed 6183d30558f3f56b0f7248aea1ed9b1098037ff5ad5eea69% bx seed 090a30f539d443b9ca61cc40c0e8142fc3e95c2e2d288a85% bx seed | bx ec-new > private_key% cat private_key 43c8175d0dc33bfca0bd6bb5f758fd3489da33b08e9b65cd377436952cbc6eb3 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 Conclusions 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. Loss Expectancy 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 Figure 1 Figure 2 Risk management/avoidance 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 metho