ASecuritySite Podcast

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

Lessons from the cybersecurity rule book for government: Lesson 1: If you have PII (Personally Identifiable Information), you should encrypt it. Lesson 2: Lock down access to encrypted data and require multifactor authentication for access. Lesson 3: All communications with citizens should be stored in an encrypted form. Lesson 4: The transmission of data between systems should be encrypted and authenticated. Lesson 5: All accesses to data should be logged, and restrict queries based on a policy. Lesson 6: Alerts on data access should be analysed — either automated or by a human. Lesson 7: Provide a strong identity governance framework and do not automatically assign rights. Lesson 8: Apply human checkpoints and tripwires on access control to sensitive documents. Lesson 9: Provide physical and virtual segmentation of data sources from access control. Lesson 10: Implement a dual-homed approach to the access to data — and where access to sensitive data sources is isolated from general areas through white-list firewalls. Lesson 11: Put a strongly authenticated API in-front of data and limit queries based on role. Lesson 12: Don't use role-based security, and migrate to attribute-based systems based on time, location, hardware/software token access, and so on. Lesson 13: Don't use a single key to encrypt all your data … use envelope encryption and where every data record and message can have a random encryption key. Lesson 14: Use a Hardware Security Module (HSM) to store your sensitive keys and restrict access to them. Lesson 15: Audit regularly and review access logs. Get external reviews from trusted entities. Lesson 16: Warn staff of tripwire approaches, and define HR procedures for breaches, eg three strikes, and you're out! Lesson 17: Remove passwords wherever possible, and replace with multifactor authentication that includes tokens, time and location. Lesson 18: Implement file scanning processes and which aim to discover key identifiers of PII (including on work-based laptops). Lesson 19: Zero trust levels on access to citizen data. Lesson 20: Run only one service on one server, and minimise the surface area. It's as simple as that. In fact, governments could learn a great deal about coping with cybersecurity in the Cloud. But now the Electoral Commission in the UK has revealed that information on around 40 million citizens was exposed from August 2021 to October 2022. This includes everyone who was eligible to vote between 2014 and 2022 and includes their names and addresses, along with information sent to the commission in the form for email and web forms. https://www.bbc.co.uk/news/uk-politics-66441010 Very few details of the "complex cyber-attack" are given, but I bet, in the end, that it was the good old standard method of gaining a foothold in a system. The risk of insiders leaking information is significant in this type of breach, and the best firewalls in the world will not protect us from insider threats. The banks have realised that they now need 24x7 SOC support, and this would be the case in government. While the information leaked is possibly not that serious, there is a basic trust issue here, and where data was exposed for over a year, and it was not detected. Conclusions In response, the Commission has said that it would lock out hostile actors, which doesn't sound like a coherent plan to protect the data. I would hope encryption, and a zero-trust approach will also be used. Governments need to lead the way and not be stuck using the paper-based approaches of the 20th Century.

Blog: https://medium.com/asecuritysite-when-bob-met-alice/one-of-the-greatest-protocols-and-one-of-the-greatest-weaknesses-of-the-internet-meet-the-d8201a1e6e80 So the Internet isn't the large-scale distributed network that DARPA tried to create, and which could withstand a nuclear strike on any part of it. At its core is a centralised infrastructure of routing devices and of centralised Internet services. The protocols its uses are basically just the ones that were drafted when we connected to mainframe computers from dumb terminals. Overall, though, a single glitch in its core infrastructure can bring the whole thing crashing to the floor. And then if you can't get connected to the network, you often will struggle to fix it. A bit like trying to fix your car, when you have locked yourself out, and don't have the key to get in. As BGP still provides a good part of the core of the Internet, any problems with it can cause large scale outages. Recently Facebook took themselves off the Internet due to a BGP configuration errors, and there have been multiple times when Internet traffic has been "tricked" to take routes through countries which do not have a good track record for privacy. BGP does the core of routing on the Internet, works by defining autonomous systems (AS). The ASs are identified with an ASN (Autonomous System Number) and keep routing tables which allows the ASs to pass data packets between themselves, and thus route between them. Thus the Facebook AS can advertise to other AS's that it exists and that packets can be routed to them. When the Facebook outage happened, the Facebook AS failed to advertise its presence. Each AS then defines the network ranges that they can reach. Facebook's ASN is AS32935 and covers around 270,000 IP address ranges [here]. What is BGP? The two main interdomain routing protocols in recent history are EGP (Exterior Gateway Protocol) and BGP (Border Gateway Protocol). EGP suffers from several limitations, and its principal one is that it treats the Internet as a tree-like structure, as illustrated in Figure 1. This assumes that the structure of the Internet is made up of parents and children, with a single backbone. A more typical topology for the Internet is illustrated in Figure 2. BGP is now one of the most widely accepted exterior routing protocol, and has largely replaced EGP. Figure 1: Single backbone — Tree-like topology Figure 2: Multiple backbones BGP is an improvement on EGP (the fourth version of BGP is known as BGP-4), and is defined in RFC1772. Unfortunately it is more complex than EGP, but not as complex as OSPF. BGP assumes that the Internet is made up of an arbitrarily interconnected set of nodes. It then assumes the Internet connects to a number of AANs (autonomously attached networks), as illustrated in Figure 3, which create boundaries around organizations, Internet service providers, and so on. It then assumes that, once they are in the AAN, the packets will be properly routed. Figure 3: Autonomously attached networks Most routing algorithms try to find the quickest way through the network, whereas BGP tries to find any path through the network. Thus, the main goal is reachability instead of the number of hops to the destination. So finding a path which is nearly optimal is a good achievement. The AAN administrator selects at least one node to be a BGP speaker and also one or more border gateways. These gateways simply route the packet into and out of the AAN. The border gateways are the routers through which packets reach the AAN. The speaker on the AAN broadcasts its reachability information to all the networks within its AAN. This information states only whether a destination AAN can be reached; it does not describe any other metrics. An important point is that BGP is not a distance-vector or link state protocol because it transmits complete routing information instead of partial information. The BGP update packet also contains information on routes which cannot be reached (withdrawn routes), and the content of the BGP-4 update packet is: Unfeasible routes length (2 bytes). Withdrawn routes (variable length). Total path attribute length (2 bytes). Path attributes (variable length). Network layer reachability information (variable length). This can contain extra information, such as 'use AAN 1 in preference to AAN 2'. Routers within AS's share similar routing policies, and thus operate as a single administrative unit. All the routers outside the AS treat the AS as a single unit. The AS identification number is assigned by the Internet Assigned Numbers Authority (IANA) in the range of 1 to 65,535, where 64,512 to 65,535 are reserved for private use. The private numbers are only used within private domain, and must be translated to registered numbers when leaving the domain. BGP and routing loops BGP uses TCP segments on port 179 to send routing information (whereas RIP uses port 520). BGP overcomes routing loops by constructing a graph of autonomo

Blog: https://medium.com/asecuritysite-when-bob-met-alice/my-five-favouriate-least-favouriate-computer-programming-languages-dd8a560c27a I love programming and think that every child should be taught it at school at an early age — and, for me, coding is for everyone. As an artist uses paint and a canvas, programming allows me to practice my art — cryptography. I can then re-enforce my learning of theoretical methods into practice — and where the learning comes alive. It also allows me to script things that would be extremely time-consuming. With the Cloud, for example, I can open and close ports on a firewall with a simple Python script — and which allows me to avoid logging into a system and using a silly GUI (Graphical User Interface, aka browser) to perform a simple operation. Overall, I have taught programming in the past, but I have no desire to teach it as a subject on its own. Personally, I would rather teach cryptography or cloud computing and then show how code can be used to implement things practically. And, so, here are my favouriate programming languages and least favouriate ones. My Web site (https://asecuritysite.com) has a range of programming languages. Sometimes I pick the language because it is easiest to implement a given method, but other times I might only be able to find a certain method within a given implementation. And, so, you will find lots of Python, Golang, Rust, and JavaScript, but not so much for Java. You will not find so much on C#, but that is the core language that I use to build the Web site, so it's still one of my favouriate languages. The best for me? I know many people will disagree with me, but my five favouriate programming languages in order of how much I like them: Golang. It just always works for me, and no real problems in finding libraries. C is my natural programming language, and I just find Golang so intuitive in its structure and the methods it uses to compile programs. I also love a command-line approach to compiling programs, and which can provide an alternative to complex GUIs. For prototyping, it is great and produces executables which can work across different platforms. It is, though, very much a back-end programming language and will produce fairly dependable code. I particularly like it, as it loads its libraries onto my machine with a Git pull, and it gives me some satisfaction that I am pulling a fresh version of a library. C#/ASP.NET. It has (mostly) everything you need, and you can build systems in so many ways. With ASP.NET, we have a pure (M)odel, (V)iew and (C)ontroller approach and can properly code for the Web. I vividly remember changing from Microsoft Windows coding to ASP.NET, and it opened up a whole new world of Web coding. In less than a day, I covered 100s of thousands of C# code into an ASP.NET environment. Python. The syntax is a bit horrible and can break easily, but it's powerful and portable. It misses many things that I would think are natural, such as a proper for() loop and repeat … until(), but it is the fall-back language that many systems will use. As it is interpreted, it is fairly slow, and can lack a bit of robustness, but for its scope, its everywhere and can turn its hand from microcontrollers to cloud scripting. Rust. If we were to start programming all over again, we would use Rust and not C. We fell into a large trap in using C programs with its usage of memory pointers, and pointers to pointers. Rust teaches you good programming and how not to rely on the garbage collector to get rid of your variables that you do not use anymore. PowerShell. If you know C#, then you know PowerShell. While many think it is just tied to Microsoft Windows, it can now run on most operating systems. Basically, it is the command shell programming language that Microsoft Windows has always needed. But, watch-out, those cybercriminals can use it for bad purposes. It is a saint and a sinner. The worst for me? And my least favouriate: Java. So, sorry. I know it's one of the top computer languages around and extremely powerful, but Java has just passed me by. I think it is all the hassle of building class files and defining class paths, but it just doesn't work for me. JavaScript. Well, it has very little to do with Java, but I still don't like it. It is, though, extremely powerful and one of the few computer languages that can exist in the browser but also in the back (with Node.js). Many years ago, I predicted that JavaScript would die off as it was a horrible language and basically fossilised its version. But, I was wrong, and while Flash and all the other plug-ins for browsers have fallen, JavaScript has rebuilt the Web, and where code now runs in the browser rather than calling back to a server. And its version control is really terrible but powerful. With npm — its package manager — we have a quick way to install libraries, but also a convenient way for the delivery of back door trojans. And, for remembering the syntax? I have very li

Blog: https://medium.com/asecuritysite-when-bob-met-alice/the-wacky-world-of-javascript-and-npm-protecting-the-software-supply-chain-not-25662cfd1b66 JavaScript is the best and the worst of computer programming. It is able to exist in both the front end (the browser) and in the back end (with Node.js). It basically saved the Web as we moved from static Web pages to delivering dynamic content. With JavaScript, we could then enable direct interaction with the user but also capture and process data when required. It was a stroke of genius that allowed the same code in a Web page to be used on the back end (Node.js). But, it is sloppy language and rather unpredictable. Many love its methods, as a simple npm (Node Package Manager) can install the required software and libraries without any fuss: npm install crypgraphy But this simplicity can lead to problems. And, for Python, the pip command makes it easy to install libraries: pip install cryptography But these can lead to back-door trojans if an adversary places a back door in one of the associated libraries. Along with this, we can get typosquatting, and where a developer might type: pip install crypgraphy and download a malicious library. For this, an adversary needs to get their code onto one of the trusted repositories for JavaScript and Python. Protecting the supply chain The SolarWinds attack should act as a lesson in the importance of protecting the software supply chain, as backdoors can be applied to trusted software. For this, an adversary could either break into a trusted software system and add a backdoor in the software and then, with a compromised private key, sign the update as being valid. Also, an adversary could add a backdoor to open-source software that might go unnoticed when built. And, so, software languages tend to vary greatly in their control of libraries. With Rust, for example, we have Cargo, and which is a strongly versioned package manager. This will build a Rust program with a strict linkage of libraries to a given version — rather than taking the up-to-date version. All of the code is compiled strictly against versions of the binding to the code. Golang is less tightly defined and uses a git pull of the current version and stores it locally on a machine. A new git pull is required to update the version. The problem with npm and pip Now, it has been reported by Phylum that a new stealthy malware is spreading within npm [here]: With this, they reported on 31 July 2023 that there were suspicious activities on npm, and that 10 "test" packages were published. The research team found that they were part of a targeted malware attack — and which focused on exfiltrating source code and confidential information. This involved several iterations of updates before the final malware was constructed, as it shows that adversaries can focus on small incremental updates rather than showing the complete code at a single instance. This can allow malicious code to go undetected — and where the increments look like sensible updates. Overall, the packages had sensible-looking names —and an example of "npm typosquatting". A recent example included the creation of a package named "aabquerys", which is similar to the valid package of "abquery" [here]. With is it was found that it installs a legitimate EXE (wsc_proxy.exe) and which is digitally signed with a valid certificate but where is can be used as a side loader for malware. With a side loader, a valid and trusted program is run, but where it loads malicious code. In the malware version, a malicious file named wsc.dll is placed in the same place as wsc_proxy.exe, and which loads wsc.dll when invoked (Figure 1). Figure [here] And pip, too, does not have a great track record for protecting against malicious packages. A recent report from ReversingLabs involves the integration of the Python Package Index (PyPI) repository and includes the identification of 24 malicious packages that link to three popular open-source tools: vConnector, eth-tester and databases [here]. The target for these seems to be for cryptocurrency-focused developers. Conclusions Watch the versions of your code, as you could be a trojan for others. A backdoor compiler, for example, is one of the most difficult threats to detect, and it can infect a whole lot of systems that you may be responsible for.

Blog post: https://medium.com/asecuritysite-when-bob-met-alice/only-51-have-been-found-heres-mersenne-primes-4c296a3d8091 And, so what's the next number in the sequence 3, 7, 31, and 127? Well, it's 8,191, and I will explain why in a little minute. If you need to test with prime numbers — such as with public key encryption — how do you remember some large ones that you can test with? Well, one of the easiest ways is to remember the Mersenne prime numbers. Mersenne prime numbers were first defined by Marin Mersenne and who was a 17th Century French Minim friar. His main contribution included his investigations of prime numbers, along with being seen as the father of acoustics. A Mersenne prime is defined as a prime number that is one less than a power of two. The general form is M_n=2^n−1 where n is an integer. The discovery of 2¹¹²¹³-1 was even given its own postmark: The largest found is 2⁸²⁵⁸⁹⁹³³-1, and is the 51st Mersenne prime to be ever found). Since 1997, the Great Internet Mersenne Prime Search (GIMPS) distributed system has been used to find new Mersenne primes. From Wikipedia, here are the first 20: The Mersenne sequence becomes: 2, 3, 5, 7, 13, 17, 19, 31, 61, 89, 107, 127, 521, 607, 1279, 2203, 2281, 3217, 4253, 4423, 9689, 9941, 11213, 19937, 21701, 23209, 44497, 86243, 110503, 132049, 216091, 756839, 859433, 1257787, 1398269, 2976221, 3021377, 6972593, 13466917, 20996011, 24036583, 25964951, 30402457, 32582657, 37156667, ..., 77232917 ... Some code to discover these is [here]: import galoisimport sysn=2if (len(sys.argv)>1): n=int(sys.argv[1])print("Mersenne_exponents:", galois.mersenne_exponents(n))print("Mersenne primes:", galois.mersenne_primes(n)) and a sample run [here]: Mersenne_exponents: [2, 3, 5, 7, 13, 17, 19, 31, 61, 89, 107, 127, 521, 607]Mersenne primes: [3, 7, 31, 127, 8191, 131071, 524287, 2147483647, 2305843009213693951, 618970019642690137449562111, 162259276829213363391578010288127, 170141183460469231731687303715884105727, 6864797660130609714981900799081393217269435300143305409394463459185543183397656052122559640661454554977296311391480858037121987999716643812574028291115057151, 531137992816767098689588206552468627329593117727031923199444138200403559860852242739162502265229285668889329486246501015346579337652707239409519978766587351943831270835393219031728127] We can see that 2⁶⁰⁷-1 is 531137992816767098689588206552468627329593117727031923199444138200403559860852242739162502265229285668889329486246501015346579337652707239409519978766587351943831270835393219031728127. The FourQ Curve The core of the security you are using to access this page is probably provided with Elliptic Curve Cryptography (ECC), and where a session key is created through ECDH (Elliptic Curve Diffie Hellman). While there are a number of curves we can use, such as NIST P-256, Curve 25519 (as used in Tor) and Secp256k1 (as used with Bitcoin), there are some doubts about their security and their performance. And so Microsoft Research has produced the FourQ curve and which has 128-bit security. It is open source and runs efficiently on a number of platforms. At its core is the usage of the Mersenne prime of 2¹²⁷-1 [here]: In tests, the Microsoft team showed that FourQ was four or five times faster than the NIST P-256 curve, and two or three times faster than Curve 25519. As so we turn to the wonderful Cloudflare, and their Circl library. Within this, Cloudflare has implemented FourQ, and is [here]: package mainimport ( "crypto/rand" "fmt" "io" "encoding/hex" "github.com/cloudflare/circl/ecc/fourq")// 32 byte keys usedconst Size = 32 // type Key [Size]byte// From secret s, calculate public key (public=aG)func KeyGen(public, s *Key) { var P fourq.Point P.ScalarBaseMult((*[32]byte)(s)) P.Marshal((*[Size]byte)(public))}func Shared(shared, secret, public *Key) bool { var P, Q fourq.Point ok := P.Unmarshal((*[Size]byte)(public)) Q.ScalarMult((*[Size]byte)(secret), &P) Q.Marshal((*[Size]byte)(shared)) ok = ok && Q.IsOnCurve() return ok}func main() { var AliceSecret, BobSecret, AlicePublic, BobPublic, AliceShared, BobShared Key // Generate Alice's private key and public key _, _ = io.ReadFull(rand.Reader, AliceSecret[:32]) KeyGen(&AlicePublic, &AliceSecret) // Generate Bob's private key and public key _, _ = io.ReadFull(rand.Reader, BobSecret[:]) KeyGen(&BobPublic, &BobSecret) fmt.Println("Fourq key sharing") fmt.Println("Alice Secret: ", hex.EncodeToString(AliceSecret[:32])) fmt.Println("Alice Public: ",hex.EncodeToString(AlicePublic[:32])) fmt.Println("\n\nBob Secret: ", hex.EncodeToString(BobSecret[:32])) fmt.Println("Bob Public: ",hex.EncodeToString(BobPublic[:32])) // Determine shared keys Shared(&AliceShared, &AliceSecret, &BobPublic) Shared(&BobShared, &BobSecret, &AlicePublic) fmt.Println("\n\nBob Shared:\t", hex.EncodeToString( BobShared[:32] )) fmt.Println("Alice Shared:\t", hex.EncodeToString( AliceShared[:32] ))} With this, Alice produces her private key (a), and Bob produces his private key (b). We select

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

