ASecuritySite Podcast

Kerckhoff's principle defines that "a Cryptographic system should be designed to be secure, even if all its details, except for the key, are publicly known", but there aren't too many other rules defined. So here are my 100 Basic Rules of Cryptography (and Secure Programming). First, my Top 10:

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

And the rest:

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

And there you go … 100 rules of cryptography

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

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

% bx seed 6183d30558f3f56b0f7248aea1ed9b1098037ff5ad5eea69% bx seed 090a30f539d443b9ca61cc40c0e8142fc3e95c2e2d288a85% bx seed | bx ec-new > private_key% cat private_key 43c8175d0dc33bfca0bd6bb5f758fd3489da33b08e9b65cd377436952cbc6eb3

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

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

4,294,967,296

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

115792089237316195423570985008687907853269984665640564039457584007913129639936

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

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

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

Conclusions

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

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

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

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

Loss Expectancy

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

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

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

ALE = AV x ARO

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

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

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

ALE = AV x ARO x EF

Figure 1 Figure 2 Risk management/avoidance

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

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

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

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

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

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

Figure 3 Figure 4

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

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

Figure 5 Kill chain model

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

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

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

Figure 6: Cyber Kill Chain Model © [2] Reconnaissance

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

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

Hi Carol,

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

— Trent

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

MITRE ATT&CK (TM) Framework

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

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

Figure 7: Mitre [2][here]

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

Figure 8: Defining sub-techniques [link]

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

Figure 9: Sub-techniques [link] Unified Kill Chain (UKC) model

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

Figure 8 [Link] Figure 9 [Link] Conclusions

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

References

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

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

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

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

Digital signatures are the foundation of our digital trust. With this, Bob has a key pair: a private key and a public key. In order to provide his identity, he signs a hash of a message with his private key, and then Alice proves this with his public key. Currently, we mainly use RSA, ECDSA and EdDSA for our signature methods, and where DSA signatures (which use discrete logs) have been dropped for their creation. For example, ECDSA is used with Bitcoin and Ethereum, and RSA is often used to identify Web sites. EdDSA is now on the rise, and is part of the FIPS-186–5 standard. Unforunately, we will need to replace these methods — as quantum computers can crack them.

The other area that needs to be replaced is key exchange and public key encryption. These days we typically use ECDH (Elliptic Curve Diffie Hellman) for key exchange, and RSA for public key encryption. These will have to be replaced with quantum-robust methods — Post Quantum Cryptography (PQC).

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) corporations, but it is individuals who have often built…

medium.com

MPC-in-the-head

These methods use non-interactive zero-knowledge proofs of knowledge and MPC (Multiparty Computation). With MPC we can split a problem into a number of computing elements, and these can be worked on in order to produce the result, and where none of the elements can see the working out at intermediate stages. The great advantage of this method is that we only use symmetric key methods (block ciphers and hashing functions).

Let's Go For A Post-Quantum Picnic And then there were three: CRYSTALS Dilithium, Falcon and Rainbow. These are the finalists for the NIST standard for…

medium.com

Symmetric

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

Isogenies

If we have two elliptic curves (E1 and E2), we can create a function that maps a point (P) on E1 to a point Q on E2. This function is known as an isogeny. If we can map this function, every point on E1 can be mapped to E2. Our secret key is then the isogeny and the public key is the elliptic curve. For key exchange, Bob and Alice mix their isogeny and the other side's curve to generate a secret curve.

Isogenies? The End Game for Public Key Encryption? Well, we are now at the final stage of NIST's post-quantum cryptography standardization, and which started in 2016:

medium.com

Conclusions

Exciting times are ahead as the methods go up and against each. In the last competition, some of the methods fell because of a problem with their parameters (Rainbow — UOV) or because of a core weakness (isogenies). But, this time, they are all likely to come back strong and (hopefully) compete well against the lattice methods.

Lessons from the cybersecurity rule book for government:

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

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

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

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

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

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

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 autonomous systems, based on the information provided by exchanging information between neighbors. It can thus build up a wider picture of the entire interconnected ASs. A keep-alive message is send between neighbours, which allows the graph to be kept up-to-date.

Single-homed systems

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

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

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

Multihomed system

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

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

BGP specification

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

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

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

OPEN message

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

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

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

Figure 4: BGP message header and BGP OPEN message data BGP configuration

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

RouterA # config tRouterA(config)# router bgp AS-number

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

RouterA # config tRouterA(config) # router bgp AS-numberRouter(config-router)# network network-number [mask network-mask]

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

RouterA # config tRouterA(config) #router bgp AS-numberRouter(config-router)#network network-number [mask network-mask]Router(config-router)# neighbor ip-address remote-as AS-number

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

Conclusions

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

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

https://asecuritysite.com/cisco/bgp

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

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

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

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

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

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:

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

The worst for me?

And my least favouriate:

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

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

Conclusions

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

So learn some Golang:

https://asecuritysite.com/golang

and some Rust:

https://asecuritysite.com/rust

Which are your five favouriate and least favouriate programming languages?

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

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

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

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 a point on the elliptic curve (G), and Alice passes aG to Bob, and Bob passes bG to Alice. The shared key is then abG. A sample run is [here]:

