ASecuritySite Podcast

And, so, we are moving into one of the greatest changes that we ever see on the Internet, and where we will translate from our existing public key infrastructures towards Post Quantum Cryptography (PQC) methods. At the present time, NIST has approved one key exchange/public key encryption method (Kyber) and three digital signature methods (Dilithium, Falcon and SPHINCS+). The focus will now be on seamless integration, and where we will likely use hybrid methods initially and where we include our existing ECDH method with Kyber, and mix either RSA, ECDSA or EdDSA digital sigatures with Dilithum.

Key exchange is (relatively) straightforward

Overall, Kyber is fairly easy to create a hybrid key exchange method with ECDH, and where we would transmit both the ECC public key and the Kyber public key in the same packet. In fact, Google are already testing its integration in Chrome. With this, our existing key sizes are [here]:

Type Public key size (B) Secret key size (B) Ciphertext size (B)------------------------------------------------------------------------ P256_HKDF_SHA256 65 32 65P384_HKDF_SHA384 97 48 97P521_HKDF_SHA512 133 66 133X25519_HKDF_SHA256 32 32 32X448_HKDF_SHA512 56 56 56

Thus, for P256, we have a 32-byte private key (256-bits) and a 65-byte public key (520 bits). Kyber 512 increase the key size of 1,632 bytes for the private key, and 800 bytes (6,400 bits) for the public key:

Type Public key size (B) Secret key size (B) Ciphertext size (B)------------------------------------------------------------------------ Kyber512 800 1,632 768Kyber738 1,184 2,400 1,088Kyber1024 1,568 3,168 1,568

Thus, to use a hybrid key exchange method, we would include the ECC public key and the Kyber512 public key and thus have a packet which contains 832 bytes. This is smaller than the 1,500 byte limit for an IP packet and thus requires only one packet to send the public key from Bob to Alice (and vice-versa). A Hybrid method is defined here:

https://asecuritysite.com/pqc/circl_hybrid

and a test run is:

Method: Kyber512-X25519 Public Key (pk) = 3BF9B5BB236AD036BA65B1B532E11927E20269D3CE74009E6C085F0D901F5CC9 (first 32 bytes)Private key (sk) = B96B644DE170BA19266AF32BFA4B3B22A4917888A2EE785C701B7252D6308573 (first 32 bytes)Cipher text (ct) = 0E54F37E171768318B45FD27FBDB08B33CD2204142C4B925BB395DA93AE26EA7 (first 32 bytes)Shared key (Bob): C0B27940D588EE1D0F8348F169BA04A48E0E7FA7DE5B8A091D5D1B59E70D577EEAC4180B076595B2EFCCE96E2271EEA3B20228FC3FD5B63114D32E9D20D9A2F2Shared key (Alice): C0B27940D588EE1D0F8348F169BA04A48E0E7FA7DE5B8A091D5D1B59E70D577EEAC4180B076595B2EFCCE96E2271EEA3B20228FC3FD5B63114D32E9D20D9A2F2Length of Public Key (pk) = 832 bytes Length of Secret Key (sk) = 1664 bytesLength of Cipher text (ct) = 800 bytes Digital Signatures and PKI is not so easy

But, what will happen with the next part of the process, and where we need to digitally sign something with a private key and then prove with the public key? This is an important element in HTTPs, and where ECDH is used to exchange the symmetric key, and then digital signatures are used to verify the identity of the server. For this, we use digital certificates (X.509), and which contain the public key of the entity and which has been signed by a trusted entity (Trent).

Well, at the present time, it is not quite clear yet, and a new IETF draft perhaps gives some insights [here]:

The draft outlines how we could include two public keys in the same certificate: such as an ECC or RSA public key and a PQC public key. Unfortunately, it has been given a "Tombstone notice", which means it will not progress. The reason for this is that it adds a PQC key — no matter if the host actually wants (or uses) it. Along with this, it does not give a mechanism for coping with two signatures on a method (with a traditional one and a PQC one), and where it is not possible to detect where one of the signatures has been removed — a stripping attack.

Public key sizes for Dilithum

Like it or not, the days of small public key sizes are coming to an end. In ECC, for NIST P256, we have a 32-byte (256 bit) private key, and a 64-byte (512-bit) public key. For Ed25519, we use Curve 25519, and which reduces the public key to ust 32 bytes (256 bits).

For RSA 2K, we have a 256-byte private key (2,048 bits), and a 256-byte public key (2,048 bits). The equivalent security for Dililithum is Dililithum2, and which gives a much larger private key of 2,528 bytes (20,224 bits) and a public key of 1,312 bytes (10,496 bits). The Dilithium public key is thus over 20 times larger than the ECC key. This could be a major overhead in communication systems, and where more than one data packet would have to be sent in order to transmit the public key.

Method Public key size Private key size Signature size Security level------------------------------------------------------------------------------------------------------Crystals Dilithium 2 (Lattice) 1,312 2,528 2,420 1 (128-bit) LatticeCrystals Dilithium 3 1,952 4,000 3,293 3 (192-bit) LatticeCrystals Dilithium 5 2,592 4,864 4,595 5 (256-bit) LatticeFalcon 512 (Lattice) 897 1,281 690 1 (128-bit) LatticeFalcon 1024 1,793 2,305 1,330 5 (256-bit) LatticeSphincs SHA256-128f Simple 32 64 17,088 1 (128-bit) Hash-basedSphincs SHA256-192f Simple 48 96 35,664 3 (192-bit) Hash-basedSphincs SHA256-256f Simple 64 128 49,856 5 (256-bit) Hash-basedRSA-2048 256 256 256ECC 256-bit 64 32 256

A hybrid scheme is defined here:

https://asecuritysite.com/pqc/circl_dil2

For our existing signatures, we have:

Method Public key size (B) Private key size (B) Signature size (B) Security level------------------------------------------------------------------------------------------------------Ed25519 32 32 64 1 (128-bit) EdDSAEd448 57 57 112 3 (192-bit) EdDSAECDSA 64 32 48 1 (128-bit) ECDSARSA-2048 256 256 256 1 (128-bit) RSA

And in using a hybrid approach, we increase the signature size of 64 bytes or Ed25519 to 2,484 bytes — a 38-fold increase in size:

Method Public key size Private key size Signature size Security level------------------------------------------------------------------------------------------------------Crystals Dilithium2-X25519 2,560 1,344 2,484 1 (128-bit) LatticeCrystals Dilithium3-X25519 4,057 2,009 3,407 3 (192-bit) LatticeCrystals Dilithium 2 (Lattice) 1,312 2,528 2,420 1 (128-bit) LatticeCrystals Dilithium 3 1,952 4,000 3,293 3 (192-bit) LatticeCrystals Dilithium 5 2,592 4,864 4,595 5 (256-bit) LatticeFalcon 512 (Lattice) 897 1,281 690 1 (128-bit) LatticeFalcon 1024 1,793 2,305 1,330 5 (256-bit) LatticeSphincs SHA256-128f Simple 32 64 17,088 1 (128-bit) Hash-basedSphincs SHA256-192f Simple 48 96 35,664 3 (192-bit) Hash-basedSphincs SHA256-256f Simple 64 128 49,856 5 (256-bit) Hash-based

And, so, what about using SPHINCS+? That has a 32-byte public key. The downside is that Sphincs SHA256–128f requires a 17,088-byte signature. This would also overload the communication channel and require over 11 packets to send a single signature to prove the identity of a Web site. It is highly unlikely that SPHINCS+ will be used to replace RSA and ECC signatures in ECDH, but where it would be used in applications that did not have a communications channel.

Conclusions

And, so, the double public key draft has been sent back, and we are awaiting the next iteration.

Learn more about PQC here:

https://asecuritysite.com/pqc

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

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

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

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

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

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

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

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

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

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

Now, Level 3 Communications uses AS1.

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

Domain Name: bbn.comRegistry Domain ID: 4240240_DOMAIN_COM-VRSNRegistrar WHOIS Server: whois.corsearch.domainsRegistrar URL: Updated Date: 2023-05-09T19:30:10ZCreation Date: 1985-04-24T05:00:00ZRegistrar Registration Expiration Date: 2024-04-25T04:00:00ZRegistrar: Corsearch Domains LLCRegistrar IANA ID: 642Registrar Abuse Contact Email: [email protected] Abuse Contact Phone: +1.8007327241Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited

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

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

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

Conclusion

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

In cybersecurity, the teaching of Cloud security is often weak. So, here are my Top 100 things about encryption in the Cloud. I've focused on AWS, but Azure is likely to also be applicable.