Blog: https://medium.com/asecuritysite-when-bob-met-alice/lesson-1-in-secure-programming-dont-reuse-your-ivs-5666ddfa9a1c I wrote up an article on a recent Samsung vulnerability [here], and one comment said … "it's an old bug, reuse of IV (Initialisation Vectors) seem a very basic problem". On the face of it, the comment perhaps doesn't go into enough detail, so I'll try and explain the "bug" and hopefully show that it is shockingly bad coding … almost negligent in terms of protection, and could even be seen as an intentional backdoor. And for a "very basic problem", it should perhaps be "extremely bad coding", and this "bug" should never, ever be seen within trusted environments. It shows an almost complete lack of knowledge in how cryptography works, with a novice vulnerability. The paper is here [1]: In fact, it's like WEP all over again, and where the WEP Wifi method had a small IV (Initialisation Vector), and when it rolled out, it was possible to just XOR cipher streams, and discover the plaintext. The asleep program could crack any Cisco access point in less than a day. Luckily we now use WPA-2, and which does not have the reuse of the IV. I hope to show that we should be worried if code such as this ever gets near a user's device. In fact, if there was ever a back door in a mobile phone, it could be this one. If you want to read about the "bug", try here: Crypto Bug in Samsung Galaxy Devices: Breaking Trusted Execution Environments (TEEs) If you use an Apple Macbook, it's likely that you have a secret enclave for important secrets — such as your encryption… medium.com A bad "bug" Now, I will explain how bad this "bug" is. If you are into cybersecurity, you should hopefully know that AES GCM is a stream cipher. With this, we take a secret key value and a salt value (an IV — Initialisation Vector) and generate a pseudo infinite keystream. Our plaintext is then simply XOR-ed with the keystream to produce our ciphertext: The salt value should then always be random, as a fixed salt value will always produce the same keystream for the same plaintext, and where we can reveal the keystream by XOR-ing cipher streams, and eventually revealing the plaintext. In the case of the key wrapping, the plaintext is an encryption key, and thus the encryption key used by the TEE will be revealed. If we reuse IVs, Eve will be able to XOR cipher streams together and reveal the keystream (K). From there she can decrypt every cipher stream, but simply XOR-ing the cipher stream with K. Coding AES GCM (Galois Counter Mode) is a stream cipher mode for AES. It is based on the CTR mode but converts to a stream cipher. This provides low latency in the encryption/decryption process and is fast to process. Along with this, it integrates AEAD mode for authentication. But as GCM is a stream cipher mode, it is open to a reuse IV attack. With this, the IV (Initialization Vector) of the cipher is the same for two cipher messages. We can then XOR to the two cipher streams together to reveal the cipher stream key (K). We can then reveal the plaintext by XOR-ing any cipher stream with K. So, let's try some code to do this. In this case, I will use Golang to show the basic principles of the method. I will use a static key in this case (as this would not change within the TEE) of "0123456789ABCDEF" (16 bytes — 128-bit key), and a static nonce of "0123456789AB" (12 bytes — 96 bits) [here]: package mainimport ( "crypto/aes" "crypto/cipher" "fmt" "os")func xor(a, b []byte, length int) []byte { c := make([]byte, len(a)) for i := 0; i c[i] = a[i] ^ b[i] } return (c)}func main() { nonce := []byte("0123456789AB") key := []byte("0123456789ABCDEF") block, err := aes.NewCipher(key) if err != nil { panic(err.Error()) } msg1 := "hello" msg2 := "Hello" argCount := len(os.Args[1:]) if argCount > 0 { msg1 = (os.Args[1]) } if argCount > 1 { msg2 = (os.Args[2]) } plaintext1 := []byte(msg1) plaintext2 := []byte(msg2) aesgcm, err := cipher.NewGCM(block) if err != nil { panic(err.Error()) } ciphertext1 := aesgcm.Seal(nil, nonce, plaintext1, nil) ciphertext2 := aesgcm.Seal(nil, nonce, plaintext2, nil) xor_length := len(ciphertext1) if len(ciphertext1) > len(ciphertext2) { xor_length = len(ciphertext2) } ciphertext_res := xor(ciphertext1, ciphertext2, xor_length) fmt.Printf("Message 1:\t%s\n", msg1) fmt.Printf("Message 2:\t%s\n", msg2) fmt.Printf("Cipher 1:\t%x\n", ciphertext1) fmt.Printf("Cipher 2:\t%x\n", ciphertext2) fmt.Printf("Key:\t\t%x\n", key) fmt.Printf("Nonce:\t\t%x\n", nonce) fmt.Printf("XOR:\t\t%x\n", ciphertext_res) plain1, _ := aesgcm.Open(nil, nonce, ciphertext1, nil) plain2, _ := aesgcm.Open(nil, nonce, ciphertext2, nil) fmt.Printf("Decrypted:\t%s\n", plain1) fmt.Printf("Decrypted:\t%s\n", plain2)} When we run with "hello" and "Hello" we get [here]: Message 1: helloMessage 2: HelloCipher 1: 7fcbe7378c2b87a5dfb2803d4fcaca8d5cde86dbfaCipher 2: 5fcbe7378cf8c68b82a2b8d705354e8d6c0502cef2Key: 30313233343536373839414243444546Nonce: 303132333435363738394

Blog: https://medium.com/asecuritysite-when-bob-met-alice/the-art-of-the-backdoor-e39f001ea8b9 Do you ever worry that your locksmith may take a copy of your key when they fit a new lock? Or that your locksmith has defined a lock which they know they have a skeleton key for? Or that your locksmith modifies the lock so that they can compromise it? And so we trust those that create locks to design them so that they cannot be broken easily, and that lock standard agencies around the world to set standards that promote good lock design, and, most of all, that locksmiths can be trusted to fit them without compromising them (and in giving us good advice). Introduction Well, let's look at software backdoors. Overall it's not an easy thing to put in a backdoor in a piece of software. Well, let me re-phrase that … "it is not an easy thing to put in a backdoor in a piece of software and for it not to be seen". Computer security is a serious business, but you must smile a little when you see the lengths that some intruders will go to in order to compromise systems. Organisations such as the NSA have long been accused of applying backdoors into cryptography software, but the recent Apple login hack shows that there are lots of opportunities for others to get in on the act. The addition of a backdoor in the Apple compiler showcased the opportunity for large-scale compromises. Overall there are a number of ways that a backdoor can be added to a piece of software: Escrow. In encrypted communications, one method is to keep of copy of the encryption key that could be used at some time in the future. Details [here]. Defining a standard that you know you can crack. The NSA and law enforcement agencies around the world have been accused of helping to define a standard and setting various parameters, and they know they have the methods to crack them. Source code addition backdoor. This is the typical way that an intruder would add a backdoor, and where the additional code is added which will perform a task that allows the source code writer back into the system. Normally the code is added by the writer, but then an intruder finds out the backdoor and can exploit it. Injected code backdoor. With these, packages such as Metasploit insert some additional code into the application, which allows it to work the same, but creates a backdoor connection. Normally this is a call-out method, where the program calls out to the malware writer. Compiler backdoor. This is the best method for going undetected, and where the compiler, itself, adds the additional code to every program which uses the compiler. In terms of a mass exploit, the compiler backdoor will have the greatest scope as it will exploit a wide range of applications. The executable will also be signed to verify that it is a valid application. Vulnerability and XSS exploit. This involves compromising a system in order to create a backdoor, typically injecting code into a running application which causes the system to open up a backdoor connection. The open-up of a network connection will obviously be detected on the system, but code writers have implemented a number of smart ways to cover this up, including passing secret passphrases for passwords, or with port knocking, where network packets are sent to a well-known open port, which then causes another port to open. A. Defining a standard you know you can crack A key focus for law enforcement is the cracking of cryptography, especially for tunnels and VPN connections. Devices created by Juniper were found to have a flaw which allows agencies to decrypt VPNs traffic. The company may have also used Dual EC (Elliptic Curve) DRBG (Deterministic Random Bit Generator) for generating the random numbers required to create VPN tunnels. This method, which was promoted by the NSA, has a known weakness and can be cracked. The possible backdoor in Dual EC DRBG has been known about since 2004, and the team who worked on it had the chance to plug the gap but failed too. It thus allows law enforcement agencies to crack SSL/TLS encrypted traffic which used the method for random number generation. It was thus assumed that no one would use the method, but, in Juniper's case, it has been found in some of their devices. In 2013, Edward Snowden showed NSA memos which indicated that the NSA had been the sole editor of the standard, whereas NIST responded that it did not deliberately weaken any cryptography standard. The following year, NIST recommended that companies stop using it, and withdrew it from its draft guidance on random number generation. In 2013, also, OpenSSL was found to be implementing the method, which allowed TLS/SSL connections to be decrypted. The back door in the standard for Elliptic Curve method for Dual_EC_DRBY caused a great deal of suspicion on the definition of NIST's P curve standards, and that they had selected them so they could have an advantage in breaking the public keys. Most of the industry has moved away from the P s

I often get asked about what makes a successful university spin-out, so here are my observation for any budding academic team looking to spin out: You need a solid academic base. A PhD programme is often an excellent base for a spin-out, as it involves three or more years of extensive study into every aspect of a given field. This involves both a macro and micro viewpoint of a problem, and it develops the skills that support the articulation of new knowledge and new discoveries. A great team, too, often has a foundation of both theory and practice. You need vision. Any company can innovate but fail to take things forward. A great team needs a visionary leader and who knows how to take something to the place which achieves this vision. They are a creator of a seed that is likely to sustain the company into its future. Build a team, focus on quality and keep them. I know it sounds obvious, but it's not easy to build a team in academia. There are too many barriers and academic structures that get in the way of team building. Try and create a team with complementary skills, and don't just build with a single focus on one skill. You need testers, coders, cloud scalers, documenters, presenters, and many other things. Try to always focus on the quality of your work and not quantity. Quality gets recognised, but quantity often does not. Anyone can produce a 100 research papers, but it takes a great team to produce a single groundbreaking paper. Get the right leader for the right stage. There are different types of leaders. Those who people respect for their technical expertise, those who understand how to make their offering to the market, and others who can scale a company. Get the right leader for the right stage — as they are often different people. Without a visionary, you will not need the next two leaders. Protect your IP. I know many dislike patents, but it's a dog-eat-dog world of innovation, and if you fail to protect your IP, others will come along and "borrow" from it or even "steal" it. Get a patent, if possible — not to attack others, but to defend yourself. The last thing you want is to licence your own invention from others. Abstract your ideas. While words are great, pictures and abstractions are so much better. Draw your ideas and concepts in a way that engages others. Research papers can be good. The importance of having peer review for any contribution to knowledge cannot be underlined enough, but, know that you have some IP protection in place and that you are further along the route than others in the development of your innovation. If your company wants to be a leader in its field, it needs to show that it has a strong scientific and technical base. And articulating complex thoughts in a research paper is a great way of showing that you have a core understanding of a field. Have a log book. I know this sounds trivial, but I have seen the difficult side of managing IP — when something becomes successful. It does no good in the future to say that you invented something when you have no real evidence. So, keep a log book and write down your thoughts as you develop your research, and get it signed by a trusted person (and with a date). I am still a fan of hardback log books and love it when a PhD student takes one along to meetings and jots down ideas. You need industry. A great invention will go nowhere without it being built at a production levels, and which matches to problems in the market. As early on, try to get industry involved, and focus the work. Build a team with theory and practice. Do not have one without the other. A great research team has the knowledge to ground the work in academic practice, but it needs practical skills to implement it. The leader is not the boss. The leader is not a role. The leader is whoever is sustaining the work. Research grants are a vehicle to sustain your vision. Unfortunately, many academics see research grants as isolated projects which must be implemented and delivered. They are routes to career advancement, and where they can tot-up their total grant income and display it as a KPI. But, are also stepping stones to your true innovation — each grant sustains the work and the team but takes you forward one little bit. Investors invest in people and not just innovation. Like it or not, investors are typically not investing in the great new invention but in the team that will take it forward. In most cases, this involves a break between the academic research and the spin-out. Four slide rule, always. You only need four slides: the problem, you and your team, your innovation, and how you will execute. Don't bore your audience; inspire them into your dream and vision, and listen to what they say. And, remember, it has a great simple opening slide — so dwell there as you introduce yourself and your vision. And end with a bang! Define the culture at an early stage. This might not seem to be a core focus, but it is important to lay out the ethics and morals of

There's one little program that I could not do my work without … Git. And, so, our digital world needs to say a great thanks to the wonderful Linus Torvalds. In fact, without him, our digital world would be a whole lot more locked-down and controlled by large and faceless companies. Without Linus, we would probably now be dominated by Microsoft Windows, and your car and your mobile phone would probably be running Windows for its interface (yuk!). And if the software in your car crashed — as it would likely do on a regular basis — you might possibly have to connect a keyboard to your instrument panel and press Ctrl-Alt-Del. Your TV, too, would possibly boot up into Microsoft Windows, and you'd need a mouse to control it. And our world of servers would possibly mainly be running on Microsoft IIS and use MS SQL databases. And, to back up your code, you would need a licence for Microsoft Backup 3.1, and where you dragged your folders over to make updates. Possibly, the command line terminal would have been dropped in favour of GUI (Graphical User Interface) approaches. So, just as in the famous advert from Apple in 1984 which illustrated the smashing of a Big Brother screen, Linus smashed the world of Windows — sorry for the pun! https://www.youtube.com/watch?v=2zfqw8nhUwA And, so rather than a world of Microsoft Windows, our world is full of Linux and associated distributions. For this, he wrote the first version of the Linux kernel and wrote the original version of Linux with pure machine code. I suppose there is something in the DNA for the Finnish people, that wants to be open about things, and not close them down with patents and restrictions. Git So, while the creation of Linux is possibly one of the greatest advancements in Computer Science. There is something even better … Git. With Git we have a version control system of code and documents. I use it every day, and it saves me so much time and effort. I use it in so many ways, including archiving my code and updating my Golang libraries. At its core is a smart way of keeping track of any version of a file and the difference between them. Linus wrote Git in 2005 for his Linux kernel but is now maintained by Junio Hamano. At its core, each host maintains a complete repository of all the files it has archived and how they have been modified. This differs from the client-server-based approach of code repositories, as the tracking can be done independently from a server. With Git, you end up with some commands that are hard-wired into your memory. We use "git add ." to add new files, then "git commit -m 'New update'" to search for changes in the files, and then finally a "git push" to upload the new versions. Then a "git pull" to get things back. Anyone who has ever lost their code or created a bad version will know the power of using Git to recover things. Three basic commands are thus: git add .git commit -m "My new update"git push But, it's not just code it can archive; it can archive many different document types, and it particularly likes mark-up documents such as LaTeX. Overall, Microsoft Word is terrible for version control, as the file is encapsulated in a Zip file. Many developers thus use LaTex and archive with Git. The great advantage of this is — just like Wiki's — we can trace the updates through text. It also allows us to easily share documents and allow collaborative work (as Git can keep a track of the update). And, for large files which are more than GBs in size there is Git Large File Storage (LFS) — git-lfs. And, so, if we were to start the Internet again, possibly LaTeX and Git would be used to create our documents, and we would have no Microsoft Word. In fact, we would probably not need Microsoft Windows, as our world would be open-sourced with the use of Linux. While Linux has always struggled to compete with Microsoft Windows and Mac OSX, it is open and free. The code for Linux, too, is open to all to examine and update. People often maintain open-source software as they have a real belief in its power and in how it frees us from the dominance of large and powerful companies. Not just for source code There are so many use cases of using Git that are not just versioning code. For my own teaching, I use Git to push my PowerPoint slides, source code and labs. Students can easily download the whole module at the start of the course and thus just to a "git pull" for any updates. Students, too, can mark typos in the material. You can find this at: https://github.com/billbuchanan/appliedcrypto Another interesting example is the District of Columbia and which publishes its laws through Git. This allows everyone involved to keep track of changes in the law and also spot errors and typos. If you are interested, the laws are marked up with XML and available at: https://github.com/DCCouncil/law-xml This, though, is the definitive source of the law, and not a copy from another system, and where a "pull request" allows someone to update a document,

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