== Fourq key sharingAlice Secret: 4d4ae7584414589e7688507cbd0eb1f107352176eac219ec49d698e0868f83a6Alice Public: 6e34b72d675cf331ed856393580e9f74fce2a9d2cce10f2e15d58070a70d2567Bob Secret: 19b5c6a97dad74f0ffdaf9cb4bec561de3124b4c90f90f2f618db6cc0f5f9b8eBob Public: e2159ddc2efc501ccc01f1df78d5d14061edf3b284ae98095e747b7aeac63306Bob Shared: 0112c5090679d20d4363a670ff61d554284519c6d371e61cc9526d65d5a763a0Alice Shared: 0112c5090679d20d4363a670ff61d554284519c6d371e61cc9526d65d5a763a0

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

The Mersenne Twister

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

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

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

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

Lucas-Lehmer Test

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

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

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

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

The following is the code [here]:

import syss=18if (len(sys.argv)>1): s=int(sys.argv[1])if (s>127): sys.exit(1)u=4n=pow(2,s)-1print (f"n=2^{s}-1={n}\n")for k in range(1,s-1): u=((u*u)-2) %n print (u,end=' ')if (u==0): print ("\n\nIt is prime")else: print ("\n\nIt is not prime")

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

n=2^19-1=52428714 194 37634 218767 510066 386344 323156 218526 504140 103469 417706 307417 382989 275842 85226 523263 0 It is prime Conclusions

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

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

and where p is a prime number.

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

https://asecuritysite.com/primes

Blog: https://medium.com/asecuritysite-when-bob-met-alice/a-bluffers-guide-to-symmetric-key-encryption-modes-f7882881f6d

Symmetric key encryption involves a single key to encrypt and decrypt and where Bob and Alice can use the same encryption key. The two most popular symmetric key methods are AES — Advanced Encryption Standard — and ChaCha20. Along with this, we either have a block cipher or a stream cipher. With a block cipher, we process a number of bytes at a time with our ciphering process. With AES, we have a 128-bit block size, and thus process 16 bytes for each block. For a stream cipher, we generate a pseudo infinitely long key stream from a passphrase or random value, and then just XOR this with the plaintext. The size of the key stream is match to the number of bytes in the plaintext. To decrypt, we just generate the same key stream, and XOR it with the ciphertext to recover the plaintext.

I am often surprised by how little care many companies have in their encryption process and do not review the fundamental weaknesses of using symmetric key encryption. For many, it is a tick-box approach, where an auditor just asks if they are using encryption or not. It should not be, and there are many weaknesses that need to be taken into account. So, here's the bluffer's guide to modes in AES:

• ECB (Electronic Code Book). This is the fastest mode and should NEVER be used, as there is no salt (IV) used in the ciphering process. This mode is only used for academic purposes to show what can go wrong if salt is not added to the encryption process. With this, the ciphertext will always be the same for the same plaintext, and it is possible to easily crack by looking at patterns in the data.

All of the other modes have a salt (IV or nonce) value:

• CTR (Counter). This is an excellent mode which has a counter for each block, and then converts to a stream cipher. It is nearly as fast as ECB, and can be processed in parallel. It can be played back in a different session and can have little in the way to integrity check, and where Eve can flip bits and change the plaintext from the ciphertext. We need all the ciphertext before we can use the plaintext. A demo of breaking CTR is: https://billatnapier.medium.com/can-i-break-aes-encryption-yes-31bdf539aba0
• GCM (Galois/Counter Mode). This is almost the same as CTR and is a stream cipher, but slower than CTR (but still relatively fast overall. It has the advantage of adding additional data, such as for a session ID, and thus protects against playback. GCM (Galois/Counter Mode). The main change from CTR is to add a MAC, and so the bit-flipping method would be near impossible to implement. This mode implements AEAD (Authenticated Encryption with Additional Data), and is useful in defending against playback attacks. It can suffer from nonce reuse, though.
• CBC (Cipher Block Chain). This is a block mode which thus requires padding before encryption and after decryption. While achieving the same speeds as ECB for a small amount of data, it slows down with larger amounts — because of the block-chaining process. It is seen to be a little cumbersome and has a few issues with security.
• CCM (counter with cipher block chaining message authentication code; counter with CBC-MAC). This is a stream cipher mode and has a similar performance to CBC. It integrates better integrity checks with a MAC (message authentication code).
• ChaCha20. It is not AES — which can be a good thing. Along with this, it is a stream cipher (and so fast in its operation). It is typically not as fast at CTR and GCM, but faster than CBC. Overall, AES tends to be accelerated for its processing on x64/x86 chips, but not for ChaCha20. As with AES GCM mode, ChaCha20 implements AEAD (Authenticated Encryption with Additional Data) and is useful in defending against playback attacks.

There are other modes, such as OFB (Output Feedback) and CFB (Cipher Feedback), but these are not used that much. For this in the finance industry, you might also be using 3DES, and which has not been broken, but is much slower than AES and ChaCha20. Here are some performance tests [here]:

Generally, the stream ciphers can struggle against nonce reuse, and if the same nonce is used, it can be possible to break AES by XOR'ing cipher streams.

And to show the breaking of the integrity of AES:

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 to recreate a valid MAC and replace it, when a nonce is reused.

So, companies who take security seriously should understand their risks, and test accordingly. Those involved in areas of high risk, such as dealing with financial data and PII, should understand the risks in the methods they implement and not just tick a box to say that they have encrypted the data. I have seen many examples of companies ploughing on with the same old encryption methods — even though they have significant weaknesses.