1. Keys are created in the AWS KMS (Key Management Store). In Azure, this is named KeyVault.
2. The cost of using a key in KMS is around $1/month (prorated hourly). When a key is disabled, it is not charged.
3. With AWS KMS, we use a shared customer HSM (Hardware Security Module), and with AWS CloudHSM it is dedidated to one customer.
4. For data at rest, with file storage, we can integrate encryption with Amazon EBS (Elastic Block Storage) and Amazon S3.
5. Amazon EBS drives are encrypted with AES-256 with XTS mode.
6. For AWS-managed keys, a unique key is used for every object within S3 buckets.
7. Amazon S3 uses server-side encryption to store encrypted data. The customer can use client-side encryption to encrypt data before it is stored in the AWS infrastructure.
8. AWS uses 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) for its symmetric key encryption.
9. In AWS S3, by default, all the objects are encrypted.
10. A customer can use client-side encryption to encrypt data before it goes into the AWS infrastructure.
11. For data at rest, for databases, we can integrate encryption with Amazon RDS (AWS's relational database service) and Amazon Redshift (AWS's data warehousing).
12. For data at rest, we can integrate encryption into ElastiCache (AWS's content caching service), AWS Lambda (AWS's serverless computing service), and Amazon SageMake (AWS's machine learning service).
13. Keys are tokenized and have an ARN (Amazon Resource Names) and alias. An example ARN for a key is arn:aws:kms:us-east-1:103269750866:key/de30e8e6-c753–4a2c-881a-53c761242644, and an example alias is "Bill's Key". Both of these should be unique in the user's account.
14. To define a KMS key, we can either use its key ID, its key ARN, its alias name, or alias ARN.
15. You can link keys to other AWS Accounts. For this, we specify in the form of "arn:aws:iam::[AWS ID]:root", and where AWS ID is the ID of the other AWS account.
16. To enhance security, we can use AWS CloudHSM (Hardware Security Module). For simpler and less costly solutions, we typically use AWS KMS (Key Management Solution). For CloudHSM, we pay per hour, but for KMS, we just pay for the usage of the keys.
17. The application of the keys is restricted to defined services.
18. Key identifiers and policies are defined with a JSON key-value pair for data objects.
19. Each key should have a unique GUID, such as "de30e8e6-c753–4a2c-881a-53c761242644".
20. Users are identified and roles are identified with an ARN, such as : "arn:aws:iam::222222:root".
21. With the usage of keys we have Key Administrative Permission and a Key Usage policies.
22. There is an explicit denial on a policy if there is not a specific allow defined in a policy.
23. For key permissions, we have fields of "Sid" (the descriptive name of the policy), "Effect" (typically "Allow"), Principal (the ARN of the user/group), "Action" (such as Create, Disable and Delete) and "Resource". A wildcard ("*") allows or disallows all.
24. To enable a user of "root" access to everything with a key would be : "Sid": "Enable IAM User Permissions", "Effect": "Allow","Principal": {"AWS": "arn:aws:iam::22222222:root"},"Action": "kms:*", "Resource": "*"}.
25. The main operations within the KMS are to encrypt/decrpyt data, sign/verify signatures, export data keys, and generate/verify MACs (Message Authentication Codes).
26. Key are either AWS managed (such as for the Lambda service), Customer managed keys (these are created and managed by the customer).
27. Custom key stores are where the customer has complete control over the keys).
28. The main use of keys are for EC2 (Compute), EBS (Elastic Block Storage) and S3 (Storage).
29. AES symmetric keys or an RSA key pair are used to encrypt and decrypt.
30. RSA uses 2K, 3K or 4K keys, and with either "RSA PCKS1 v1.5" or "RSA PSS" padding.
31. RSA PCKS1 v1.5 padding is susceptible to Bleichenbacher's attack, so it should only be used for legacy applications, and for all others, we should use RSA PSS.
32. For RSA, we can use a hashing method of SHA-256, SHA-384 or SHA-512.
33. In RSA, we encrypt with the public key and decrypt with the private key.
34. For signatures, we can use either RSA or ECC signing. For RSA, we have 2K, 3K, or 4K keys, whereas ECC signing uses NIST P256, NIST P384, NIST P521, and SECG P256k1 (as used in Bitcoin and Ethereum).
35. For MACs (Message Authentication Codes), Bob and Alice have the same shared secret key and can authenticate the hash version of a message. In the KMS, we can have HMAC-224, HMAC-256, HMAC-384 and HMAC-512.
36. KMS uses hardware security modules (HSMs) with FIPS 140–2 and which cannot be accessed by AWS employees (or any other customer).
37. Keys will never appear in an AWS disk or backup, and only existing the memory of the HSM. They are only loaded when used.
38. Encryption keys can be restricted to one region of the world (unless defined by the user).
39. With symmetric keys, the key never appears outside the HSM, and for asymmetric keys (public key encryption), the private key stays inside the HSM, and only the public key is exported outside.
40. AWS CloudWatch shows how and when the encryption keys are being used.
41. The minimum time that can be set for a key to be deleted is seven days (and up to 30 days maximum).
42. An organisation can also create its own HSM with the CloudHSM cluster. When a key is then created in KMS, it is then stored in the cluster.
43. The usage of encryption keys should be limited to a minimal set of service requirements.
44. If possible, separate key managers and key users.
45. With a key management (KEY_ADMINISTRATOR) role, we typically have the rights to create, revoke, put, get, list and disable keys. The key management role will typically not be able to encrypt and decrypt.
46. For a key user (KEY_WORKER) role, we cannot create or delete keys and typically focus on tasks such as encrypting and decrypting.
47. Hae a rule of minimum access rights, and simplify user access by defining key administration and usage roles. Users are then added to these roles.
48. Avoid manual updates to keys and use key rotation. The system keeps track of keys that are rotated and can use previously defined ones.
49. The default time to rotate keys is once every year.
50. Key rotation shows up in the CloudWatch and CloudTrail logs.
51. KMS complies with PCI DSS Level 1, FIPS 140–2, FedRAMP, and HIPAA.
52. AWS KMS is matched to FIPS 140–2 Level 2.
53. AWS CloudHSM complies with FIPS 140–2 Level 3 validated HSMs.
54. AWS CloudHSM costs around $1.45 per hour to run, and the costs end when it is disabled or deleted.
55. The CloudHSM is backed-up every 24 hours, and where we can cluster the HSMs into a single logical HSM.
56. CloudHSM can be replicated in AWS regions.
57. AWS KSM is limited to the popular encryption methods, whereas the CloudHSM can implement a wider range of methods.
58. The CloudHSM can support methods such as 3DES with AWS Payment Cryptography. This complies with payment card industry (PCI) standards, such as PCI PIN, PCI P2PE, and PCI DSS.
59. In the CloudHSM for payments, we can generate CVV, CVV2 and ARQC values, and where sensitive details never exist outside the HSM in an unprotected form.
60. With the CloudHSM, we have a command line interface where we can issue commands, and is named CloudHSM CLI.
61. Within the CloudHSM CLI, we can use the genSymKey command to generate symmetric key within the HSM, such as where -t is a key type (31 is AES), -s is a key size (32 bytes) and -l is the label: genSymKey -t 31 -s 32 -l aes256
62. With genSymKey the key types are: 16 (Generic Secret), 18 (RC4), 21 (Triple DES), and 31 (AES).
63. Within the CloudHSM CLI, we can use the genRSAKeyPair command to generate an RSA key pair, such as where -m is the modulus and -e is the public exponent: genRSAKeyPair -m 2048 -e 65537 -l mykey
64. AWS CloudHSM is integrated with AWS CloudTrail, and where we can track user, role, or an AWS service within AWS CloudHSM.
65. With AWS Payments Cryptography, the 2KEY TDES is Two-key Triple DES and has a 112-bit equivalent key size.
66. The Pin Encryption Key (PEK) is used to encryption PIN values and uses a KEY TDES key. This can store PINs in a secure way, and then decrypt them when required.
67. S3 buckets can be encrypted either with Amazon S3-managed keys (SSE-S3) or AWS Key Management Service (AWS KMS) keys.
68. There is no cost to use SSE keys.
69. For symmetric key encryption, AWS uses envelope encryption, and where a random key is used to encrypt data, and then the key is encrypted with the user's key. AWS should not be able to access the key used for the encryption.
70. The default in creating an encryption key is for it only be to used in a single region, but this can be changed to multi-region, and where the key will be replicated across more than one region.
71. In AWS, a region is a geographical area, and which is split into isolated locations. US-East-1 (N.Virginia) and US-East-2 (Ohio) are different regions, while us-east-1a, us-east-1b and us-east-1c are in the same region. A single region key the US-East-1 region would replicate across eu-east-1a, eu-east-1b and eu-east-1c, and not to eu-east-2a, eu-east-2b and eu-east-2c.
72. When creating a key, you can either create in the KMS, import a key (BYOK — bring your own key), create in the AWS CloudHSM, or create in an external key store (HYOK — hold you own key).
73. For keys stored on-premise we can use an external key store (XKS) — this can be defined as Hold Your Own Keys (HYOKs), and where and where no entity in AWS will able to read any of the encrypted data. [here].
74. You can BYOK (bring your own key) with KMS, and import keys. KMS will keep a copy of this key.
75. With XKS, we need a proxy URI endpoint, with the proxy credentials of an access key ID, and secret access key.
76. To export keys from AWS CloudHSM, we can encrypt them with an AES key. This is known as key wrapping, as defined in RFC 5648 (for padding with zeros) or RFC 3394 (without padding).
77. A strong password should always be used for key wrapping.
78. AWS encryption operations can either be conducted from the command line or within API, such as with Python, Node.js or Golang.
79. With KMS, the maximum data size is 4,096 bytes for a symmetric key, 190 bytes for RSA 2048 OAEP SHA-256, 318 bytes for RSA 3072 OAEP SHA-256, ad 446 bytes for RSA 4096 OAEP SHA-256.
80. An example command to encrypt a file for 1.txt with symmetric key encryption is: aws kms encryp --key-id alias/MySymKey --plaintext fileb://1.txt --query CiphertextBlob --output text > 1.out
81. To decrypt a file with symmetric key encryption, an example with 1.enc is: aws kms decrypt --key-id alias/BillsNewKey --output text --query Plaintext --ciphertext-blob fileb://1.enc > 2.out
82. In Python, to integrate with KMS, we use the Boto3 library.
83. The standard output of encrypted content is in byte format. If we need to have a text version of ciphertext, we typically use Base64 format.
84. The base64 command can be used to convert byte format in Base64, such as with: $ base64 -i 1.out — decode > 1.enc
85. The xxd command in the command line allows the cipher text to be dumped to a hex output and can then be edited. We can then convert it back to a binary output with:
86. An example piece of Python code for encrypting a plaintext message with the symmetric key in Python is: ciphertext = kms_client.encrypt(KeyId=alias,Plaintext=bytes(secret, encoding='utf8')
87. An example piece of Python code to decrypt some cipher text (in Base64 format) is: plain_text = kms_client.decrypt(KeyId=alias,CiphertextBlob=bytes(base64.b64decode(ciphertext)))
88. To generate an HMAC signature for a message in the command line, we have the form of: aws kms generate-mac --key-id alias/MyHMACKey --message fileb://1.txt --mac-algorithm HMAC_SHA_256 --query Mac > 4.out
89. To verify an HMAC signature for a message in the command line, we have the form of: aws kms verify-mac -key-id alias/MyHMACKey -message fileb://1.txt \ -mac-algorithm HMAC_SHA_256 -mac fileb://4.mac
90. To create an ECDSA signature in the command line, we have the form of: aws kms sign -key-id alias/MyPublicKeyForSigning -message fileb://1.txt -signing-algorithm ECDSA_SHA_256 -query Signature > 1.out
91. To verify an ECDSA signature in the command line, we have the form of: aws kms verify -key-id alias/MyPublicKeyForSigning -message fileb://1.txt -signature fileb://1.sig -signing-algorithm ECDSA_SHA_256
92. To encrypt data using RSA in the command line, we have the form of: aws kms encrypt -key-id alias/PublicKeyForDemo -plaintext fileb://1.txt -query CiphertextBlob -output text -encryption-algorithm RSAES_OAEP_SHA_1 > 1.out
93. To decrypt data using RSA in the command line, we have the form of: aws kms decryptb -key-id alias/PublicKeyForDemo -output text -query Plaintext -ciphertext-blob fileb://1.enc -encryption-algorithm RSAES_OAEP_SHA_1 > 2.out
94. To sign data using RSA in the command line, we have the form of: aws kms sign --key-id alias/MyRSAKey --message fileb://1.txt --signing-algorithm RSASSA_PSS_SHA_256 --query Signature --output text > 1.out
95. To verify data using RSA in the command line, we have the form of: aws kms verify --key-id alias/MyRSAKey --message fileb://1.txt — signature fileb://1.sig --signing-algorithm RSASSA_PSS_SHA_256
96. You cannot encrypt data with Elliptic Curve keys. Only RSA and AES can do that. Elliptic Curve keys are used to sign data.
97. If you delete an encryption key, you will not be able to decrypt any ciphertext that uses it.
98. We can store our secrets, such as application passwords, in the secrets manager. An example of a secret name of "my-secret-passphrase" and a secret string of "Qwery123" we can have: aws secretsmanager create-secret --name my-secret-passphrase --secret-string Qwerty123
99. In China regions, along with RSA and ECDSA, you can use SM2 KMS signing keys.
100. In China Regions, we can use SM2PKE to encrypt data with asymmetric key encryption.

Find out more here:

https://asecuritysite.com/aws

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

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

Here are my 100 interesting things to learn about cryptography:

1. For a 128-bit encryption key, there are 340 billion billion billion billion possible keys. [Calc: 2**128/(1e9**4)]
2. For a 256-bit encryption key, there are 115,792 billion billion billion billion billion billion billion billion possible keys. [Calc: 2**256/(1e9**8)]
3. To crack a 128-bit encryption with brute force using a cracker running at 1 Teracracks/second, will take — on average — 5 million million million years to crack. Tera is 1,000 billion. [Calc: 2**128/100e9/2/60/60/24/365/(1e6**3)] For a 256-bit key this is 1,835 million million million million million million million million million years.
4. For the brute force cracking of a 35-bit key symmetric key (such as AES), you only need to pay for the boiling of a teaspoon of energy. For a 50-bit key, you just need to have enough money to pay to boil the water for a shower. For a 90-bit symmetric key, you would need the energy to boil a sea, and for a 105-bit symmetric key, you need the energy to boil and ocean. For a 128-bit key, there just isn't enough water on the planet to boil for that. Ref: here.
5. With symmetric key encryption, anything below 72 bits is relatively inexpensive to crack with brute force.
6. One of the first symmetric key encryption methods was the LUCIFER cipher and was created by Horst Feistel at IBM. It was further developed into the DES encryption method.
7. Many, at the time of the adoption of DES, felt that its 56-bit key was too small to be secure and that the NSA had a role in limiting them.
8. With a block cipher, we only have to deal with a fixed size of blocks. DES and 3DES use a 64-bit (eight-byte) block size, and AES uses a 128-bit block size (16 bytes).
9. With symmetric key methods, we either have block ciphers, such as DES, AES CBC and AES ECB, or stream ciphers, such as ChaCha20 and RC4.
10. In order to enhance security, AES has a number of rounds where parts of the key are applied. With 128-bit AES we have 10 rounds, and 14 rounds for 256-bit AES.
11. In AES, we use an S-box to scramble the bytes, and which is applied for each round. When decrypting, we have the inverse of the S-box used in the encrypting process.
12. A salt/nonce or Initialisation Vector (IV) is used with an encryption key in order to change the ciphertext for the same given input.
13. Stream ciphers are generally much faster than block cipers, and can generally be processed in parallel.
14. With the Diffie-Hellman method. Bob creates x and shares g^x (mod p), and Alice creates y, and shares g^y (mod p). The shared key is g^{xy} (mod p).
15. Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash.
16. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method).
17. Adi Shamir defines a secret share method, and which defines a mathematical equation with the sharing of (x,y), and where a constant value in the equation is the secret.
18. With Shamir Secret Shares (SSS), for a quadratic equation of y=x²+5x+6, the secret is 6. We can share three points at x=1, x=2 and y=3, and which gives y=12, y=20, and y=20, respectively. With the points of (1,12), (2,20), and (3,20), we can recover the value of 6.
19. Adi Shamir broke the Merkle-Hellman knapsack method at a live event at a rump session of a conference.
20. With secret shares, with the highest polynomial power of n, we need n+1 points to come together to regenerate the secret. For example, y=2x+5 needs two points to come together, while y=x²+15x+4 needs three points.
21. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled "Cryptographic Communications System and Method".
22. In public key encryption, we use the public key to encrypt data and the private key to decrypt it.
23. In digital signing, we use the private key to sign a hash and create a digital signature, and then the associated public key to verify the signature.
24. Len Adleman — the "A" in the RSA method — thought that the RSA paper would be one of the least significant papers he would ever publish.
25. The RSA method came to Ron Rivest while he slept on a couch.
26. Martin Gardner published information on the RSA method in his Scientific American article. Initially, there were 4,000 requests for the paper (which rose to 7,000), and it took until December 1977 for them to be posted.
27. The security of RSA is based on the multiplication of two random prime numbers (p and q) to give a public modulus (N). The difficulty of RSA is the difficulty in factorizing this modulus. Once factorized, it is easy to decrypt a ciphertext that has been encrypted using the related modulus.
28. In RSA, we have a public key of (e,N) and a private key of (d,N). e is the public exponent and d is the private exponent. The public exponent is normally set at 65,537.
29. The binary value of 65,537 is 10000000000000001 — this number is efficient in producing ciphertext in RSA.
30. In RSA, the ciphertext is computed from a message of M as C=M^e (mod N), and is decrypted with M=C^d (mod N).
31. We compute the the private exponent (d) from the inverse of the public exponent (e) modulus PHI, and where PHI is (p-1)*(q-1). If we can determine p and q, we can compute PHI.
32. Anything below a 738-bit public modulus is relatively inexpensive to crack for RSA.
33. To crack 2K RSA at the current time, we would need the energy to boil ever ocean on the planet to break it.
34. RSA requires padding is required for security. A popular method has been PCKS#1v1.5 — but this is not provably secure and is susceptible to Bleichenbacher's attack. An improved method is Optimal Asymmetric Encryption Padding (OAEP) and was defined by Bellare and Rogaway and standardized in PKCS#1 v2.
35. The main entity contained in a digital certificate is the public key of a named entity. This is either an RSA or an Elliptic Curve key.
36. A digital certificate is signed with the private key of a trusted entity — Trent. The public key of Trent is then used to prove the integrity and trust of the associated public key.
37. For an elliptic curve of y²=x³+ax+b (mod p), not every (x,y) point is possible. The total number of points is defined as the order (n).
38. ECC (Elliptic Curve Cryptography) was invented by Neal Koblitz and Victor S. Miller in 1985.
39. Elliptic curve cryptography algorithms did not take off until 2004.
40. In ECC, the public key is a point on the elliptic curve. For secp256k1, we have a 256-bit private key and a 512-bit (x,y) point for the public key. A "04" in the public key is an uncompressed public key, and "02" and "03" are compressed versions with only the x-co-ordinate and whether the y coordinate is odd or even.
41. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security.
42. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass ("Vier-strass") curve.
43. The prime number used with secp256k1 is 2²⁵⁶-2³²-2⁹-2⁸-2⁷-2⁶-2⁴-1.
44. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a "04".
45. A compressed secp256k1 public key only stores the x-co-ordinate value and whether the y coordinate is odd or even. It starts with a "02" if the y-co-ordinate is even; otherwise, it starts with a "03".
46. In computing the public key in ECC of a.G, we use the Montgomery multiplication method and which was created by Peter Montgomery in 1985, in a paper entitled, "Modular Multiplication without Trial Division."
47. Elliptic Curve methods use two basic operations: point address (P+Q) and point doubling (2.P). These can be combined to provide the scalar operation of a.G.
48. In 1999, Don Johnson Alfred Menezes published a classic paper on "The Elliptic Curve Digital Signature Algorithm (ECDSA)". It was based on the DSA (Digital Signature Algorithm) — created by David W. Kravitz in a patent which was assigned to the US.
49. ECDSA is a digital signature method and requires a random nonce value (k), and which should never be reused or repeated.
50. ECDSA is an elliptic curve conversion of the DSA signature method.
51. Digital signatures are defined in FIPS (Federal Information Processing Standard) 186–5.
52. NIST approved the Rijndael method (led by Joan Daemen and Vincent Rijmen) for Advanced Encryption Standard (AES). Other contenders included Serpent (led by Ross Anderson), TwoFish (led by Bruce Schneier), MARS (led by IBM), and RC6 (led by Ron Rivest).
53. ChaCha20 is a stream cipher that is based on Salsa20 and developed by Daniel J. Bernstein.
54. MD5 has a 128-bit hash, SHA-1 has 160 bits and SHA-256 has 256-bits. It is relatively easy to create a hash collision with MD5. Google showed that it was possible to create a signature collision for a document with SHA-1. It is highly unlikely to get a hash collision for SHA-256.
55. In 2015, NIST defined SHA-3 as a standard, and which was built on the Keccak hashing family — and which used a different method to SHA-2.
56. The Keccak hash family uses a sponge function and was created by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche and standardized by NIST in August 2015 as SHA-3.
57. Hash functions such as MD5, SHA-1 and SHA-256 have a fixed hash length, whereas an eXtendable-Output Function (XOF) produces a bit string that can be of any length. Examples are SHAKE128, SHAKE256, BLAKE2XB and BLAKE2XS.
58. BLAKE 3 is the fastest cryptographically secure hashing method and was created by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox-O'Hearn.
59. Hashing methods can be slowed down with a number of rounds. These slower hashing methods include Bcrypt, PBKDF2 and scrypt.
60. Argon 2 uses methods to try and break GPU cracking, such as using a given amount of memory and defining the CPU utlization.
61. To speed up the operation of the SHA-3 hash, the team reduced the security of the method and reduce the number of rounds. The result is the 12 Kangaroo's hashing method. The number of rounds was reduced from 24 to 12 (with a security level of around 128 bits).
62. Integrated Encryption Scheme (IES) is a hybrid encryption scheme which allows Alice to get Bob's public key and then generate an encryption key based on this public key, and she will use her private key to recover the symmetric. With ECIES, we use elliptic curve methods for the public key part.
63. A MAC (Message Authentication Code) uses a symmetric key to sign a hash, and where Bob and Alice share the same secret key. The most popular method is HMAC (hash-based message authentication code).
64. The AES block cipher can be converted into a stream cipher using modes such as GCM (Galois Counter Mode) and CCM (counter with cipher block chaining message authentication code; counter with CBC-MAC).
65. A MAC is added to a symmetric key method in order to stop the ciphertext from being attacked by flipping bits. GCM does not have a MAC, and is thus susceptible to this attack. CCM is more secure, as it contains a MAC.
66. With symmetric key encryption, we must remove the encryption keys in the reverse order they were applied. Commutative encryption overcomes this by allowing the keys to be removed in any order.
67. It is estimated that Bitcoin miners consume 17.05 GW of electrical power per day and 149.46 TWh per year.
68. A KDF (Key Derivation Function) is used to convert a passphrase or secret into an encryption key. The most popular methods are HKDF, PBKDF2 and Bcrypt.
69. RSA, ECC and Discrete Log methods will all be cracked by quantum computers using Shor's algorithm
70. Lattice methods represent bit values as polynomial values, such as 1001 is x³+1 as a polynomial.
71. Taher Elgamal — the sole inventor of the ElGamal encryption method — and Paul Koche were the creators of SSL, and developed it for the Netscape browser.
72. David Chaum is considered as a founder of electronic payments and, in 1983, created ECASH, along with publishing a paper on "Blind signatures for untraceable payments".
73. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment.
74. Blockchains can either be permissioned (requiring rights to access the blockchain) or permissionless (open to anyone to use). Bitcoin and Ethereum are the two most popular permissionless blockchains, and Hyperledger is the most popular permissioned ledger.
75. In 1992, Eric Hughes, Timothy May, and John Gilmore set up the cypherpunk movement and defined, "We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money."
76. In Bitcoin and Ethereum, a private key (x) is converted to a public key with x.G, and where G is the base point on the secp256k1 curve.
77. Ethereum was first conceived in 2013 by Vitalik Buterin, Gavin Wood, Charles Hoskinson, Anthony Di Iorio and Joseph Lubin. It introduced smaller blocks, improved proof of work, and smart contracts.
78. NI-ZKPs involves a prover (Peggy), a verifier (Victor) and a witness (Wendy) and were first defined by Manuel Blum, Paul Feldman, and Silvio Micali in their paper entitled "Non-interactive zero-knowledge and its applications".
79. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge).
80. Bitcoin and Ethereum are pseudo-anonymised, and where the sender and recipient of a transaction, and its value, can be traced. Privacy coins enable anonymous transactions. These include Zcash and Monero.
81. In 1992, David Chaum and Torben Pryds Pedersen published "Wallet databases with observers," and outlined a method of shielding the details of a monetary transaction.
82. In 1992, Adi Shamir (the "S" in RSA) published a paper on "How to share a secret" in the Communications of the ACM. This supported the splitting of a secret into a number of shares (n) and where a threshold value (t) could be defined for the minimum number of shares that need to be brought back together to reveal the secret. These are known as Shamir Secret Shares (SSS).
83. In 1991, Torbin P Pedersen published a paper entitled "Non-interactive and information-theoretic secure verifiable secret sharing" — and which is now known as Pedersen Commitment. This is where we produce our commitment and then show the message that matches the commitment.
84. Distributed Key Generation (DKG) methods allow a private key to be shared by a number of trusted nodes. These nodes can then sign for a part of the ECDSA signature by producing a partial signature with these shares of the key.
85. Not all blockchains use ECDSA. The IOTA blockchain uses the EdDSA signature, and which uses Curve 25519. This is a more lightweight signature version and has better support for signature aggregation. It uses Twisted Edwards Curves.
86. The core signing method used in EdDSA is based on the Schnorr signature scheme and which was created by Claus Schnorr in 1989. This was patented as a "Method for identifying subscribers and for generating and verifying electronic signatures in a data exchange system". The patent ran out in 2008.
87. Curve 25519 uses the prime number of 2²⁵⁵-19 and was created by Daniel J. Bernstein.
88. Peter Shor defined that elliptic curve methods can be broken with quantum computers.
89. To overcome the cracking of the ECDSA signature from quantum computers, NIST are standardising a number of methods. At present, this focuses on CRYSTALS-Dilithium, and which is a lattice cryptography method.
90. Bulletproofs were created in 2017 by Stanford's Applied Cryptography Group (ACG). They define a zero-knowledge proof as where a value can be checked to see it lies within a given range. The name "bulletproofs" is defined as they are short, like a bullet, and with bulletproof security assumptions.
91. Homomorphic encryption methods allow for the processing of encrypted values using arithmetic operations. A public key is used to encrypt the data, and which can then be processed using an arithmetic circuit on the encrypted data. The owner of the associated private key can then decrypt the result.
92. Some traditional public key methods enable partial homomorphic encryption. RSA and ElGamal allow for multiplication and division, whilst Pailier allows for homomorphic addition and subtraction.
93. Full homomorphic encryption (FHE) supports all of the arithmetic operations and includes Fan-Vercauteren (FV) and BFV (Brakerski/Fan-Vercauteren) for integer operations and HEAAN (Homomorphic Encryption for Arithmetic of Approximate Numbers) for floating point operations. Most of the Full Homomorphic encryption methods use lattice cryptography.
94. Some blockchain applications use Barreto-Lynn-Scott (BLS) curves which are pairing-friendly. They can be used to implement Bilinear groups and which are a triplet of groups (G1, G2 and GT), so that we can implement a function e() such that e(g1^x,g2^y)=gT^{xy}. Pairing-based cryptography is used in ZKPs.
95. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477.
96. An accumulator can be used for zero-knowledge proof of knowledge, such as using a BLS curve to create to add and remove proof of knowledge.
97. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains.
98. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers.
99. With a Verifiable Delay Function (VDF), we can prove that a given amount of work has been done by a prover (Peggy). A verifier (Victor) can then send the prover a proof value and compute a result which verifies the work has been done, with the verifier not needing to do the work but can still prove the work has been done.
100. A Physical Unclonable Functions (PUFs) is a one-way function which creates a unique signature pattern based on the inherent delays within the wires and transistors. This can be used to link a device to an NFT.