Blog: https://medium.com/asecuritysite-when-bob-met-alice/tetra-burst-42773a490b35 Introduction Anyone can create a cipher. Basically, Bob and Alice do some modulo maths and could encrypt their secret messages into ciphertext by multiplying by 10 and adding 5, and then to decrypt back into plaintext, they would just subtract the ciphertext by 5 and divide by 10. The maths involved could then be defined by a Galois Field (GF)— and which is named after Évariste Galois. Bob and Alice could then keep their method secret from Eve (their adversary), and where they believe their method is secure and thus do not ask Trent to evaluate its security. But Eve is sneaky and tries lots of different ways to crack the cipher. Eventually, after trying to crack the ciphertext, she discovers the method, and can then crack all the future (and, possibly, previous) ciphers. Bob and Alice then carry on using the secret cipher method and would then have no way of knowing that Eve now knows their method. This approach is often known as "cooking your own crypto", and is not recommended in most implementations. Along with this, as Bob and Alice try to hide their method from Eve, the approach is "Security by obfuscation" rather than "Security-by-design". Cooking your own crypto There are many cases of propriety cryptography methods being used in production. In 2013, for example, researchers at the University of Birmingham found flaws in the key fobs related to the Volkswagen group vehicles. In fact, the encryption used in the Swiss-made Megamos transponder was so weak that an intruder only needed to listen to two transmitted messages from the fob in order to crack the key. The vulnerability related to the poor, proprietary cryptographic methods used by the device, and where the researchers found they could generate the transponder's 96-bit secret key and start the car in less than half an hour. The vulnerability has been well known since 2012, and code to exploit the flaw has circulated online since 2009. Yet, at the time, there was no product recall for the dozens of models that were affected, including Audi, Porsche, Bentley and Lamborghini, Nissan and Volvo. The research team were even stopped from publishing their work through the threat of legal action from Volkswagen. Testing, Evaluation and Standardization Along with the risk of discovering a secret method, the other major problem is that the method used to create a cipher is when it is not rigorously reviewed by experts. This can take years of reviewing and testing — both in the formal theory and in practice. Many companies, too, have bug bounties and which try to discover vulnerabilities in their code. To overcome this, NIST has created open competitions for the standardization of encryption methods. These have included standards related to symmetric key encryption (AES), hashing methods (SHA-3) and post-quantum cryptography (PQC). Once rigorously evaluated, the industry can then follow the standards defined, and where proprietary methods and implementations are often not trusted. With symmetric-key methods (where the same key is used to both encrypt and decrypt), at one time, we used a wide range of methods, such as DES, 3DES, RC2, RC4, Blowfish, and Twofish. To overcome this, NIST set up an operation standardization process for the Advanced Encryption Standard (AES). In the end, and after extensive testing and performance analysis, the Rijndael method was selected. It is now used in most systems, with either a 128-bit, a 192-bit or 256-bit encryption key. Overall, the larger the key size, the more difficult it is to brute force the key. The TETRA standard This week it has been reported that the TETRA (TErrestrial Trunked RAdio) standard [here] has a number of vulnerabilities in its cryptography. Overall, TETRA is used by many police and military forces across the world for encrypted radio. These vulnerabilities have existed for over a decade and could have led to the leakage of sensitive information. These vulnerabilities have been discovered by Midnight Blue and will be presented as "Redacted Telecom Talk" at Black Hat 2023 on 9 August 2023 [here]. As the work is so sensitive, there are many issues related to its disclosure, so the full details of the talk have not been released. But, it has involved over 18 months of responsible disclosure related to the cracking of TETRA-powered radios purchased from eBay. TETRA was first standardised by the European Telecommunications Standards Institute (ETSI) in 1996 and used by many radio manufacturers, such as Motorola and Airbus. It does not have open-source software and relies on cryptography which is secret and proprietary. TEA1 — Intentionally weak crypto Goverments around the world have generally used export controls on cryptography — in order to reduce security levels so that their own law enforcement agents have a good chance to crack encrypted traffic outside their own borders. One of the most famous was related to Netscape

Blog: https://billatnapier.medium.com/cryptography-fundamentals-elgamal-encryption-and-signature-2de5f16b1127 ElGamal methods: https://asecuritysite.com/elgamal Introduction In research, we build on the shoulders of giants, and Taher Elgamal is one of the giants of cybersecurity. His work on Netscape led to the creation of SSL, and for which much of our Web security is still built on. Along with this, he published this paper in 1985 [here]: It was true classic, and has been reference over 12,500 times. Within the paper, Tahir outlined an encryption methods and a digital signature method. His 'base' was to take John Napier's logarithm, and make them discrete. This discrete element meant that we only dealt with positive integer values, and where we worked within a finite field. This field was defined by a prime number (p). While the core ElGamal encryption method was overtaken in its usage by RSA, and then by ECC (Elliptic Curve Cryptography), the signature method was adopted as the Digital Signature Standard (DSS) by NIST. This has since scaled into ECC to become ECDSA, and which is used by Bitcoin and Ethereum. Tahir studied electrical engineering in the late 1970s at Stanford University. It was there he met Marty Hellman and who helped him spark an interesting in cryptography. He received his PhD in 1984 and it was Marty introduced him to Paul Kocker at Netscape Communications. Together, Paul and Tahir worked on a method to implement end-to-end encryption, and published SSL 3.0 in November 1996: Examples are at: https://asecuritysite.com/elgamal The ElGamal Method Befre we start we need to look at some of the basics of logarithms and where: {g^a}^b is g^{ab} and: g^a . g^b = g^{a+b} To make these discrete to add (mod p) in our operations and where p is a prime number. This constrains our integrates with a finite field, between 0 and p-1. In the ElGamal method, Initially, Bob creates his public key by selecting a g value and a prime number (p) and then selecting a private key (x). He then computes Y which is: Y=g^x (mod p) His public key is (Y,g,p) and he will send this to Alice. Alice then creates a message (M) and selects a random value (k). She then computes a and b: a=g^k (mod p) b=y^k.M (mod p) Bob then receives these (a and b), and then uses his private key (x) to decrypt the values and discover the message: M=b/(a^x) (mod p) With the divide by (a^x) we basically take the inverse of (a^x) mod p, and then multiply. The operation works because: ElGamal and Signatures With ElGamal signing, Alice has a public key (y,g,p) and a private key of a. She then takes a message m and creates a signature (r,s). This signature can then be checked by Bob. With ElGamal, Alice selects a generator (g), prime number of p and a private key of a. Her public key is then (y,g,p) and where y is: y=g^a (modp) To sign a message (m) we generate a secret random number (k) and we must make sure: gcd(k,p−1)=1 Next we compute: r=g^k (mod p) Next we compute: k^{−1} (mod p−1) and then: s=k^{−1}(h(m)−ar) (modp−1) The signature is then (r,s). Bob verifies the signature by computing two values: v1=y^r.r^s (mod p) and: v2=g^{h(m)} (mod p) If v1 is equal to v2 the signature has been verified. The proof is given here: https://asecuritysite.com/elgamal/el_sig2 While, ElGamal signing is not used these days, its method were applied into the Digital Signature Algorithm (DSA), and which was since been coverted into the Elliptic Curve Digital Signature Algorithm (ECDSA) method. Converting from discrete logs to elliptic curves In discrete logs we convert from: Y=g^a (mod p) to Y=a.G and where we have a exponential for discrete logs we have: Y = {g^a}^ b is equivalent to: Y=a.b.G and for a multiplication we have Y=g^a.g^b (mod p) = g^{a+b} (mod p) In elliptic curves we convert the multiplication to a point addition: Y = a.G + b.G = (a+b) G Converting from John Napier's Logarithms to Elliptic Curve Methods Around ten years ago, discrete log and RSA methods were riding right. But both of these methods have struggled with…medium.com This exponential becomes point multiplication, and multiply/division becomes point addition/subtraction. ElGamal and ECC But, Elliptic Curve Cryptography (ECC) methods are just everywhere just now. With ECC, we take points on a defined curve — such as Curve 25519 — and then perform point addition and subtraction. So how can we convert the ElGamal method into ECC? First, Alice first creates a private key (a) — and which is a random scalar value — and a public key (aP) — and which is a point on the elliptic curve. P is the base point on a curve. Alice's public key will then be: A=aP If Bob wants to send Alice an encrypted message (M), he creates a random value (k) and uses her public key (A) to produce a cipher message of: K=kP and then the next with: C=kA+M and where M is matched to a point on the elliptic curve. Now Alice receives (K) and (C), and computes: S=aK and then computes the message with: M=C−S As C and S will be

Blog: https://medium.com/asecuritysite-when-bob-met-alice/passion-leadership-and-responsibility-ded697c73c76 Introduction I have been involved in enterprise and innovation for quite a while. I love it, and where I have had the opportunity to think and dream and kick-start things that flourish in the future. Some things have worked, and other things have not. And, we have been so lucky to have spun out three highly successful cybersecurity companies, and each of which has come from a seed of an idea but has been built by great people. And I am so pleased that people like Professor Mark Logan are now introducing words like enterprise and innovation back into academic approaches, as, for too long, it was all about research. Overall, research will go nowhere without adding some innovation and then some enterprise to take it to places where real people find real uses for it. In academia, there can be game-playing, and where the impact factor of a journal or the number of publications in the year can be seen as having an impact. But, the real impact happens in the real world and away from citation counts and impact factors. And, for grants, it is not the income that matters; it is what the grant actually does. Know the market and your customer Over the years, too, I have seen many approaches to enterprise and innovation, and at the core of this is knowing what the problem is that you are solving and that there is a market in what you are creating — in crude terms, it is, "Know the market and your customer". Having a passion for what you do At the core of a great company is the genuine passion for what you do as an organisation. It should never be false passion — but genuinely, from the heart — we love what we do. And I've observed that great companies focus on the quality of what they do and never dwell on what they have at the current time. Leadership and responsibility, and removing committees and bureaucracy A great company, too, prizes leadership and responsibility, and where job roles have lesser importance than someone's responsibility. I have never liked committees and bureaucracy; they are often created through a lack of trust in individuals. Few committees ever make strategic decisions, and few committees ever innovate anything. And, so, to me, the best companies/organisations have leaders who are generally self-starters — they don't need to be prompted to do something — they just know it is right to progress something. These leaders, hopefully, should be instantly identifiable in your organisation, and who you could communicate with in an instance. Great leaders should not hide behind administrative support but actively engage with those who have questions about their approaches. Stop wasting time, and don't blame To me, companies should always try to break down these barriers to advancement and try to minimise the time in meetings. For me, I despair at the two-hour meetings with fixed agenda — and with a growing list of attendees. I've always found that time spent discussing will grow exponentially with the number of people in a meeting. The best meetings for me, as those which communicate things and have an open place to discuss any concerns, and then they finish on time. And great companies often do not pinpoint blame on individuals. They will investigate what went wrong but will never end up pin-pointing any individual. This approach allows individuals to feel confident that they can take responsibility without feeling that, if something fails, they will end up being blamed for the failure. My Bluffers guide to creating a great company/organisation So, here's my bluffers guide to creating a great company/organisation: Be passionate about what you do. Love your business. Understand the market and your customer's needs. Promote leadership wherever possible. Do not blame individuals for mistakes. Recruit amazing staff, look after them, reward them well, and keep them. Break down the hierarchy. Focus on responsibilities rather than job roles. Promote enterprise and innovation wherever possible. Remove bureaucracy wherever you find it. Remove committees wherever possible. Be agile, move fast and execute quickly. Small teams often work best. Support the generation of ideas from every part of the business. Praise success wherever possible, and allow others to share in the success. Know when something fundamentally isn't working, and stop it. And, the signs: There is a genuine passion in the company/organisation. There is a core focus on quality. Leadership drives the company. Leaders are highly visible to all and are self-starters. There is a common and shared vision. There is accountability in decisions. There is open communication for debate within teams/company. Success is communicated within teams and where teams genuinely feel proud of their achievements. Conclusions Avoid hooking up with a company or organisation with followers which is full of committees and line managers. Oh, and get the best HR pe

Related blog: https://medium.com/asecuritysite-when-bob-met-alice/tokens-jwt-and-google-tink-c6b915d387e8 And: https://billatnapier.medium.com/hmac-or-public-key-signing-of-jwts-64084aff10ef Introduction My Top 20 important things about JWTs: JWT is a JSON Web Token and is pronounced "jot". JSON objects support human-readable text and are used in many applications, such as with NoSQL databases. You should not trust a JWT unless it is cryptographically signed. For authorization, a captured JWT can be replayed and "played back" to provide a malicious entry or rights into a system. JWTs should never be trusted before their issue date and their not-before date and never trusted after their expiry. JWTs have been defined as an RFC standard with RFC7519. The format is URL friendly and is Base64URL encoded. A JWT token has three main parameters separated by a period ("."), and which are the header, the payload and the signature. The header is typically not encrypted and defines the signature algorithm ("alg") and the type ("typ"). The payload is typically not encrypted and uses a Base64 format. The payload can typically be seen by anyone who captures it. "ey" is a typical field starting part of a parameter in the header and body of a token as '{"' encoded in Base64 is "ey==". You can tell if a token is not encrypted with an "ey" as the start of the header and body parameters. The registered claims of a token are iss (Issuer), sub (Subject), aud (Audience), iat (Issued At), exp (Expires), nbf (Not Before), and jti (JWT ID). The claim fields are not mandatory and just a starting point for defining claims. A claim is asserted about a subject, and where we have a claim name and a claim value in a JSON format. With an HMAC signature, the issuer and validator must share the same secret symmetric key. If you use HMAC to sign the tokens, a breached secret key will compromise the signing infrastructure. The two main public key signing methods are RSA and ECDSA. The time of a token is represented as the number of seconds from 1 January 1970 (UTC). Each day of a JWT token is represented by 86,400 seconds. An unsecured JWT does not have encryption or a signature. This is bad! it is represented in the header parameter with an "alg" of "none" and an empty string for the JWS Signature value. A JWT can be encrypted (but this is optional). For public key methods, we can use either RSA and AES, or we can use a wrapped key. And a debate I've had with many development teams: What's a token? So, what's a token? Well, it is basically a way to encapsulate data in a well-defined format that has a signature from the issuer. For this, we either sign using HMAC (HMAC-256, HMAC-384 or HMAC-512), RSA signing or ECC signing. The HMAC method requires the use of a secret symmetric key, whilst RSA and ECC use public key encryption. The problem with HMAC is that if someone discovers the secret key, they could sign valid tokens. For enhanced security, we typically use public key encryption, where we sign with a private key and then validate with the public key. In this case, we will use Google Tink to create JWTs (JSON Web Tokens) and which are signed with elliptic curve cryptography. For this, we will use either NIST P-256 (ES256), NIST P-384 (ES384) or NIST P512 (ES512) for the curves. Overall, we do not generally encrypt the payload in JWT, so it can typically be viewed if the token is captured. JWT format A JWT token splits into three files: header, payload and signature (Figure 1). Figure 1: JWT format The header parameter The header contains the formation required to interpret the rest of the token. Typical fields are "alg" and "kid", and these represent the algorithm you use (such as "ES256") and the ID, representively. The default type ("type") will be "JWT". Other possible fields include "jwk" (JSON Web key), "cty" (Content type), and "x5u" (X.509 URL). An example header for a token that uses ES384 signatures and with an ID of "s5qe-Q" is: {"alg":"ES384", "kid":"s5qe-Q"} The payload parameter The payload is defined in JSON format with a key-pair setting. For a token, we have standard claim fields of iss (Issuer), sub (Subject), aud (Audience), iat (Issued At), exp (Expires At), nbf (Not Before), and jti (JWT ID). The claim fields are not mandatory and are just a starting point — and where a developer can add any field that they want. An example field is: {"aud":"qwerty", "exp":1690754794, "iss":"ASecuritySite", "jti":"123456", "sub":"hello"} The time is defined in the number of seconds past 1 January 1970 UTC. In this case, 1690754794 represents Sunday 30 Jun 22:06:34: The token signing parameter There are two ways to sign a token: with an HMAC signature or with a public key signature. With HMAC, we create a shared symmetric key between the issuer and the validator. For public key encryption, we use either RSA or ECDSA. For these, we create a signature by signing the data in the token with the private key of the creator of the token, and t

Blog post: https://medium.com/asecuritysite-when-bob-met-alice/noyce-moore-and-grove-a-template-for-spin-out-start-up-success-b67d9795154a Introduction So, is there a formula for a successful start-up/spin-out — and if you followed it, you would be guaranteed success? For this, many people approach me and say, "I want to have a spin-out. What should I do?". To me, this is a little like saying, "I want to fly, can you give me wings?". So, let me lay out a few things that I have learned over the past two decades of being involved in spin-out companies. Overall, we have been very lucky in our spin-outs, with three highly successful ones, and where two have been bought out (Zonefox and Symphonic), and the third is expanding fast within digital forensics (Cyacomb). But, as they say, "The Harder I Practice, the Luckier I Get". We have had failures, but every time our team has licked their wounds and come back stronger. And the one thing, though, I've observed is that the leadership of an innovative company often needs to change as it evolves, and those leading it need to know when they need to move aside and let others take their place. So, I'm going to define the three stages as: Visionary, Strategy and Grit, and where there are very different leaders at each stage. But, fundamentally, the first two stages set up the culture and approach of the company, and which are fundamental to its long-term beliefs and ideals. Overall, few companies in the third stage can turn their ship and travel in a different direction. The approach of IBM, for example, is still one of an engineering approach to their work and one built on rewarding innovation. Forgive me, I'm technical And, so I am a cryptography professor, and not a business one, so please forgive me for not covering the core literature in the areas of business. I am also highly technical, and that is what I love. I would never want to be a cut-throat business person and would never want to be. I love inventing things and seeing ideas grow from seeds. And one thing I know is when my role is complete as part of the innovation process and when to move aside. But, deeply technical people are at the core of creating a successful spin-out, along with people with a vision. And, so, I would like to lay out a basic template of my observations in creating a successful spin-out — and based on the ones we have produced. To me, also, a great technical company should have a core of theoretical work, and where the best work can come from academic collaborations. In academia, there is an attention to detail and theory, and which makes sense of the complex world of invention and discovery. But, the magic comes from practical implements, and where the best collaborations mix practice with theory. So, my basic template for success is to get the right leadership team in place, and get the right leader for the right time. A core part of this is knowing when the leader should move aside and let someone else take over. For this, I'll map it to the success of Intel and its first three employees: Robert Noyce, Gordon Moore and Andy Grove. Stage 1: Robert Noyce — the Visionary (1968–1975) If there's a superstar of our digital era, it must be Robert Noyce. Imagine inventing the one thing that now drives virtually everything in our digital age: the integrated circuit. It all started in the late 1950s with John Bardeen and Walter Brattain at Bell Labs and who first invented the transistor. William Shockley advanced the concept with the creation of the bipolar transistor. Bardeen and Brattain were a great research team and has a great balance of theoretical skills with practical ones. Brattain did the theory, and Bardeen did the practical work. All three eventually received a Nobel Prize for their work — with Brattain being one of the few people to ever get two Nobel Prizes. While Bell Labs was a hub of innovation at the time, Shockley wanted to take a good deal of the credit for the invention of the transistor and left Bell Labs to set up his own company in 1955: Shockley Semiconductor. For this, we recruited Robert Noyce and Gordon Moore to work on his ideas. But Shockley was a difficult boss and had an overbearing approach to his management style. This caused eight of Shockley's employees — including Robert Noyce and Gordon Moore — to leave the company and start their own venture with the support of Fairchild Camera and Instrument. It was there, in 1961, that Robert created one of the most significant patents of all time: It outlined a magical way of doping a semiconductor substrate and producing an integrated circuit: This invention differed from Jack Kilby's work at Texas Instruments, as Robert outlined a monolithic circuit while Jack defined a hybrid circuit approach. And, so, Fairchild grew fast as a leader in semiconductors, but as the company grew, Robert increasingly missed the days of true innovation and decided to team up with Gordon Moore to create Integrated Electronics (which would

Blog: https://medium.com/asecuritysite-when-bob-met-alice/a-soft-target-are-higher-education-infrastructures-at-risk-4ff323fd73c5 They helped build the Internet Academia was one of the first infrastructures to build and use the Internet — in fact, they built ARPANET and which morphed into the Internet. And so, you will find that they often have privileged IP address ranges, such as for Class A or Class B. With this, when IPv4 address ranges were initially given out, universities and research organisations were granted large address spaces to allocate to their growing networks. No one, at the time, could have ever envisaged in how much the Internet has grown since then. To make things easy, nearly every computer that was allocated a public address could be connected to directly — these were routable Internet addresses. To overcome these direct connections, firewalls filtered data packets and tried to stop malicious access. The Happy Phase of the Internet We might call this the "Happy Phase" of the Internet, where it basically interconnected trusted organisations and where there was no real concept of many people outside this trust circle having access to a computer. It was a new frontier in technological development and seemed to be a nice way to send emails between academics and researchers and to showcase their latest research work. By a public address, we have the concept that it is possible to route data directly to a computer. As you connect to this article, you are likely to be using a non-routable IP address, which is hidden between a NAT (Network Address Translation) router. These privileged academic address spaces supported public IP address spaces for thousands or even millions of hosts — and where a Class A IP address can allow over 16 million computers to have a public IP address. The University of California, Berkley, for example, has an IP address and subnet of 104.247.81.71/8, and where 104.0.0.0 is the network address, and where 24 bits in the address can be used for subnetworks and hosts. This means that the host part can be used to create subnetworks with an extension of the subnet field. Ultimately, a Class A address can give up to 16,777,216 publicly addressable hosts. And, so, while most organisations put their computers in private address spaces (though NAT), universities had enough IP addresses to allow many computers to be publicly addressable. In fact, at one time, an academic's desktop computer was likely be allocated a public address and could thus be directly contacted. And, so, as long as the computer was powered on, it could be addressable. Along with this, a log of any sites visited would leave a trace of the public IP address. In fact, it was all too common to add a DNS entry of Bob's computer as "Bob.uni.edu". But, this was all created in a time of little concern about cybersecurity, and it allowed academic infrastructures to grow dynamically — and under their own control. This was all set up before any real concept of requiring cybersecurity — as the networks were often just used to interconnect networks. So while other infrastructures have closed themselves to external threats, universities — in places — can still support legacy applications and have security support which ends after the working day. 24x7 Security Operations Centre I have observed the rise of the SOC (Security Operations Centre) in the finance industry — in fact, many of our graduates go into jobs that relate to this. I've also toured many of the SOCs in Glasgow and Edinburgh and love to see the fusion of data from inside and outside the companies. Basically, these companies had to move from being a Monday to Friday, 9am-5pm company to looking after security 24x7. But what about Higher Education (HE) as a sector? Well, I might be wrong, but higher education has not adopted the concept of 24x7 SOCs, and at 5 pm, many networked infrastructures hand over to support staff. There is very little in the way of sharing security resources across HE, too. Like it or not, our adversaries don't work 9–5pm (GMT), and are most likely to be on a different time zone in the world. And, so, we see the University of Manchester and the University of the West of Scotland (UWS) being subject to a cyber attack in the last few weeks, and this could be the start of a targeted offensive against network infrastructure with weaker support for security. The attack on the University of Manchester was part of a vulnerability around the usage of the MOVEIt protocol: https://medium.com/asecuritysite-when-bob-met-alice/the-moveit-zero-day-the-payroll-hack-dd4e7ceaeb92 Results The attack on the UWS site happened around 6 July 2023, and now it is suspected data from the breach where it is reported that the ransomware gang of Rhysida [here] is selling breached data to the highest bidder for 20 bitcoins (£450,000): The site went down for around a week, and it affected a range of internal systems. At the current time, it is thought that the brea

Related blog post: https://billatnapier.medium.com/cryptography-fundamentals-commutative-encryption-19ba4c4c2173 Introduction What's at the core of cryptography? Well, the simple EX-OR holds a special place, as we can do not lose any information when we apply it. For a bitwise operation of 0 EXOR 0 gives 0, 0 EXOR 1 gives 1, 1 EXOR 0 gives 1, and 1 EXOR 1 gives 0. And, so, cryptographers dream of the perfect cipher. And that cipher is a one-time pad. Basically, we generate a one-time use key for our plaintext, and then EX-OR them together, and then just EX-OR again with the same key and we will get our plaintext back. Unfortunately, we can only use it once and need to generate another one. So, let's see if we can generate something similar but just use the simple XOR method for our encryption and decryption. In the Tor (The Onion Router) network, data is encrypted with a key from each of the Tor routing nodes. Thus, if we have three nodes of A, B and C, with A as the entry node and C as the exit node. For this, the user will generate a separate key for each node to use and encrypt with the key of A, then the key of B, and then the key of C. The encrypted data is passed to A, and which will decrypt with its key, and pass the encrypted data onto B, and who will decrypt with its key. Finally, C will decrypt with its key, and the data will be decrypted. This protects the data as it is routed. But we have to remove the keys in the reverse order they were applied. One way to do this is with commutative encryption. Using a hasp When I worked as an electrical engineer, we had a hasp to isolate the electric power on a device we were working on: With this, each person who was working on the equipment, would put on their own padlock, and where we could not put the power back on, until all the padlocks had been taken off. The padlocks could be put on in any order, and taken off in any order, but there was no way to putting the power back on, until everyone had taken their padlock off. So how could we do this with data. Let's say that Bob, Alice and Carol want to apply their "data hasp", so that the data cannot be revealed until they have all taken off their padlock. Well, with symmetric key block ciphers, such as AES, we cannot do this, as we must decrypt in the reverse order of they keys being applied: To encrypt: Bob → Alice → Carol … and then to decrypt: Carol → Alice →Bob There are ways to do it with RSA, such as with SRA [here], but these methods significantly reduce the security of the process. The solution is to use a stream cipher, as we basically just X-OR the data when we are encrypting, and then X-OR again with the same key when we decrypt. We can apply multiple keys to the data, and in any order and it will always decrypt properly once we have applied all the keys. What we need with commutative encryption is to have an encryption string which is the same length as the data string. To make the encryption string, we can use an XOF (eXtendable-Output Functions) and where we can create a hash value of a given size. For this, rather than the fixed hash of SHA-3, we can use the SHAKE. Or with With BLAKE2b we have an XOF of BLAKE2XB, and for BLAKE2s we have an XOF of BLAKE2XS. We can then basically have a secret passphrase, and which generates an output which matches the length of the plaintext. Another method we can use, is to generate an pseudo infinitely long encryption key which is the same length as the plaintext — in the same way that a stream cipher works. A simple application: Booking a ticket With the ever increasing number of breaches, we are moving to a world where companies should not hold any personally sensitive information, as it is just too risky. So how could we create a trustworthy system, where someone can show up with a ticket, and where we can trust it, without actually revealing any personal information about where the person has booked their seat? So how can we generate a receipt of the booking, but not give away your identity, or the details of the booking? Let's take an example of booking a seat in a theatre at the festival, and how your privacy can be respected, but where the theatre will trust the ticket. Let's say there are 100 seats in a theatre, and I want to book one of them, but I don't want the theatre company to know which seat I've booked, or my identity. I also want a receipt of purchase that they can verify my booking. One way would be to get a trusted agent to look after the bookings, but I don't trust them either. So how can we do this? Well it can be done with commutative encryption. The steps would be: Initially the theatre company generates 100 receipts for each of the seats, and then encrypts them with its public key. Next when I want to make a booking they send me the encrypted receipts that they have left, and I select one at random, and then encrypt it with my public key. I send them all back, including the one I've encrypted. The theatre checks to see which one has be

Blog: https://medium.com/asecuritysite-when-bob-met-alice/can-privacy-and-traceability-exist-together-tracing-keys-and-jurisdictions-bfc395d502a Introduction Privacy and traceability are two sides of the same coin, and where the coin will never land on its side. If you want privacy in a transaction, you have to hide the payer and payee and the transaction value. All that needs to happen is that there is proof that the payer has enough currency to pay the payee. We can do this with a range proof — so that Bob can show that the sum of his previous transactions minus the current one is greater than zero. But, this stops any traceability and stops investigators from investigating the trail of an illegal transaction. It's a dilemma that can keep cybersecurity professionals awake at night and where a few bad apples can spoil the whole bunch. But, if we add traceability — such as in Bitcoin — we remove the privacy aspect, and if someone links your Bitcoin address to you and the others you trade with, they will be able to see all your transactions. "Ah, I see", they might say, "That Bill has just bought a ticket for a bus journey in Edinburgh at 10:03 am". Along with this, we have different requirements in different jurisdictions and where we might want to limit the investigator power in one jurisdiction to others. For this, John Gilmore — one of the original Cipher Punks — wrote: "We are literally in a race between our ability to build and deploy technology, and their ability to build and deploy laws and treaties. Neither side is likely to back down or wise up until it has definitively lost the race" And, so, the tension between strong cryptography, which protects privacy, and the ability to monitor and investigate remains as open as ever. In the UK, the Online Safety Act could aim to insert backdoors in cryptography in order to monitor communications. So, is it possible to keep things private but also make them traceable? For this, a new paper outlines the TRCT (Traceable Anonymous Transaction Protocol for Blockchain) protocol [1]: The focus of the paper is on the anonymous cryptocurrencies such as Monero, Dash and ZCash. It uses an Extractable Proof of Knowledge (EPoK) to produce a Zero Knowledge Proof (ZKP) for a transaction. This can then be added to the RingCT method of anonymity to produce traceable transactions for the participants and the amount transacted. The transaction, though, is still kept anonymous. The paper pinpoints the usage of Monero in a number of crimes, such as for the Wannacry ransomware attack and where the adversaries converted their Bitcoin rewards into Monero tokens [here], and which has not been since been traced. This problem has become so difficult for law enforcement that privacy-protecting cryptocurrencies have been banned in Canada, South Korea and Australia. TRCT An overview of TRCT is defined in Figure 1. With this, we have a miner which collects broadcasted transactions, and creates a consensus with other miners. An Authority is then responsible for linking account addresses and transactions and which can trace anonymous account addresses of the actual payer and payee and resolve the transaction amount. For TRCT, the payer generates a long-term key pair and then creates a one-time address (Figure 1). This can then be sent to the payer. The transaction is then anonymised for the payer address, payee address and transaction value using the Ring CT protocol, and which integrates the EPoK scheme. The miner then receives this and checks that it is valid and that the payer has enough currency in their account to make the payment. Next, the miner will check the EPoK so that it can be traced by the authority — and without discovering the secret details in the transaction. The authority can then trace the hidden content in the transaction (Figure 2). Figure 1 [1] Figure 2: [1] While applied in RingCT, the TRCT can be generally applied to any permissionless and permissioned blockchain, as it does not affect the underlying logic of the blockchain. In this, a trusted authority creates a tracing key and publicises its public key to the miners and whether these miners may be enabled or not for the integration of EPoK. In a permissioned blockchain, there are typically fewer nodes that create the consensus, and where it is thus easier to broadcast and update the tracing key. Overall, the authority is then used to oversee all the transactions, and decide whether there are illegal transactions, and also trace them. The control of the tracing key can then use attribute-based encryption to control its usage and using threshold-based sharing to control the usage of the key. For example, the FBI, CIA and GCHQ could agree on a 2-from-3 share approach, where two agencies have to come together to regenerate the tracing key. This approach allows for different jurisdictions to generate their own tracing key and where they cannot trace within any other jurisdiction. The addition of tracing tags also allow