Interview here:

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

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

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

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

DigitalScotland 2023 DigitalScotland 2023 is designed for public sector leaders whose goal is to drive transformational change - both within…

futurescot.com

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

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

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

The Problem

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

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

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

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

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

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

The Vision

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

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

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

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

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

How long for this to happen?

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

GLASS: Control your own data with EU Digital ID Wallet The GLASS Consortium came together on 14-15 June 2022 in Lisbon, Portugal for the 5th Plenary Meeting of the Project…

tages.biz

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

And in November [here]:

Conclusions

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

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

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

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

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

So, what's wrong with spreadsheets?

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

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

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

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

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

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

Conclusions

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

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

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

1. Blockchains use public key methods to integrate digital trust. Bob signs for a transaction with his private key, and Alice proves this with Bob's public key.
2. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled "Cryptographic Communications System and Method".
3. Blockchains can either be permissioned (requiring rights to access the blockchain) or permissionless (open to anyone to use). Bitcoin and Ethereum are the two most popular permissionless blockchains, and Hyperledger is the most popular permissioned ledger.
4. Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash.
5. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method).
6. David Chaum is considered as founders of electronic payments, and, in 1983, created ECASH, along with publishing a paper on "Blind signatures for untraceable payments".
7. Miners gather transactions on a regular basis, and these are added to a block and where each block has a Merkle hash.
8. The first block on a blockchain does not have any previous blocks — and is named the genesis block.
9. Blocks are bound in a chain, and where the previous, current and next block hashes are bound into the block. This makes the transactions in the block immutable.
10. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment.
11. Craig Steven Wright has claimed that he is Satoshi Nakamoto, but this claim has never been verified.
12. Most blockchains use elliptic curve cryptography — a method which was created independently by Neal Koblitz and Victor S. Miller in 1985.
13. Elliptic curve cryptography algorithms did not take off until 2004.
14. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security.
15. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass ("Vier-strass") curve.
16. The prime number used with secp256k1 is ²²⁵⁶−²³²−²⁹−²⁸−²⁷−²⁶−²⁴−1.
17. Satoshi published a 9-page paper entitled "Bitcoin: A Peer-to-Peer Electronic Cash System" White Paper on 31 Oct 31, 2008.
18. In 1997, Adam Black introduce the concept of Proof of Work of Hashcash in a paper entitled, "Hashcash — a denial of service countermeasure." This work was used by Satoshi in his whitepaper.
19. Satoshi focused on: a decentralized system, and a consensus model and addressed areas of double-spend, Sybil attacks and Eve-in-the-middle.
20. The Sybil attack is where an adversary can take over the general consensus of a network — and leads to a 51% attack, and where the adversary manages to control 51% or more of the consensus infrastructure.
21. Satoshi used UK spelling in his correspondence, such as using the spelling of "honour".
22. The first Bitcoin block was minted on 3 Jan 2009 and contained a message of "Chancellor on brink of second bailout for banks" (the headline from The Times, as published in London on that day).
23. On 12 Jan 2009, Satoshi sent the first Bitcoin transaction of 50 BTC to Hal Finney [here].
24. A new block is created every 7–10 minutes on Bitcoin.
25. In Aug 2023, the total Bitcoin blockchain size is 502 GB.
26. As of Aug 2023, the top three cryptocurrencies are Bitcoin, Ether, and Tether. Bitcoin has a capitalization of $512 billion, Ether with $222 billion, and Tether at $83 billion. The total cryptocurrency capitalisation is $1.17 trillion.
27. The original block size was 1MB for Bitcoin, but recently upgraded to support a 1.5MB block — and has around 3,000 transactions. Currently the block sizes are more than 1.7MB.
28. Bitcoin uses a gossip protocol — named the Lightning Protocol — to propagate transactions.
29. A Bitcoin wallet is created from a random seed value. This seed value is then used to create the 256-bit secp256k1 private key.
30. A wallet seed can be converted into a mnemonic format using BIP39, and which uses 12 common words. This is a deterministic key, and which allows the regeneration of the original key in the correct form.
31. BIP39 allows for the conversion of the key to a number of languages, including English, French and Italian.
32. A private key in a wallet is stored in a Wif format, and which is a Base58 version of the 256-bit private key.
33. The main source code for the Bitcoin blockchain is held at https://github.com/bitcoin, and is known as Bitcoin core. This is used to create nodes, store coins, and transactions with other nodes on the Bitcoin network.
34. A 256-bit private key has 115,792 billion billion billion billion billion billion billion billion different keys.
35. A public Bitcoin ID uses Base58 and has a limited character set of '123456789ABCDEFGHJKLMN PQRSTUVWXYZabcdefghijkmno pqrstuvwxyz', where we delete '0' (zero), 'l' (lowercase 'l'), and 'I' (capital I) — as this can be interpreted as another character.
36. In Bitcoin and Ethereum, a private key (x) is converted to a public key with x.G, and where G is the base point on the secp256k1 curve.
37. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a "04".
38. A compressed secp256k1 public key only stores the x-co-ordinate value and whether the y coordinate is odd or even. It starts with a "02" if the y-co-ordinate is even, otherwise it starts with a "03".
39. In 1992, Eric Hughes, Timothy May, and John Gilmore set up the cypherpunk movement and defined, "We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money."
40. In Ethereum, the public key is used as the identity of a user (a.G), and is defined as a hexademical value.
41. In Bitcoin, the public ID is created from a SHA256 hash of the public key, and then a RIPEMD160 of this, and then covered to Base58.
42. In computing the public key in ECC of a.G, we use the Montgomery multiplication method and which was created by Peter Montgomery in 1985, in a paper entitled, "Modular Multiplication without Trial Division."
43. Elliptic Curve methods use two basic operations: point address (P+G) and point doubling (2.P). These can be combined to provide the scalar operation of a.G.
44. In 1999, Don Johnson Alfred Menezes published a classic paper on "The Elliptic Curve Digital Signature Algorithm (ECDSA)". It was based on the DSA (Digital Signature Algorithm) — created by David W. Kravitz in a patent which was assigned to the US.
45. The core signature used in Bitcoin and Ethereum is ECDSA (Elliptic Curve Digital Signature Algorithm), and which uses a random nonce for each signature. The nonce value should never repeat or be revealed.
46. Ethereum was first conceived in 2013 by Vitalik Buterin, Gavin Wood, Charles Hoskinson, Anthony Di Iorio and Joseph Lubin. It introduced smaller blocks, an improved proof of work, and smart contracts.
47. Bitcoin is seen as a first-generation blockchain, and Ethereum as a second-generation. These have been followed by third-generation blockchains, such as IOTA, Cardano and Polkadot — and which have improved consensus mechanisms.
48. Bitcoin uses a consensus mechanism which is based on Proof-of-Work, and where miners focus on finding a block hash that has a number of leading "0"s.
49. The difficulty of the mining is defined by the hashing rate. At the current time, this is around 424 million TH/s.
50. There are around 733,000 unique Bitcoin addresses being used.
51. Satoshi defined a reward to miners for finding the required hash. This was initially set at 50 BTC, but was set to half at regular intervals. On 11 January 2021, it dropped from 12.5 BTC to 6.2 BTC.
52. Bitcoin currently consumes around 16.27 GWatts of power each year to produce a consensus — equivalent to the power consumed by a small country.
53. In creating bitcoins, Satoshi created a P2PKH (Pay to Public Key Hash) address. These addresses are used to identify the wallet to be paid and links to the public key of the owner. These addresses start with a '1'.
54. In order to support the sending of bitcoins to and from multiple addresses, Bitcoin was upgraded with SegWit (defined in BIP141). The wallet address then integrates the pay-to-witness public key hash (Pay to script hash — P2SH). These addresses start with a '3'.
55. Ethereum uses miners to undertake work for changing a state and running a smart contract. They are paid in "gas" or Ether and which relates to the amount of computation conducted. This limits denial of service attacks on the network and focuses developers on creating efficient code.
56. Ethereum supports the creation of cryptocurrency assets with ERC20 tokens — and which are FT (Fungible Tokens). For normal crypto tokens (ERC-20) we use, there is a finite number of these, and each of these is the same.
57. Ethereum creates NFTs (Non-Fungible Tokens) with ERC721 tokens. We mint these each time and each is unique.
58. Solidity is the programming language used in Ethereum, while Hyperledger can use Golang, Node.js and Java.
59. For Ethereum, we compile Solidity code into EVM (Ethereum Virtual Machine) code. This is executed on the blockchain.
60. Blockchain uses the SHA-256 hash for transaction integrity.
61. Ethereum uses the Keccak hash is used to define the integrity of a transaction. This is based on SHA-3, and differs slightly from Keccak.
62. The Keccak hash family uses a sponge function and was created by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, and standardized by NIST in August 2015 as SHA-3.
63. The DAO is a decentralized autonomous organization (DAO) for the Ethereum blockchain and was launched in 2016.
64. In 2016, DAO raised $150 million through a token sale but was hacked and funds were stolen. This resulted in a forking of the blockchain: Ethereum and Ethereum Classic.
65. Non-interactive Zero Knowledge Proofs (NI-ZKP) allow an entity to prove that they have knowledge of something — without revealing it. A typical secret is the ownership of a private key.
66. NI-ZKPs involve a prover (Peggy), a verifier (Victor) and a witness (Wendy) and were first defined by Manuel Blum, Paul Feldman, and Silvio Micali in their paper entitled, "Non-interactive zero-knowledge and its applications".
67. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge).
68. Bitcoin and Ethereum are pseudo-anonymised, and where the sender and recipient of a transaction, and its value, can be traced. Privacy coins enable anonymous transactions. These include Zcash and Monero.
69. In 1992, David Chaum and Torben Pryds Pedersen published "Wallet databases with observers," and outlined a method of shielding the details of a monetary transaction.
70. In 1992, Adi Shamir (the "S" in RSA) published a paper on "How to share a secret" in the Communications of the ACM. This supported the splitting of a secret into a number of shares (n) and where a threshold value (t) could be defined for the minimum number of shares that need to be brought back together to reveal the secret. These are known as Shamir Secret Shares (SSS).
71. In 1991, Torbin P Pedersen published a paper entitled "Non-interactive and information-theoretic secure verifiable secret sharing" — and which is now known as Pedersen Commitment. This is where we produce our commitment and then show the message that matches the commitment.
72. Distributed Key Generation (DKG) methods allow a private key to be shared by a number of trusted nodes. These nodes can then sign for a part of the ECDSA signature by producing a partial signature with these shares of the key.
73. Not all blockchains use ECDSA. The IOTA blockchain uses the EdDSA signature, and which uses Curve 25519. This is a more lightweight signature version, and has better support for signature aggregation. It uses Twisted Edwards Curves.
74. The core signing method used in EdDSA is based on the Schnorr signature scheme and which was created by Claus Schnorr in 1989. This was patented as, a "Method for identifying subscribers and for generating and verifying electronic signatures in a data exchange system". The patent ran out in 2008.
75. Curve 25519 uses the prime number of ²²⁵⁵-19 and was created by Daniel J. Bernstein.
76. Peter Shor defined that elliptic curve methods can be broken with quantum computers.
77. To overcome the cracking of the ECDSA signature from quantum computers, NIST are standardising a number of methods. At present, this focuses on CRYSTALS-Dilithium, and which is a lattice cryptography method.
78. Bulletproofs were created in 2017 by Stanford's Applied Cryptography Group (ACG). They define a zero-knowledge proof as where a value can be checked to see it lies within a given range. The name of "bulletproofs" is defined as they are short, like a bullet, and with bulletproof security assumptions.
79. While Bitcoin can take up to 7–10 minutes to mine a new block and create a consensus, newer blockchains, such as IOTA, can give an almost instantaneous consensus.
80. Banks around the world are investigating CBDC (Central Bank Digital Currency) and which is not a cryptocurrency but a way to quickly define a consensus on a transaction.
81. Homomorphic encryption methods allow for the processing of encrypted values using arithmetic operations. A public key is used to encrypt the data, and which can then be processed using an arithmetic circuit on the encrypted data. The owner of the associated private key can then decrypt the result.
82. Some traditional public key methods enable partial homomorphic encryption. RSA and ElGamal allow for multiplication and division, whilst Pailier allows for homomorphic addition and subtraction.
83. Full homomorphic encryption (FHE) supports all of the arithmetic operations and includes Fan-Vercauteren (FV) and BFV (Brakerski/Fan-Vercauteren) for integer operations and HEAAN (Homomorphic Encryption for Arithmetic of Approximate Numbers) for floating point operations. Most of the Full Homomorphic encryption methods use lattice cryptography.
84. Some blockchain applications use Barreto-Lynn-Scott (BLS) curves which are pairing friendly. They can be used to implement Bilinear groups and which are a triplet of groups (G1, G2 and GT), so that we can implement a function e() such that e(g1^x,g2^y)=gT^{xy}. Pairing-based cryptography is used in ZKPs.
85. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477.
86. An accumulator can be used for zero-knowledge proof of knowledge, such as using a BLS curve to create to add and remove proof of knowledge.
87. Open Zeppelin is an open-source Solidity library that supports a wide range of functions that integrate into smart contracts in Ethereum. This includes AES encryption, Base64 integration and Elliptic Curve operations.
88. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains.
89. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers.
90. Solidity programs can be compiled with Remix at remix.ethereum.org.
91. The main Ethereum network is Ethereum Mainnet. We can test smart contracts on Ethereum test networks. Current networks include sepolia.etherscan.io and goerli.net.
92. Ether can be mined for test applications from a faucet, such as faucet.metamask.io. This normally requires some proof of work to gain the Ether — in order to protect against a Denial of Service against the Faucet.
93. The private key can be revealed from two ECDSA signatures which use the same random nonce value.
94. Polkadot is a blockchain which allows blockchains to exchange messages and perform transactions.
95. The proof of work method of creating is now not preference because of the energy that it typically uses. Many systems now focus on proof of stack (PoS).
96. A time-lock puzzle/Proof of Work involves performing a computing task which has a given cost and which cannot be cheated again. This typically involves continual hashing or continual squaring.
97. The Chia blockchain network uses both Proof of Space (PoS) and Proof of Time (PoT). The PoS method makes use of the under-allocation of hard-disk space.
98. With a Verifiable Delay Function (VDF), we can prove that a given amount of work has been done by a prover (Peggy). A verifier (Victor) can then send the prover a proof value and compute a result which verifies the work has been done, with the verifier not needing to do the work but can still prove the work has been done.
99. A Physical Unclonable Functions (PUFs) is a one-way function which creates a unique signature pattern based on the inherent delays within the wireless and transistors. This can be used to link a device to an NFT.
100. In Blockchain applications, we can use Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) — DLEQ. With this — in discrete logarithms — we have 𝑎=𝑔^x and 𝑏=ℎ^x and can prove the knowledge of x by showing that log_𝑔(𝑎)=log_ℎ(b).

Blog: here.

You can just imagine the movie trailer …

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

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

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

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

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

CrashOverRide and Titon

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

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

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

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

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

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

DM-PLC

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

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

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

Figure 1 [1]

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

Figure 2: Polling of devices

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

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

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

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

Conclusions

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

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

References

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