Blog: https://medium.com/asecuritysite-when-bob-met-alice/did-you-buy-a-ring-doorbell-from-2015-to-2019-then-you-could-get-compensation-c8434916b2da I know the title sounds like one of those adverts that say, "Did you buy a car between 1890 and 2023, then you can get compensation, because they didn't tell you that you needed to put fuel in your car! In fact, you don't even have to have bought a car or bought anything; you just have to show that you are still breathing, and you might still also get it. Call us now! Before COVID-19, I used to demonstrate live at conferences the Ring doorbell and showcase weak practices. The video wasn't encrypted at all, and where I could easily view it. Along with this, user credentials were left unencrypted. But, after we went into lockdown, it was not so easy to give practical demonstrations, so I've not done a demo for a few years. But you will be glad to know that I'm all set up for hacks on electrical sockets, doorbells, kettles, door locks, and many other things, so if your company wants a demo, please get in contact. Overall, I have found that for the balance between useability/ease of setup, and security, most companies go for useability/ease of setup, as they know their users are often not that technical. Now, it has been shown that there are thousands of customers of the Ring doorbell that have been affected by cyberattacks. For this, Amazon will have to pay out $5.8 million in payments to around 55,000 customers for its weak data security practices. For this, it has been well known that some employees at Amazon had been spying on user videos: It was also found that there was no encryption on the video streams and that credentials were sent in a plaintext format. There were also attacks on previously breached passwords or in using repeated attempts at guessing credentials. Normally, this type of practice would be defended with a lock-out policy or by monitoring password usage, and which was weakly implemented. The case was brought by the FTC (Federal Trade Commission) in a federal court [here]: It is thought that 1,250 devices were breached with passwords, that the live stream was compromised, and that there were at least 20 cases that involved a breach of over one month. The suit outlines cases involving screaming obscenities, demanding ransoms, and threatening murder and sexual assault [here], and covers those who bought Ring doorbells between 2015 and 2019 — even if they have not been hacked. These will be used to pay for refunds for the doorbell and requires that Amazon delete all the video information gathered and any user credentials. Amazon will also have to inform the FTC about future incidents. Along with this, the FTC reported that Amazon failed to encrypt video streams from 2016 and 2020, along with no encryption for user credentials and details, and failed to get user consent for the viewing of video streams. Also, they failed to provide adequate training for their staff in supporting the Ring doorbell. In 2021, though, Amazon finally implemented encryption and proactive monitoring on the product [here]: Alongside this, Amazon will also have to pay $25 million for Alexa with the FTC Act and Children's Online Privacy Protection Act by retaining children's information without parental permission. Amazon will also be required to stop using geolocation, voice information, and children's voice information for any product improvement purposes. Conclusions When ease of use and usability are placed before cybersecurity, there's likely to be a storm brewing. I like Apple devices, as they seem to be able to span both sides of this. My demos for Ring, though, don't work anymore, but I've got many other things to showcase. Overall, one bad product implementation can taint a whole brand. Amazon needs to watch that its Ring doorbell doesn't give the company a bad name, as it has its e-commerce and cloud infrastructure to look after.

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

Related blog: https://medium.com/asecuritysite-when-bob-met-alice/mathematics-in-the-blood-the-lenstra-family-bf188c686e74 Introduction I know it's a strange question to pose, but which family has most advanced the Internet and Cybersecurity? Well, the Lenstra family has a strong claim to that title. From their Dutch roots, they have contributed so much to our modern world — both from a theoretical and a practical point of view. I suppose there's something in the nature of the Dutch that not only wants to solve real problems, but do it in a scientific way. That approach is also the beating heart of academic research — to take major problems and solve them through collaborative efforts, and where each researcher breaks solves part of the puzzle. The Internet — and in fact our modern world — has been created through the coming together of all the amazing work of researchers over many decades. Meet the Cryptography and Problem-Solving Brothers My grandfather was an electrician, and my father was one too. I suppose electrical things are in my blood. It was where I started my career, and I have always had a love for everything that relates to electrons. I must admit I gave myself a little too many electrical shocks when I was a child, as the temptation to take things apart just seemed too strong for me. And, it still amazes me that we often just take electricity — and all its applications in our modern world — for granted. Where would we be without our control of electricity and all things electrical? You certainly wouldn't be reading this article, now. So, sometimes, there's something in our blood that defines our future careers. And for the Lenstra family that was certainly the case, and from their Dutch roots, Hendrik, Arjen, Andries and Jan Karel have become important mathematicians. One of the most famous of the brothers for those who have studied networking is the mighty Jan Karel Lenstra (J.K. Lenstra) and whose many major breakthroughs include scheduling, local searches and the travelling salesman problem. We can thus all thank Jan for his work on routing problems, and which led to the creation of routing protocols on the Internet: The solving of the routing problem on the Internet, allowed the Internet to scale to levels that we see now, and where we have almost instant access to information from any part of the planet. We can thank J.K. Lenstra for providing that foundation. Arjen followed a cryptography focus for his work, including many classic papers such as those related to the factorization of polynomials and a famous paper entitled "Ron was wrong. White is right" [here]: But, Arjen's most cited paper included his brother (Hendrik W. Lenstra Jr.) as a co-author [3]: And, in these days of Microsoft Word and LaTeX, don't you just love the pen markup on the paper? The brothers also collaborated on another classic paper — and which included the mighty J.M Pollard [2]: Lenstra–Lenstra–Lovász (LLL) When the two brothers worked together they created some of their best work, and it was the classic Factorizing Polynomials with Rational Coefficients paper [3] that led to the Lenstra–Lenstra–Lovász (LLL) method [paper]. The paper also included mighty Laszlo Lovász [here] (who has an h-index of 109): This will use this method — defined as Lenstra–Lenstra–Lovász (LLL) — to crack the signature, and discover the private key used to digitally sign the message. This will search for the private key that has been used to sign a message with ECDSA. In this case we will generate two signatures, and then search for a private key. One of the most common signatures is ECDSA (Elliptic Curve Digital Signature Algorithm) and which is used with Bitcoin and Ethereum. With this, Bob creates a random private key (priv), and then a public key from: Next, in order to create a signature for a message of M, he creates a random number (k) and generates the signature of: The signature is then (r,s) and where r is the x-co-ordinate of the point kG. H(M) is the SHA-256 hash of the message (M), and converted into an integer value. If the k value is revealed for any of the signatures, an intruder can determine the private key using: This works because: and so: and for priv: We can then use the code [here] to implement a searching method based on LLL: import ecdsaimport randomimport libnumimport olllimport hashlibimport sys# https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/ G = ecdsa.NIST256p.generatororder = G.order()print ("Curve detail")print (G.curve())print ("Order:",order)print ("Gx:",G.x())print ("Gy:",G.y())priv = random.randrange(1,order) Public_key = ecdsa.ecdsa.Public_key(G, G * priv)Private_key = ecdsa.ecdsa.Private_key(Public_key, priv) k1 = random.randrange(1, pow(2,127))k2 = random.randrange(1, pow(2,127))msg1="Hello"msg2="Hello1"if (len(sys.argv)>1): msg1=(sys.argv[1])if (len(sys.argv)>2): msg2=(sys.argv[2])m1 = int(hashlib.sha256(msg1.encode()).hexdigest(),base=16)m2 = int(hashlib.sha256(msg2.encode()).hexdi

Related page: https://medium.com/asecuritysite-when-bob-met-alice/clocks-latex-byzantine-generals-and-post-quantum-crypto-meet-the-amazing-leslie-b-lamport-b2ade4b590d7 Demo: https://asecuritysite.com/hashsig/lamport Introduction I write this article in Medium and with its limited text editor, but I really would love to write it in LaTeX. Before the monopoly of Microsoft Word, there were document mark-up systems such as Lotus Manuscript, and where we had a basic editor to produce publishing-ready content. The GUI came along, and all the back-end stuff was pushed away from the user. For many, this is fine, but for those whose output is focused on sharing and dissemination of research, it is often the only way to work. In research, LaTeX is King and is a fully formed method of laying out — and sharing — research outputs. In the past few years, we have published over 100 research papers, and not one of them has been created in Microsoft Word. And for this, I thank Leslie Lamport. In fact, ask our kids about Newton, Faraday or Einstein, and they could probably tell you something about them. But ask them about Whitfield Diffie, Shafi Goldwasser, or Leslie B Lamport, and they would probably look quizzical? Their future world, though, is probably going to be built around some of the amazing minds that built the most amazing structure ever created … The Internet. To Leslie Lamport So, I am so privileged to be an academic researcher. For me, teaching, innovation and research go hand-in-hand, and where the things I research into gives me ideas for innovation, and which I can then integrate these things into my teaching. The continual probing of questions from students also pushes me to think differently about things, and so the cycle goes on. But, we are all just building on the shoulders of true giants, and there are few larger giants than Leslie Lamport — the creator of LaTeX. For me, every time I open up a LaTeX document, I think of the work he did on creating LaTeX, and which makes my research work so much more productive. If I was still stuck with Microsoft Office for research, I would spend half of my time in that horrible equation editor, or in trying to integrate the references into the required format, or in formatting Header 1 and Header 2 to have a six-point spacing underneath. So, for me, the contest between LaTeX and Microsoft Word is a knock-out in the first round. And one of the great things about Leslie is that his work is strongly academic — and which provides foundations for others to build on. For this, he did a great deal on the ordering of task synchronisation, in state theory, cryptography signatures, and fault tolerance. 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. Overall we use Overleaf, but we're not tie-in to that, and can move to any editor we want. But the process is just so much better than Microsoft Word, especially when creating a thesis. Word is really just the same old package it was in the 1990s, and still hides lots away, and which makes it really difficult to create content which can easily be changed for its layout. With LaTeX, you create the content and can then apply whatever style you want. 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 [here]: Byzantine Generals Problem In 1981, Leslie B Lamport defined the Byzantine Generals Problem [here]: And in a research world where you can have 100s of references in a paper, Leslie only used four (and which would probably not be accepted these days for having so few references): Within this paper, the generals of a Byzantine army have to agree to their battle plan, in the face of adversaries passing in order information. In the end, we aim to create a way of passing messages where if at least two out of three of the generals are honest, we will end up with the correct battle plan. So why don't we build computer systems like this, and where we support failures in parts of the system, or where parts of the system may be taken over for malicious purposes? And the answer is … no reason, it just that we are stuck with our 1970s viewpoint of the computing world, and everything works perfectly, and security is someone else's problem to fix. So, we need a system where we create a number of trusted nodes to perfor

Related material Main page: https://billatnapier.medium.com/cryptography-fundamentals-8-rsa-rivest-shamir-and-adleman-445b91932bd0 RSA: https://asecuritysite.com/rsa Introduction In August 1977, The Stranglers were in the music charts with "Something Better Change" and something really was changing, and it was something that would change the world forever. This was the month that Martin Gardner in his Scientific American column, posted a challenge of a method that has stood the test of time: RSA. It related to the work of R(ivest), A(dleman) and S(hamir) and was a puzzle on their discovery of a method which allowed two keys to be created, where one could encrypt and the other to decrypt. Their work had been based on a proposal from Whitfield Diffie and Martin Hellman on trapdoor functions that could be used to create the key pair. Mathematical Puzzles introducing RSA In order to explain the RSA concept, Martin's provided a background the Diffie-Hellman method for which he outlined: Then in 1975 a new kind of cipher was proposed that radically altered the situation by supplying a new definition of "unbreakable." a definition that comes from the branch of computer science known as complexity theory. These new ciphers are not absolutely unbreakable in the sense of the one-time pad. but in practice they are unbreakable in a much stronger sense than any cipher previously designed for widespread use. In principle these new ciphers can be broken. but only by computer programs that run for millions of years! Overall the Diffie-Hellman method has had a good run, but it has struggled in recent years to keep up with the processing power for computers, and the millions of years of running is not quite the case in the modern area, and where the original ciphers could now easily be broken with the simplest of computers within minutes. With the RSA method, Martin Gardner outlined: Their work supported by grants from the NSF and the Office of Naval Research. appears in On Digital Signatures and Public-Key Cryptosystems (Technical Memo 82. April. 1977) issued by the Laboratory for Computer Science Massachusetts Institute of Technology 545 Technology Square. Cambridge Mass. 02139.The memorandum is free to anyone who writes Rivest at the above address enclosing a self-addressed. 9-by-12-inch clasp. On receipt the requesters eventually (it took over four months in many cases) received a precious piece of history (Figure \ref{fig03}). RSA research paper It seems unbelievable these days, but the original methods were based on two 63-digit prime numbers that would be multiplied to create a 126-digit value: Contrast this with the difficulty of finding the two prime factors of a 125- or 126-digit number obtained by multiplying two 63-digit primes. If the best algorithm known and the fastest of today's computers were used, Rivest estimates that the running time required would be about 40 quadrillion years' A 256-bit number, at its maximum, generates 78-digits: 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665, 640,564,039,457,584,007,913,129,639,936 Web: https://asecuritysite.com/encryption/keys3 The 40 quadrillion years has not quite happened, and where 512-bit keys are easily broken in Cloud. If you are interested, here is a 512-bit integer value and which has 148 digits, such as: 13,407,807,929,942,597,099,574,024,998,205,846,127,479,365,820,592,393,377,723,561,443,721,764,030,073,546,976,801,874,298,166,903,427,690,031,858,186,486,050,853,753,882,811,946,569,946,433,6 49,006,084,096 web: http://asecuritysite.com/encryption/random2 The search for prime numbers, too, has been progressive since 1977, and by 2014, the world discovered a 17,425,170-digit prime number. The finding of prime numbers make the finding of them in the RSA method must easier. So the RSA method has been under attack for years, from both discovering prime numbers and also in factorizing. Along with this computing power has increased massively. If think that 40 years that have passed, and take a quick assumption that computing power doubles every year then we get: 1977 4 Quadrillion Years (4,000,000,000,000,000)1978 2 Quadrillion Year1979 1 Quadrillion Year…2020 227 years2021 113 years2022 57 years2023 28 years and if we get a GPU card with 4,000 processors, we take it to less than a year, and we get of few of them today into a cluster, and we crack it within one day! The FREAK vulnerability was actually caused by the limiting of RSA keys, due to US Export controls, to 512-bits. The factorising of prime numbers too has generated methods which can quickly find the prime number factors The Tension of Crypto and Academic Freedom Once Martin had published the article, the requests for the article came rushing in, especially as the paper had not yet appeared in the Communication of the ACM. Initially there were 4,000 requests for the paper (which rose to 7,000), and it took until December 1977 for them to be posted. Why did it take so long to get the p

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

Demos These are: Quadratic residues: https://asecuritysite.com/primes/q_res Jacobi symbol: https://asecuritysite.com/primes/jac Jacobi and Legendre symbol: https://asecuritysite.com/primes/jacobi Introduction Remember at school that class where the teacher taught you about how to square something? It was great, and where we loved to take the square of 3 and get 9, and the square of 5 gave us 25. But, in the next lesson, we came back to earth with a bump, as it was time for the nasty little square root. Now, we have to find two numbers which when multiplied together, gave us 121, or 196. Luckily, there was a convenient button on the calculator that give us our quick answer. In the time before calculators, though, working out more complex square roots involved tables of logarithms. And, so, in this podcast, I will outline a difficult problem … find a square root in a modulo n world … aka quadratic residues. A hard problem In cryptography, we look for hard problems to solve. For this, we can create a backdoor into the problem and solve the problem. With discrete logarithms, we have a hard problem of: Y=g^x (mod p) and where it is difficult to determine x, even though we know g, Y and p, but as long as the prime number if large enough. Another hard problem is used in the RSA public key method, and this involves the difficulty in factorization at modulus (N) which is made up of two prime numbers. Another hard problem is quadratic residues modulus n, and uses the form of: x²=a (mod p) and where we must find a value of x which results in a value of a (mod p). If a solution exists, the value of a is a quadratic residue (mod n). In modular arithmetic, this operation is equivalent to a square root of a number (and where x is the modular square root of a modulo p). In the following, we will try and solve for the value of x, and also generate the Legendre symbol value. For example, if we have a=969 and p=1223, we get: Solve x²=968 (mod 1223) [Ans: 453] Try! and: Solve x²=1203 (mod 1223) [Ans: 375] Try! Thus 968 and 1203 are quadratic residues modulo 1223. The form of x²=a (mod p) is not always solvable. For example, if we have a=209 and p=1223 , we get: x²=209 (mod 1223) Also, if a shares a factor with p it is also not solvable. For example: x²=39 (mod 13) will return a zero value for x. If we take a value of p=53, we get the following values [here]: 0, 1, 4, 6, 7, 9, 10, 11, 13, 15, 16, 17, 24, 25, 28, 29, 36, 37, 38, 40, 42, 43, 44, 46, 47, 49, 52 A sample run of the code gives: Quadradic residue (mod n) solver a: 47 p: 53We need to solve for: val^2 = 47 (mod 53 )-----------------------Result: 10( 10 )^2 = 47 (mod 53 )-----------------------For a prime number of 53 here are the residues up to p (or 100)1 4 6 7 9 10 11 13 15 16 17 24 25 28 29 36 37 38 40 42 43 44 46 47 49 52 In this case, we see that 10 is a possible quadratic residue for a p of 53. The solution is thus: 10²=47(mod 53) You can see a demonstration here and here are some examples: Solve x²=12 (mod 13) [Ans: 8] Try! Solve x²=968 (mod 1223) [Ans: 453] Try! Solve x²=1203 (mod 1223) [Ans: 375] Try! Solve x²=47 (mod 53) [Ans: 10] Try! Solve x²=209 (mod 1223) [No solution!] Try! Solve x²=888 (mod 1223) [No solution!] Try! Solve x²=39 (mod 13) [No solution!] Try! Legendre symbol In science, it is difficult to avoid Adrien-Marie Legendre, as there are so many things named after him: Fourier–Legendre series; Gauss–Legendre algorithm; Legendre chi function; Legendre duplication formula; Legendre–Papoulis filter; Legendre form; Legendre polynomials; Legendre sieve; Legendre symbol; Legendre transformation; Legendre wavelet; Legendre–Clebsch condition; Legendre–Fenchel transformation; Legendre's constant; Legendrian knot; and Gamma function–Legendre formula. And, so, where does Legedre help with your online security? Well, you will find his method used in elliptic curve methods, which are used to protect your online identity, and the security of the communications that you have with this Web page. So, let's look at the Legendre Symbol. For this, we turn to Legendre who, in 1798, defined the Legendre symbol. In the following, we will try and solve for the value of x, and also generate the Legendre symbol value [link]: Solve x²=12 (mod 13) With his method, we can determine that the answer is 8, as 64 (mod 13) is 12. Some sample code is [here]: import sysimport libnumdef legendre_symbol(a, p): ls = pow(a, (p - 1) // 2, p) return -1 if ls == p - 1 else lsn=11if (len(sys.argv)>1): n=int(sys.argv[1])print ("Here are the Z*p (quadratic residues modulo n and coprime to n):")print ("\nJacobi symbol")for a in range(1, n): rtn= libnum.jacobi(a,n) if (rtn==1): print (a,end=', ')print ("\nLegendre symbol")for a in range(1, n): rtn= legendre_symbol(a,n) if (rtn==1): print (a,end=', ') A quadratic residue relates to the solving of the form: y=x² (mod n), and where we need to find values of y for different values of x and for a given modulus (n). For n=11, we get Z∗p={1, 3, 4, 5,

Please note, I slippled up a little in the podcast, and where the army size if 187,000. I have updated below. Web page: https://billatnapier.medium.com/cryptography-fundamentals-6-chinese-remainder-theory-ctr-2d1874943f15 And so a large army met. The general asks the collected troops to arrange themselves into groups of 50. He counts that there are four troops left without a group. He then asks for groups of 60, and there are 14 left, and finally, he asks for groups of 70, and there are 24 left. The general stands up and tells the army that they are 201,554 strong. So how did the general do it? >>> army%50 4 >>> army%60 14 >>> army%70 24 >>> print (army) 187000 Solution: https://asecuritysite.com/principles_pub/crt02?val1=4,14,24&val2=50,60,70 The Chinese remainder theorem was first published by Chinese mathematician Sun Tzu. It determines a number x so that, when divided by some given divisors, leaves given remainders. As public key encryption typically involves this type of operation, CRT is well set up to help to crack encrypted messages. So what value will x equal in the following [Soln]: x mod 3 = 2x mod 5 = 3x mod 7 = 2 The answer is 23, as 23 divided by 3 gives 21 remainder 2, 23 divided by 5 gives 4 remainder 3, and 23 divided by 7 gives 3 remainder 2. CRT and RSA If we capture enough RSA encrypted messages with the same e value and different modulus values (N), we can crack the message using the Chinese Remainder Theorem (CRT). For example, if we have an e value of 3 we just need to capture three cipher messages to be able to recover the message. In this case, we will use the following (where p1 and q1 generate N1, p2 and q2 generate N2 and p3 and q3 generate N3): e=3, message=123456789123456, p1=1131701, q1=1131721, p2=1131727, q2=1131737, p3=1131749, q3=1131751 The run then gives: eGCD of N values: 1N1= 1280769787421 N2= 1280817319799 N3= 1280858062499Message= 1234567891234 e= 3Cipher1= 184224238921 Cipher2= 173356604414 Cipher3= 369941826218 The equations we have to solve are then: M^e mod 1280769787421=184224238921M^e mod 1280817319799=173356604414M^e mod 1280858062499=369941826218 If we now use Chinese Remainder Theorem we get a result of: Result (M^e) is: 188,1676,377,431,587,319,857,436,861,793,600,904 And then we just use: 10^(log10(M^e)/e) and recover the message of 1234567891234 Try here. A more detailed example is [here]: N1= 20439437 N2= 20684303 N3= 20830087Message= 1500000 e= 3Cipher1= 6509102 Cipher2= 9683741 Cipher3= 3214286 =======Equations to solve=======M^e mod 20439437=6509102M^e mod 20684303=9683741M^e mod 20830087=3214286 ======Chinese Remainder Theorm Calc========Result (M^e) is: 3375000000000000000 Calculated value of m is 1500000 Using 10^(log10(M^e)/e) We can also use: M=res**(1.0/3.0)M=libnum.nroot(res,3) CRT is good, sometimes? Well, in RSA, we can use Chinese Remainder Theory to simplify the decryption process. We will cover this in more detail when we look at RSA encryption. For now, all we can say that for RSA keys we also generate values of dQ, dP and InvQ to use CRT to speed up decryption. Other attacks CRT is a widely used cracking technique in cryptoanalysis. Werner Schindler [here] defined a timing attack on RSA which involves a factorization on the RSA modulus if CRT has been used. The work goes back to 1996 when Arjen Lenstra defined an attack against an optimization (called the CRT). If a fault was generated in calculating a signature (using RSA-CRT optimization), the attacker could recover the associated private key from a signature. This is known as the "RSA-CRT key leak". Many systems have been immune from this attack as TLS did not use an RSA signature. Unfortunately, the forward security option in TLS is now being recommended, and this has re-introduced the problem. Researchers at Red Hat [here] also now found many Web sites which were not hardened against this type of attack and found quite a few with RSA-CRT key leaks (none of which were code repositories). They found that the private key of a Web site can be leaked to the intruder, who can then decode all of the encrypted communications with the site and also impersonate it. Forward secrecy is used with a key-exchange method and uses a session key which derives itself from a given set of long-term keys and which will not reveal the session key even in the long-term keys are breached. How do we protect against this? There are two ways to defend against this attack. The first is to make sure that e always exceeds the copies of messages that can be copied, and the other is to pad messages with random bits. In most applications, now e is 65,537.

Cryptography Fundamentals 5: GCD, Extended GCD and Group Generators This podcast will outline a few building blocks of cryptography: GCD (Greatest common divisor), extended GCD and group generators. These you will find in many related cryptography papers, and any weaknesses in these can cause significant problems to the overall security of a method. Greatest common divisor— GCD A fairly simple concept that is used within public key encryption is the greatest common divisor (GCD). With this, we take two integer values and determine the largest factor that they are. Overall, every non-prime number is made up of the multiplication of prime numbers. For example: 32,128 = 2 x 2 x 2 x 2 x 2 x 2 x 2 x 251 36,281 = 7 x 71 x 73 So, the GCD of 56 and 42 is 14, as both of the values can be factorized into 4 x 14 and 3x14, respectively. https://asecuritysite.com/principles_pub/gcd Normally we use this function to find values which do not share a factor, as we will see when selecting the public exponent (e) in the RSA method. The method to determine the GCD is fairly simple, and where we take two values (a and b) and use the modulus operation to find the GCD: def gcd(a, b): while( b != 0 ): Remainder = a % b; a = b; b = Remainder; return a;g = gcd(679,99)print g A sample run shows that 679 and 99 do not share any factors: a:679, b:99, Remainder:85a:99, b:85, Remainder:14a:85, b:14, Remainder:1a:14, b:1, Remainder:0Return value:1 Web: https://asecuritysite.com/encryption/gcd Extended GCD GCD is the greatest common divisor. For two integers (x and y), the extended GCD method solves ax+by=v for a and b, and where v=gcd(x,y). One example of using the Extended GCD method is to determine the modulo inverse of a value (the inverse value of n (mod p) so that: n⋅n^{−1}=1 (mod p) ). 30a+20b=gcd(30,20). Soln: a=1, b=−1. Try! 35a+15b=gcd(35,15) . Soln: a=1, b=−2. Try! Group generator In reading about cryptography, have you ever come across the term of a cyclic group G of order p and with a generator g? With a discrete log mapping, we map x to Y with Y=g^x (mod p) where we have a generator value (g) and a prime number p. The challenge is that even though we know Y, g and p, it is extremely difficult to determine the x value if we use a large prime number. But can we use any value of g, and should it be as large as possible? The answer to both of these questions is no. If we select a prime number of 11, and then select g values of 2, 3, 4 …10, and then calculate the results we get [spreadsheet]: Now look at g=2 and p=11, for 2¹ (mod 11) we get 2, 2² (mod 11) we get 4, 2³ (mod 11) we get 8, and so on. As we see {1,2,3,4,5,6,7,8,9,10} gives {2,4,8,5,10,9,7,3,6,1}, and where all the input values give a 1-to-1 mapping to another value in the group. But if we try g=3 and p=11, we get x=1 gives 3, and for x=6 also gives 3. The mapping is now {1,2,3,4,5,6,7,8,9,10} to {3,9,5,4,1,3,9,5,4,1}, and so we are not using the full range, and where there would be a confusing for mapping back to our original value. But, in order to demonstrate the principle, I have done this in a long-handed way, so how do I find out all the possible values of G for a given prime number (p)? Well, here's a nice simple method in Python that I created to test up to p): import sysdef issafe(g,p): exp=1 rand=g next = rand % p while (next != 1 ): next = (next*rand) % p exp = exp+1 if (exp==p-1): return True else: return Falsep=11g=4if (len(sys.argv)>1): p=int(sys.argv[1])if (len(sys.argv)>2): g=int(sys.argv[2])print ("Is g={0} safe for p={1}? {2}".format(g,p,issafe(g,p)))print ("x\tg^x\tg^x (mod p)")for x in range(0,10): print ("{0}\t{1}\t{2}".format(x,pow(g,x),pow(g,x,p))) A sample run with an unsafe value is: Is g=3 safe for p=13? Falsex g^x g^x (mod p)0 1 11 3 32 9 93 27 14 81 35 243 96 729 17 2187 38 6561 99 19683 1 and where the only output value is 1, 3 and 9. For a safe value, we get: Is g=3 safe for p=17? Truex g^x g^x (mod p)0 1 11 3 32 9 93 27 104 81 135 243 56 729 157 2187 118 6561 169 19683 14 So, how does this work in practice? Well, rather than picking the prime number and then finding a g value which will work, we typically pick the g value we want, such as for g=2, g=3 or g=5, and then find a prime number of a given size to work with that value. This will slow down the process, as we might have to pick a few prime numbers before we find one that will work. An example command in OpenSSL to generate the Diffie-Hellman parameters for g=3 and a 512-bit prime number is: openssl dhparam -text -3 512DH Parameters: (512 bit) P: 00:ff:1a:a6:fd:94:1b:55:8c:03:e0:ba:91:d5:e3: 23:40:6a:8e:49:a1:d4:d9:dd:68:3f:10:3d:ff:a7: a6:8e:2f:9f:f9:3f:4d:dc:3d:54:71:e0:aa:65:dc: 24:03:42:73:39:db:d6:02:a6:dc:bd:ac:49:12:a8: dc:d0:57:d9:bf G: 3 (0x3) https://asecuritysite.com/openssl/dh

We live in a legacy world of money. Our transactions are often still based on moving paper money around, and we have basically scaled this into a digital world. At the core of this is the lack of any real cryptographic trust in digitally signing transactions. For this, the Bank of England is now discussing a CBDC (Central Bank Digital Currency) [2]: And before you reach for Ethereum smart contracts and ERC tokens, there's a catch. This is not actually a cryptocurrency, but an electronic payment system. Basically, it will basically be a digital currency, and thus link these coins to a digital wallet which is held by a trusted payment entity (such as a bank or payment provider). The overall proposed architecture is to use a central bank ledger, which validates transactions. This would not contain any personal data on users and integrate at an API level. Access to this API for users would be through intermediaries — trusted and regulated payment providers. Users would not be able to interact with the core ledger without using an intermediary. Figure 1: Platform model [2] CBDC model To transfer funds in a traditional way, Alice contacts her bank and enables a transfer to Bob's bank. The transaction basically involves account numbers and sort codes and is transferred through a trusted payment gateway. This is identified with the purple line in Figure 2. In the CBDC model, Bob and Alice will own a digital wallet in their bank, and where Alice can move digital tokens from her wallet to Bob's. Overall, Bob and Alice can move money between their bank account and their digital wallet. The moving of their funds into the digital wallet gives lesser control of funds than the maintenance of bank accounts. Figure 2: Traditional payment v cryptographic payment In a traditional cryptocurrency system, Bob and Alice have a public blockchain wallet that contains their private key. In Ethereum, we transfer ERC20 tokens using a digital wallet. This digital wallet contains the private key to sign off the transaction. A smart contract then maintains a table of the owners of each of the ERC20 tokens issued. This relates to the wallet identifier as a hexadecimal address. This is identified as the red line in Figure 3. Figure 3: Cryptocurrency transaction using ERC20 tokens (red line) The state-of-the-art There are several existing models for a CBDC, including Project Hamilton, and which is a collaboration between the Federal Reserve Bank of Boston (Boston Fed) and MIT [1]: The targets are for a minimum of 100,000 transactions per second and for 99% of all transactions to be completed within five seconds. There should be no loss of funds in the event of a data outage, and privacy is a fundamental part of the design. An important element of the design is the use of intermediaries and custody. In terms of trust, we have intermediaries — such as banks, and payment service providers — and which are custodians of the digital wallet. But there is the opportunity for customers to own their own digital wallets — as with an Ethereum wallet. The model can then be "direct" — customer-to-central bank, or "two-tier" — central bank to intermediatory (Figure 4). Figure 4: Two-tier model — central bank to intermediatory The proposed method decouples fund checks with transaction validations. Funds are stored as a 32-byte hash value with an Unspent funds Hash Set (UHS) — Figure 5. The transaction has a similar format to Bitcoin. Figure 5: Unspent funds Hash Set (UHS) Economic concerns The speed of the transactions and the ease of access to digital currency could enable economic risks Reduced lending opportunities As the digital coins are moved to a wallet, they will thus be out of the control of a bank, which means that they could not lend the money to another person — which kinda defeats one of the main functions of a bank. If too much of this money was moved to wallets, it could cause the lending system to stall. Bank runs There have been many occurrences of runs on banks, including with Northern Rock. With this, customers queued to get access to the funds, and which generally slowed down the pressures on withdrawals. With a digital pound, this could be made much worse, as customers could withdraw their funds with a simple transfer. Banks could thus risk a run on their funds. Cybersecurity? Generally, we trust our banks to look after our money. With a digital wallet, attackers could target hacks, which could have lower levels of control on access to the wallet. A core part of the Bank of England's strategy for the digital pound is to develop resilience in both the technical and financial disuptions involved [2]: Technical challenges The enablement of a CBDC brings many technical challenges. Privacy and auditability There is a significant balance between privacy and auditabilty. The use of zero-knowledge proofs will allow for privacy within transactions, but this will hide the sender and recipient of a transaction. This privacy, though, can restrict

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

I will bet you, that you have a memory of school where you had the "pleasure" or, most likely, the "nightmare" of performing long addition or long subtraction, and where you had carry overs between columns. The units carried over in the tens, the tens into the hundreds, and so on. And, then, you encountered long multiplication with those ever growing list of numbers. And, please forgive me, you progressed to long division, and you had that divisor dividing into your number and with the bar along the top, and where you put your result, and which those pesky remainders. "Oh, teacher, 61 divided by 9 is 6 remainder 7". And, didn't you love throwing away that remainder and just making the answer 6. But, in cryptography, the remainder is the bit we like, and we throw away the other bit. So for us, 61 mod 9 is 7. So, just take a pause now to just calm yourself for those memories. If you want to leave now, please do so, as we will revisit some of these memories, but, hopefully, we will make things a whole lot more simple. To these additions and multiplications in an electronic circuit or some software code can take many operations. But, just imagine a world where you did not need to carry over values from one column to another, and even where all you had to add or multiply was a 0 and 1, life would be so much easier, and these school nightmares would end for you, and life would be so much happier for your kids in learning maths. For example, if we have a binary adder we have 0+0=0, 1+0=1 and 1+1=0. As we see a simple binary adder just throws away that pesky carry. If we add 1+0+1+1+1+0, we see an answer of 0. But in our normal maths, to add 7+4+3+9+8 requires us to add up the units, and carry over in the 10s column. For simplifying things we turn to Évariste Galois. Évariste Galois — who lived from 1811 to 1832 — died of duelling wounds at the age of 20 but left a great legacy. While he was a teenager, he worked on polynomials and laid down the principles of Galois's theory — along with defining the concept of a finite field. Creating the reverse operation As we have seen from the previous podcasts, we have values in a group, and then can operate on these to get another value in the group. So, if we have a group of 0 to 16, we can constrain our values with a (mod p) operation, and where p is a prime number. For example, if we use a prime number of 17, and we take a value of 2 and then raise that to the power of 5 and take the mod of 17, to get 15: >>> pow(2,5,17)15 For all of the values from 0 to 16, we should (hopefully) get different mappings for the output. This will then allow us to reverse back by taking the inverse operation to the modulo power. This, as we have seen from a previous podcast, is to subtract one from the prime number (PHI=p-1), and perform an inverse of the base modulo of the prime number minus one. A simple Python program gives us the result for the inverse: >>> pow(5,-1,16)13 If we now multiply our result of 15 by 13 and take (mod 17), we magically get our value back again: >>> pow(15,13,17)2 In this way, we aim to reverse our mathematical operations, and where there is no confusion about the reverse operation. Simplifying things Up to now, we have seen that we have operated on our normal arithmetic operations for the (mod p) such as add, subtract, multiply and divide, but we can simply things even more if we have a field which has 2^n elements, and where if n is 8, we can have 256 elements. 256 elements, for example, is the number of values we can have for a byte of data in a computer system. If so, we can convert our bit values of our integers into a polynomial, and then operate on them as polynomial operations, such as: (x²+1)+(x) = x²+x+1 This, as we will see, significantly reduces the complexity of our arithmetic operations, and rather than have complex circuits for adding (with carry overs) and multiplying (and where we end up with a value which has more bits than the inputs values), we constrain the calculation within our finite field. Along with this we then just need simple 1-bit adder or multiplication operation. So from complex adding and subtraction circuits in hardware or with software operations, we end up with simple bit operations. This vastly increases the speed of our cryptographic operation. This is a Galious field, and defined more generally as GF(p^n), and where p is a prime number. But, in most cases, p will be 2. Arithmetic operations Within a finite field, we limit the number of possible values in a group. As we have seen this can be a prime number and where we get a group from 0 to p-1, and where we can perform our mathematic operations with the (mod p) operation. And, so, even though we have a finite field, we still want our maths to still operate as normal. The rules for every element in the group is: Commutative law. This is where (a+b) equals (b+a), and (a*b) equals (b*a). Associative law. This is where a.(b.c) is equal to b.(a.c). Distributive law. This is where

In previous podcasts, I outlined the usage of discrete logarithms in the form of a=g^x (mod p). Unfortunately, we now need a relatively large prime number to make sure it is now possible to discover x from a, g and p. This slows down the creation of the discrete log value. One method which has been used to replace them in some applications is to use elliptic curve points. Later in this series, I will explain how elliptic curve cryptography actually works, but in this one, we will just look at the fundamentals of the elliptic curve points. So what is a group in elliptic curve cryptography (ECC)? Well with this, we will map one group of points to another with a one-way function, and which should be difficult to reverse or find the method we have used to perform the mapping. As we will find, the basic operation is to either add two points in a group to create another point in the group or to double the point to get another point. With these simple operations, we should be able to perform point multiplication. The method of ECC was created independently by Neal Koblitz and Victor Miller. So, how did I create this mapping? Well, a basic elliptic curve has the form of: y² = x³ + ax + b For y² = x³ + 7 If x=1, we get: y² = 1+7 and where y is the square root of 8, which is 2.82. But, in cryptography, we only deal with integers, so we must modify this with a modular form of: y² = x³ + ax + b (mod p) For example, if a is zero, b is 7, and the prime is 11, we get: y² = x³ + 7 (mod 11) The possible points are (2, 9) (2, 2) (3, 1) (3, 10) (4, 4) (4, 7) (5, 0) (6, 5) (6, 6) (7, 3) (7, 8). e can try it, and where: 9² (mod 11) = 4 and 2³+7 (mod 11) = 4 https://asecuritysite.com/ecc/ecc_pointsv?a0=0&a1=7&a2=11 As we see, not all the points for an x-coordinate value are possible. This then leads to the order, which is the number of valid x-axis points — which is 6 in this case. W Point double and add In ECC, we then add points together (P+Q) or double them 2.P and get a new point. With this, it is difficult to reverse back the addition or doubling and find the original point. For y²=x³+7 (mod 11) The valid points are (2, 9) (2, 2) (3, 1) (3, 10) (4, 4) (4, 7) (5, 0) (6, 5) (6, 6) (7, 3) (7, 8). Now let's take a point of (2,9) and add another point. So this, we get: https://asecuritysite.com/ecc/ecc_points_add3?a0=2&a1=0&a2=7&a3=11 P1=(2,9) P2=(2,9) P1+P2=(5,0) P1=(2,9) P2=(3,1) P1+P2=(4,7) P1=(2,9) P2=(4,4) P1+P2=(3,10) P1=(2,9) P2=(6,5) P1+P2=(4,4) P1=(2,9) P2=(7,3) P1+P2=(3,1) and so we see when we do a point add, we always get another point on the curve, but where it is difficult to reverse back to the points which resulted in this point. Multiplying points So, can we multiply points in an efficient way? Let's say we have G, and want to add it to itself n times. We could represent this as n.G. For this, Peter Montgomery created a method known as the Montgomery Ladder. The basic method is: N ← P Q ← 0 for i from 0 to m do if di = 1 then Q ← point_add(Q, N) N ← point_double(N) return Q For a=100 we have a binary value of 1100100: 1100100, thus we double the point (N=2G). 1100100, thus we double the point (N=4G). 1100100, thus we add the point (Q=4G), and then double the point (N=8G). 1100100, thus we double the point (N=16G). 1100100, thus we double the point (N=32G). 1100100, thus we add the point (Q=4G+32G=36G), and then double the point (N=64G). 1100100, thus we add the point (Q=36G+64G=100G), and then double the point (N=128G). The result is then Q=4G+32G+64G=100G. Overall, the great advantage of this method is that we will always take the same time to compute the answer, no matter the size of the value of n. This is useful, as some cryptographic operations leak information from the time they take to compute the result. The only problem here is that the double point and point adding will have a different amount of time to compute than just the point double, and where Eve could determine if there was a 0 or a 1 in the value of n. https://asecuritysite.com/ecc/ecc_kr2 Public key encryption So how is this used in public key encryption? We first pick a base point (G) on the elliptic curve. For our example, we could pick (2,9). Next, we then pick our private key (sk). Our public key is then pk=sk.G, and where G is added to itself sk times. Our private key is thus a scalar value, and our public key is an elliptic curve point. We use this in terms of digitally signing a message, and where the private key (sk) is used to create a digital signature, and the public key validates it. The most popular methods for this are ECDSA (Elliptic Curve Digital Signature Algorithm and EdDSA (Edward Digital Signature Algorithm). I will explain these more in a future podcast. Conclusions And, so, for our elliptic curve, we don't always have a valid (x,y) point, but for our Weierstrass curve, sif we do, we end up with two y values for every x coordinate. With our points, we conduct two simple operations, a point addition and a point doubling.

A fundamental element in cryptography is the mapping of one group to another and then being able to map back again. In this, there should be no confusion about the mapping and where it should be deterministic in the mapping — that is, no matter how many times we do it, we will always create the same mapping. Obviously, we can add some randomisation into the process, but with the same randomization, we always get the same mappings. In the previous podcast, I showed how a group of A={1,2,3,4} will map to B={2,4,3,1} using a mapping of b=g^a (mod p). We see that every element of A has a one-to-one mapping from A to B. We then aim to have a mapping back from B to A, and recover the original value. Arithmetic operations And, so, encryption (the mapping of A to B) can become a mathematical operation, and then where the decryption (the mapping of B to A) is basically just the reverse of our encryption process. And, so, remember those puzzles as a child. Think of a number. Now add 10 and double it. Take away 7. Add 5, and half it. The answer is 9. Of course, this is a trick, and where we get: [(2(x+10)-7+5)/2]-x =[(2x+20–7+5)]-x = [(2x+18)/2 ]-x= [x+9]-x = 9 For this, we are basically just reversing back the method we quote in the track. And so, for encryption, we could multiply by 9, and add 14 to get our cipher value. To decrypt, we would reverse the operations so that we subtract by 14 and then divide by 9. But, in cryptography, we have a finite field in our group and thus use the (mod p) operation to constrain our integers. Luckily, all our arithmetic operations still work if we use the modulo of a prime number. Adding and subtracting Let's try to add, with x=8 and y=12, and use a prime number of p=11. If we do: (x+y) (mod p) is it the same as x (mod p) + y (mod p). And, so: 8 (mod 11) + 5 (mod 11) = 13 (mod 11) = 2 Now we will try: (8+5) (mod 11) = 13 (mod 11) = 2 So can we now subtract b from the result? 2–5 (mod 11) = -3 (mod 11) = 8 Thus if we had an operation to add to values in a group and then reverse them. This goes for modulo multiply and then divide. Multiplying and divide Now let's try to multiply and divide. For this, we will multiply our values by four modulo 5. This will get: >>> (1*3)%53>>> (2*3)%51>>> (3*3)%54>>> (4*3)%52 We ignore the zero for the set in A, as we will always get the same result. Thus we map {1,2,3,4} to {3,1,4,2}. Now we need to divide by three modulo 3. For this, we create the inverse mod of the value and then just multiply. This is basically: a/b (mod p) = a* b^{-1} (mod p) Basically, it is the value of x which will make this true: b.x (mod p) = 1 This x is thus the multiplicative modular inverse value of b. So, let's find the inverse of 3 (mod p): >>> pow(3,-1,5)2 Note that the pow(x,y,p) function is x^y (mod p). Thus to divide by 3 (mod 5), we multiply by 2. Let's try it: >>> (3*2) % 51>>> (1*2) % 52>>> (4*2) % 53>>> (2*2) % 54 and so we get our original values back. Thus we use an inverse mod to reverse a modulo multiplication. Exponentiation And, so, we can see that adding, subtracting, multiplying and dividing work with the modulo operations. Let's try exponentiation. For this, we can have: b = a^x (mod p) If we try x=3 and p=5, we get: >>> (1**3) % 51>>> (2**3) % 53>>> (3**3) % 52>>> (4**3) % 54 Thus {1,2,3,4} maps to {1,3,2,4}. But what about the reverse? Well, we need to use an inverse log modulo p function. With this, as in the RSA (Rivest Shamir Adleman) public key method we find a value for a^x (mod p) so that: x*y (mod PHI) = 1 and where PHI is (p-1). Now we compute: >>> pow(3,-1,4)3 So we can go ahead and now reverse and find the inverse log for {1,3,2,4} (mod 5): >>> pow(1,3,5)1>>> pow(3,3,5)2>>> pow(2,3,5)3>>> pow(4,3,5)4 And, so, we have reversed our modulo logarithm. Overall, the magic of PHI is at the core of the RSA method and where we can reverse the exponentiation operation. For this, we have a cipher of: C= M^e (mod N) and then can reverse with a value of d which is computed from: d = e^{-1} mod PHI and where PHI is (p-1)(q-1). We recover the message with: M=C^d (mod N) In this case, we actually have two prime numbers (p and q), and which are multiplied together to give the modulus (N). Conclusions And, so, all we need to constrain our mathematical operations on our groups is the (mod p) operation.

The problem with cryptography is that many miss some fundamental knowledge that will allow them to fully understand the key operations that are used. So, in this series of blogs, I try and explain some of the core concepts that secure our online world. Every single time that you connect to the Internet, the privacy and trustworthiness of your connection are dependent on some magical cryptographic operations. In our world of numbers, we have N (natural numbers — positive or negative integer values), Z (integers), R (real numbers) and C (complex numbers). for this. Natural numbers can go from minus infinity to plus infinity, while integers constrain these into a ring. A ring might be from 0 to 16, and the 17 goes back to 0, and so on. If we go to -1, that is 16, -2 is 15, and so on. For cryptography, we use the Z double-struck or blackboard bold symbol, where we typically define a group of numbers. For this, we represent Z_n as the numbers from 0 to n-1. So, Z_7 is {1,2,3,4,5,6}. There is another group we use; the multiplicative group of integers modulo n Z_n*. This excludes the values which are a factor of n. Z_7 will be {1,2,3,4,5,6} Z_{12}* will be {1, 5, 7, 11} [here] [Note: In the podcast, I said Z_16* and which will be: {1, 3, 5, 7, 9, 11, 13, 15}. 16 is 2x2x2x2, so any value with a factor of 2 in it will not be included. I will outline this in a future episode.] So a group is basically a set of integers, and where we map from one group to another one. If we think about two sets A and B, and then create a mapping between the numbers in A to B, and vice-versa. For encryption, we want a 1-to-1 mapping from every value in A to B, and then for us to be able to reverse back from B to A. So, if we have a set of numbers of A={1,2,3,4} we might map these to B={2,4,3,1}. If we have a value of 1 in A, it will map to a 2 in B. Then, in B, we would map back from 2 to 1. In cryptography, we typically want to make it easy to go from A to B (encrypting), but difficult to go from B to A (decrypting) — unless we know a secret. In this example, I have used a discrete logarithm mapping with a base generator of g and a prime number: b=g^a (mod p). For the mapping of {1,2,3,4} to {2,4,3,1}, I have used g=2, and a prime number of 5. b = 2¹ (mod 5) = 2 (mod 5) = 2 b = 2² (mod 5) = 4 (mod 5) = 4 b = 2³ (mod 5) = 8 (mod 5) = 3 b = 2⁴ (mod 5) = 16 (mod 5) =1 This will be cyclic, and where {1,2,3,4,5,6,7,8} will map to {2,4,3,1,2,4,3,1}. For this, we have constrained within a finite field of between 0 and 4 (or p-1). We can see that this gives us a 1-to-1 mapping for each of the elements of our first set to the other set. Every value in B can be reversed back to its original value in A. To reverse, though, we would need to compute the inverse log of the value in B for mod p — this is not so easy: a =log_g(b) (mod p) And this is the core difficulty of the discrete logarithm problem. It is this problem that secures the Internet. To show you the difficulty of this, if I use a prime number of 2²⁵⁵-19 and a g value of 2. You will find it extremely difficult to find the x value I have used for: b=25446473684081445734643481619349383496577344937808306324243206897292518839288 If you are interested, the answer is a=431342352456346734652345427573451341234132414341365756845234234234523 In Python, here's the solution: >>> a=431342352456346734652345427573451341234132414341365756845234234234523>>> p=2**255-19>>> g=2>>> b=pow(g,a,p)>>> print (b)25446473684081445734643481619349383496577344937808306324243206897292518839288 So, watch out for the next podcast…

How did you get started in this industry? What are the three key tech/software tools that you depend on the most? What is your favouriate book or podcast? What is the most important thing you have learned in your career? What advice would you give your younger self? Who inspires you?

Steve is a Professor of Cyber Security in the School of Computer Science at the University of Nottingham, as well as an Adjunct Professor at Edith Cowan University in Western Australia and an Honorary Professor at Nelson Mandela University in South Africa. He is also the Chair of Technical Committee 11 (Security and Privacy Protection) within the International Federation for Information Processing, as well as a board member of the Chartered Institute of Information Security and chair of the academic partnership committee. His main research interests are broadly linked to the intersection of human, technological and organisational aspects of cyber security. Within this, specific themes of interest include the usability of security technology, security management and culture, cybercrime and abuse, and technologies for user authentication and intrusion detection. Related to this, he has authored over 330 papers in refereed international journals and conference proceedings, as well as various books, chapters, and professional articles. https://www.nottingham.ac.uk/computerscience/People/steven.furnell

Never in the history of humankind have we advanced so fast. In just 40 years, we have built a new era and have said goodbye to the industry age. But will our future be an amazing world of opportunity where every citizen has the same opportunity as any other, or will we end up in a 1984 Big Brother world? At the core of this is the debate around privacy. Bruce Schneier sees this as a core element in building our digitally focused societies: "Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect. It is about choice, and having the power to control how you present yourself to the world." and: "Google knows more about what I'm thinking of than I do, because Google remembers all of it perfectly and forever." and for our new digital world: "One hundred years ago, everyone could have personal privacy. You and your friend could walk into an empty field, look around to see that no one else was nearby, and have a level of privacy that has forever been lost." In my career, there was a time before I read Secrets & Lies … and there was a time after I had read it. It completely changed my focus. In fact, no other author (apart from George Orwell) has had an effect on my thoughts on the future world: Bruce showed me a vision of the most trusted world. He made public key encryption interesting, and I could immediately see how cryptography could be used to rebuild our flawed digital world. I now teach and research cryptography, and I love the subject. I thank Bruce for taking me away from network switching and routers and showing me the beauty of a subject where you learn every single day.

We live in a strange world of cybersecurity. An auditor might ask a company if they encrypt their data? And the company may reply that they do, and so the auditor would tick that off. But encryption does not just involve the privacy of data; it also involves integrity checking and setting up digital trust. Along with this, there are many ways to implement methods, including key derivation, public key integration, hashing methods, and encryption modes. And, so, last week I outlined how some AES modes can be easily modified. And so, someone asked me why I recommended GCM (Galois Counter Mode)? Well, GCM integrates integrity into the cipher. It is built on CTR (Counter) mode and is a stream cipher. This makes it fast. Along with this, we can add additional data into the ciphertext — and which defends against playback attacks. At the core of this is the Galois Message Authentication Code (GMAC).

In cybersecurity, you get those who pedal snake oil, and others that just try to scare you. The gap is that the advice is not given in an educated way, and basically just scares people (or gets them to buy the latest security product). These days, the chances of someone cracking your password from a hashed version is likely to be minimal. For one, the chances of getting access to the hashed version of a password is extremely low, and for two, the password is typically stored in a way that will make it extremely costly — such as requiring the cost of electricity to boil a lake (or loch, in Scotland) — to crack it. But, still, we get them from those who aim to "educate" (aka "preach") us on Cybersecurity. Telling us not to share our passwords or to not click on spear-phishing links are better approaches than asking us to use long and complex passwords. As humans, we kinda lose it once we go over 10 characters. And, HashCat, too, knows all our little tricks for passwords (eg we typically always have one upper case letter and put it at the start) — where so-called complex passwords can be just as easy to crack as short and simple ones. And, too, the days of Microsoft Windows XP are past, but some still think we are living in that world. These days, even Microsoft uses encrypted passwords with a slow hashing method. Linux, too, uses the best of breed for its password hashing, and where it would cost you your mortgage for a single brute force password crack. The industry has moved on — and has learnt from its mistakes, but some are still stuck in the past. Ask anyone who has forgotten their Bitcoin wallet password — and I get continual questions from many people about this — about how difficult it is to recover it through brute force methods. A nine-character password, for example, on a Bitcoin wallet will take you over 59 million years — and inflation is likely to have made your Bitcoins worth very little — and you will be dead! Link: here

The worm is turning! C and C++ have ruled the core of our digital world for a long time and still do. But, they do not handle memory well, where we get buffer overflows (Morris Worm, SQL Slammer, and so many more) or buffer underflows (Heartbleed). This can involve a stack overflow attack, and where the program writes too much data to the stack that has been allocated for a given buffer, and for a heap overflow attack, where we overrun the memory into a space that is not allocated for a buffer. These problems often allow adversaries to write data into places that it was not intended for or can cause an exception in the handling of the code (and thus cause a problem to act unreliable). A typical area is to overwrite memory that is allocated for other purposes and then cause a Denial of Service (DoS) against the code — and where it just stops working. Along with this, developers often do not clean up their variables, so a garbage collector must come in and free up memory that is not being used anymore. But, Rust just doesn't allow you to do these things. It has strict checks on the usage of variables at compile time, and if you do something bad with them, it will tell you and refuse to compile the code. In 2015, Rust was born, and in eight short years, many of the major software companies have adopted it as the core of their systems. Google was one of the early adopters but is now joined by Microsoft, who are developing their core code with Rust. But, there are many questions … how long will it take to learn the language and will it make developers more productive? The following relates to research conducted in Google which answers these questions [here]. For this, Google did a survey of 1,000 of their developers. Some Rust and Cryptography is [here].

We are human, and, like it or not, we lie. Why? Because we might not want to admit to some truth, or where we might want to seem knowledgeable. It is a human attribute, and it defines us. Overall, our intelligence weighs up the cost and reward and makes a decision as to whether we should tell the truth or not. Ask a child about who eat a biscuit, and there's a chance they will lie because they do not want the punishment or do not want to tell tales about their friend. And so, as we go through our lives, we all lie, and sometimes it gets us in trouble; sometimes, it saves us from punishment; and sometimes, it makes us look smart. Overall, lying is a weakness of our character, but, at other times, it is our intelligence showing through and making good guesses. At the core of this is often trust, and where someone who lies too much becomes untrustworthy, and if someone lies about someone else for a malicious reason, they can taint their own character. One of the least liked human attributes is where someone lies about someone else. But what about machines, can they lie? But, a machine lying is a little like you getting asked, "who won the match between Manchester United and Grimsby Town?" If you don't know the answer but want to look smart, you might "lie" and say that it was Manchester United — as they are most likely to win. If they didn't win, you might be called a liar, but in most cases, you will seem knowledgeable. And, so, there's a dilemma in the usage of LLM (Large Language Models) … what happens when the AI doesn't know the answer to something and where it hasn't learnt it. While it may know the capital of Germany, it is unlikely to know the town you visited last Tuesday. With LLM, the machine obviously takes a guess based on probabilities. If I know that a person lives in Edinburgh, then in all probability, the most probable city will be Glasgow, and the next being London — as the probabilities will show that for travels, Edinburgh is most linked to Glasgow and then to London. In a previous article, I outlined how Chat-GPT provided some false statements on me, including that I invented the Hypervisor and that I was a Fellow of the Royal Society of Edinburgh (RSE). But, if someone in the newspapers published false statements about someone, you might consider suing them or at least asking for an apology. But what about machines? What happens when they define "an untruth"? In human terms, we would define an untruth as a lie. But a machine is just weighing up probabilities. It, too, has little concept of the truthiness (veracity) of the data it has received. For my RSE award, it perhaps looked at my profile and computed that there was a high probability that I would have an RSE Fellowship based on me being a Professor in Scotland, having an OBE, and having an academic publishing record. But, if someone in the newspapers published false statements about someone, you might consider suing them or at least asking for an apology. But what about machines? What happens when they define "an untruth"? And, so, ChatGPT — created by OpenAI — could be one of the first pieces of software to stand trial on the way it collects, uses and protects its data. For this, the Washington Post reports that the FTC (Federal Trade Commission) has initiated a wide-ranging set of questions against its LLM (Large Langage Model) [here].

I receive a good deal of incorrect emails on my Gmail account. Most of it relates to the gathering of war veterans in the US or church events in Illinois that I must attend. Why? Because someone, somewhere, has a similar email address to me. Perhaps it is Bill Buchan or Will Buchanan? Who knows, but I get them constantly, and where I discretely decline the invite and ask them to check the email address. Overall, I never embarrass those who send me these emails by responding back to the whole group. Many times, there can be over 50 people that are copied into the email. It is all part of the silly world of email. But, when incorrect emails go to places with sensitive data, we must worry. And, so, the Financial Times [here] has now disclosed that a typo in the definition of an email address has sent 100s of thousands of emails from its military domain (.MIL) to the Mali domain (.ML). This includes sensitive documents, tax returns, travel information and password resets. It is thought that this has existed for over a decade and was discovered by Johannes Zuurbier (and who is in contact with those who managed the .ML domain), but only now is it being taken seriously by the US military. For this, he found over 117,000 misdirected email messages, which increases by over 1,000 messages by the day. Postscript Note, I support good journalism. The FT supports "Authority. Integrity. Accuracy." Please consider a subscription, and keep good journalism alive: https://subs.ft.com/subscription

Rock singers often say that it was their adversity that drove them to create their classics, such as heartache, sorrow, or losing something in their lives. And, so, we might quote: Sweet are the uses of adversity — William Shakespeare One such person who had considerable adversity is Leonhard Euler and who lived from 1707 to 1783. Leonhard was truly one of the greatest minds who has ever graced this planet: "Read Euler, read Euler, he is the master of us all" — Pierre-Simon Laplace But, he suffered great adversity in his life and eventually went blind. His blindness, though, seemed to just increase his outputs — as it allowed him to focus his mind on core problems. In fact, in 1775 — four years after he had gone blind — he proposed a mathematical paper every week. On going blind, he was quoted: "Now I will have fewer distractions." Leonhard output of truly original thought in his time of adversity has possibly never been equalled by any mortal soul. And, his legacy lives on and is part of virtually every single transaction on the Internet. In fact, his maths has made our digital world so much safer. The fundamentals This article could in no way define all of Leonhard's contributions, but one of the most fundamental is that he took the basics of integral calculus — as sketchily defined by Newton and Leibniz — and perfected it. In our modern world, so many things in our lives depend on calculus for their solutions, such as where we see changes in the physical parameters in our world. Calculus, for example, links the distances we travel over time to speed, and then changes in our speed to acceleration and deceleration. Overall, it basically makes sense of the dynamics of our world — an ever-changing and sometimes chaotic world. Further reading here.

So while there is much debate around people like Tim Berners-Lee and Vint Cerf, we should also include "The Editor of the Internet": Jon Postel. Jon was born on 6 August 1943 and died in October 1998. Even up to his death, he was the editor of the Request for Comment (RFC) documents and administered the Internet Assigned Numbers Authority (IANA). In 2012, he was inducted into the Internet Hall of Fame by the Internet Society, and the foundation he has left is as strong as any foundation ever created, in fact, it's the foundation for our Cyber Age. Building and standardizing the Internet Before the Internet, companies such as IBM held a stranglehold on the industry, and typically defined the standards for others to follow. Along with this, we had standards agencies, such as ISO and the IEEE, which were comborsome entities which took years, if not decades, to standardize anything. With these standardization agencies, a standard could take years to develop, and often involved the tinkering from countries, in order to protect their industries, and thus often stifled innovation. Overall the Internet was built around many of the systems and protocols that grew up in the early 1980s. It then grew without the constraints of governments and standards agencies. The core part of this growth was the quick method of publishing a new standard: the RFC. RFCs RFC (Request For Comment) documents are a way to quickly define standards. With this HTTP and email quickly become standardized. Developers could then go ahead and implement the system against the standards, without the massive overhead of taking them to international standards agencies like the ISO (International Standard Organisation) or the IEEE. While first published in 1969 (with RFC1), the classics first started to appear in 1981, and which now provide the core of the Internet: RFC 791 which defines the format of IP packets (IPv4) RFC 793 which defines TCP (Transport Control Protocol), and the foundation of virtually all of the traffic that exists on the Internet. Many protocols, although now limited, became de-facto standards, and have moved on little since, including HTTP (HyperText Transmission Protocol) 1.1, which was initially created as RFC 1945. The foundation: TCP and IP So, it was in September 1981, that the true foundation of the standardisation of Internet communications was born: For RFC 783 we have: September 1981 Transmission Control Protocol PREFACE This document describes the DoD Standard Transmission Control Protocol (TCP). There have been nine earlier editions of the ARPA TCP specification on which this standard is based, and the present text draws heavily from them. There have been many contributors to this work both in terms of concepts and in terms of text. This edition clarifies several details and removes the end-of-letter buffer-size adjustments, and redescribes the letter mechanism as a push function. Jon Postel Editor Sandwiched in-between the two classics, was another one, which did not have the same impact, but has helped to debug a billion systems: Internet Control Message Protocol (ICMP) — RFC 782. So RFC791, RFC792 and RFC793 have since changed the course of our societies. The impact of the IP and TCP standards cannot be underestimated in terms of their impact on our society, and certainly rate alongside "The Wheel" and "The Transistor" as some of the most disruptive technologies ever created. Its standardization supported a whole range of activities and basically allow the Internet to boot up quickly. If nation-states had controlled the Internet, it would have ended up being licensed, and locked down in its growth. Without the massive growth of the spread of the protocols, the Internet would have died as quickly as it had been created. With standards and government agencies controlling its every move. For Jon, he just gathered the required methods for the standards and posted them for everyone to review. If you missed it, you really couldn't contribute until the next version came along. Building a Web: HTTP For something like HTTP, which provides the core of most of what we do on the Web, it started with 1.0 (with the input from Tim Berners-Lee) with RFC1945 (in 1996) and then developed on HTTP 1.1 as RFC2068 (in 1997). Basically in the 18 years since, very little has changed with the core HTTP protocol, as it quickly becomes as standard. New methods of using in — such as with REST Web services — actually made use of all the things that were not really used when accessing static Web pages. The lack of thought to security is highlighted by the fact that it took to RFC 1508 before the word "Security" was included in the title (Sept 1993), which was more than 12 years since the IP packet definition (Sept 1981). So it was 1981 when TCP and IP were created, and two major other things happened around the time that supported the growth of the Internet. The first was the release of the PC by IBM, and the other was when Leonard Bosack netw

Preface We should all have a magic switch that pushes aside our worries and replaces them with something that takes our woes away. So, when I've had a long and tiring day, and there are things buzzing in my head — I don't count sheep, I ponder the wonder of discrete logarithms, and in the magical ways they have solved our many online security. It relaxes me and pushes out all of those academic stresses. This academic year, we were so lucky to speak to some of the people who properly built the foundations of our online security. This included Marty Hellman (co-inventor of the Diffie-Hellman method), Tahir ElGamal (inventor of the ElGamal encryption method), and Neal Koblitz (co-inventor of Elliptic Curve Cryptography — ECC). In this article, I will trace the roots of this security, and outline how discrete logs paved the way for the rise of ECC. So, if we go back to school, you will remember that: g^x . g^y is equal to: g^{x+y} and that: {g^x}^y is: g^{x.y} That's the beauty of logarithms. Introduction Our online world is secured with discrete logs. While we have moved away from discrete logs for key exchange (Diffie-Hellman), encryption (ElGamal) and digital signatures (DSA), at the core of the security of elliptic curves is the Elliptic Curve Discrete Logarithm Problem (ECDLP): Can we find n such that Q = nP? and where P and Q are points on an elliptic curve, and where we have a finite field defined by a prime number. The curve itself can be the form of: y²=x³+ax+b (mod p) The (mod p) part defines a finite field, and which basically constrains the values of x and y to between 0 and p-1. But, I'd like to look back at a time before elliptic curves and see where we started with this: the discrete log. Basically, discrete logs built the security of the Internet, and without them, we would have struggled to advance from a digital world that used physical cables and padlocks to secure itself.

I love wireless (wi-fi) communications. In fact, I did my PhD around the propagation of radio waves using Maxwell's equations. The beauty and perfection of radio waves will never leave me. The first thing you often learn about wifi is how the frequency of the wave relates to its wavelength (lambda=speed of light divided by the frequency) and how dipole antennas have to be around half a wavelength long. For AM, there are long antennas (such as, with the ones that wrap copper around a core) or can be short ones (like the dipole antenna on your wireless router). Much of the magic happens around 2.4GHz.. and which gives a wavelength of 12.5cm, and where if you measure the dipole antenna, it will be around 6cm high. Once you learn about this, you are often hooked on the wonderment of radio waves. It has solid mathematics, but is also a black art (ask any RF engineer, and they will tell you this)! Overall, too, wi-fi has freed us from those pesky twisted pair of cables and those troublesome RJ45 and RJ11 connectors. And, at the core of wifi, is signal strength, and where the stronger the signal, the more chance we have of creating a good network connection. For this, with most IEEE 802.11x standards, the bandwidth that you can use often relates to the signal strength that you have — so the further away you are from the transmitter, the more likely it is that you will have a lower bandwidth capacity. I, too, love all the different antenna shapes and designs and try to imagine how they spread their signals. But those pesky metal things get in the way and can bounce signals in other directions (which is sometimes a good thing, of course), and the other materials, such as concrete, will reduce the signal strength. For all the maths of Maxwell's equations, a lot comes down to measurements and simulations. At home, you might have a MIMO (Multiple In, Multiple Out) transmitter, and which bounces signals of objects and transmits on multiple channels. This might give up to 540Mbps. But, the further you go away from this, the bandwidth reduces until it will drop to nearer 11 Mbps. And, so RSSI (Receiver Signal Strength Indicator) is an important measurement as it defines how good your signal strength is — at a point in time. This will obviously vary as you move and as other things move around you. But, at the other end, if you have too much signal strength, you can breach health and safety regulations. Currently, this is around 100mW, and you need to have a good reason if you need higher power levels than this, as too much radio power — especially around 2.4GHz — might affect someone's health. So, let's talk about that troublesome (and powerful) unit called dBm, and where it is all about adding and subtracting, and not those difficult maths operations of multiplying and dividing. Believe in John Napier's logs to help our wifi systems:

I have a secret. And you have a secret. And together, we can merge our secret into another secret. What I am outlining here is the beauty of the Elliptic Curve Diffie Hellman (ECDH) method, and it is protecting your rights to privacy in the access that you have to this podcast. And what about trust? Well, there's a chance that the Web site that you are receiving this podcast from is using the ECDSA (Elliptic Curve Digital Signature Algorithm) to verify that you can trust the site. And, so, in this podcast, I'm going to outline something that is pure mathematical beauty: the Elliptic Curve. There are more information on ECC [here] and the text to this Podcast is [here].

Here Harry McLaren talks with Rich Macfarlane and Bill Buchanan. What's the key to finding a job within Cybersecurity? A balance of technical competencies (networking, OS, services, programming, and so on) and human intelligence (self-awareness, self-regulation, motivation, empathy and social skills). The slides are here. For Splunk/Cyber&Data: here.

This is a basic introduction to the Building Trust podcast.