เพิ่มเติม End to End encryption (E2EE)
- Hybrid Encryption
- Symmetric Enc
- Public Key Enc
- gen key pair in device
- Public key of the users shared via the Messenger Service
- Device gen session key (AES) and uses PK’s of receiver to encrypt session key → Send to receiver
- Receiver decrypts CTk
(this session key is used to encrypt message for entire session)
Message Digest: Two properties
- Fixed length
- One Way (irreversible)
One Way Hash
- A hash is produced by putting data through a hashing algorithm
- The result is a fixed length "fingerprint" of the data, usually 128, 160, 256 bits. Same size output for any size input.
- ข้อมูลจะใหญ่แค่ไหน ยาวแค่ไหนก็ตาม hash ให้ออกมา size เดิม
- Like a CRC, but much more sophisticated
- Used to determine if data has changed - possibly maliciously
- Infeasible to produce a document which matches a digest
- ==A one-bit change in the message affects at least half the bits in the digest==
เอามาใช้ในการเช็ค Integrity ยังไง?
Sender เอา Message ไป Encrypt → Ciphertext (CT)
Sender เอา Message ไป Hash → Message Digest (MD)
แล้วส่งไปพร้อมกัน สามารถ Match ได้ว่าถูกต้องมั้ย
ถ้า Match แปลว่า Data is not tampered ไง
Example: https://emn178.github.io/online-tools/sha256.html
Well Known Hash Functions
- MD5
- output 128 bits
- collision resistance completely broken by researchers in China in 2004
- SHA1
- output 160 bits
- no collision found yet, but method exist to find collisions in less than
- considered insecure for collision resistance
- one-wayness still holds
- SHA2 (SHA-224, SHA-256, SHA-384, SHA-512)
- outputs 224, 256, 384, and 512 bits, respectively
- No real security concerns yet
SHA-2
- SHA-256 is widely used, particularly by U.S. government agencies to secure their sensitive data. Much stronger than SHA-1, it includes the most secure hashing algorithm available to the time of writing: SHA-256, also used in Bitcoin transactions.
SHA-2 Process Overview:
Image shows the SHA-2 process with Message Block (512/1024-Bit), Initialization Vectors, multiple rounds (Round 0 through Round 63/79), and final Hash output (224/256/384/512-Bit)

Step to Generate MD of SHA-2
- https://www.educative.io/answers/what-are-the-different-steps-in-sha-256
- https://blog.boot.dev/cryptography/how-sha-2-works-step-by-step-sha-256/
Pros of SHA-2
| Pros of SHA-2 | Cons of SHA-2 |
|---|---|
| It's resistant to collision, to pre-image and second-preimage attacks. | SHA-256 is slower than its predecessors. |
| It addresses SHA-1's weaknesses. | Some software may need updating to support SHA-2 encryption. |
| SHA-256 is supported by the latest browsers, OS platforms, mail clients and mobile devices. | |
| It generates a longer hash value, offering a higher security level making it the perfect choice for validating and signing digital security certificates and files. |
Collision = 2 different inputs produce the same message digest (เกิดขึ้นได้ยังไง? บังเอิญเท่านั้นป้ะ)
Attack on SHA
In cryptography, a preimage attack on cryptographic hash functions tries to find a message that has a specific hash value. A cryptographic hash function should resist attacks on its preimage (set of possible inputs).
In the context of attack, there are two types of preimage resistance:
-
preimage resistance: for essentially all pre-specified outputs, it is computationally infeasible to find any input that hashes to that output; i.e., given , it is difficult to find an such that .
-
second-preimage resistance: for a specified input, it is computationally infeasible to find another input which produces the same output; i.e., given , it is difficult to find a second input such that .
- ความหมายเหมือน Collision ใช่ม้าา
These can be compared with a collision resistance, in which it is computationally infeasible to find any two distinct inputs that hash to the same output; i.e., such that .
Collision resistance implies second-preimage resistance, but does not guarantee preimage resistance. Conversely, a second-preimage attack implies a collision attack (trivially, since, in addition to , is already known right from the start).
A One Way Hash

Characteristics:
- No Key
- Irreversible, Fixed-length
- Examples:
- MD5, SHA-1, SHA-2
Public Key cryptography uses hashes (digests):
- To do integrity checks
- To produce digital signatures
Think of a hash like a fingerprint - it's unique to the data, you can't recreate the person from the fingerprint, and even a tiny change creates a completely different fingerprint.
One Way Hash - Integrity

Sender side:
- Message: "Please Send 1,000 widgets @ $4 each"
- Hashing algorithm produces Message digest
- Both message and digest sent to supplier
Receiver side:
- Receives message and digest
- Runs hashing algorithm on received message
- Compares new digest with received digest
- If they match → message unchanged
One Way Hash - Digital Signature

Creating Digital Signature:
- Start with plaintext: "Please Send 1,000 widgets @ $4 each"
- Apply hashing algorithm → Message Digest
- Encrypt digest with Sender's Private Key using signing algorithm
- Result = Digital Signature
Digital Signature Properties
- Must depend on the message signed
- Must use information unique to sender
- prevent both forgery and denial
- Must be relatively easy to produce
- Must be relatively easy to recognize & verify
- Be computationally infeasible to forge
- Constructing a new message for an existing digital signature
- Constructing a fraudulent digital signature for a given message
- Be practical when keeping a copy of a digital signature in storage
Digital Signature Services
Message Authentication
- Verify author, date & time of signature
- Authenticate message contents
Message Integrity
- Use a hash function → preserve the integrity of the message
Non-repudiation
- One cannot deny that he didn't sign the message
- Use a trusted third party
Digital Signature Process
Image shows Alice (sender) and Bob (receiver) with signing and verifying algorithms

Process:
- Sender (signer) uses a signing algorithm
- Receiver (verifier) uses a verifying algorithm
- Signer uses the private key to sign the document
- Verifier uses the public key of the signer to verify the document
Signing the Digest
Image shows Alice creating signature and Bob verifying it

Process:
- Using public key cryptography is very inefficient when dealing with a long message
- A selected message digest has a one-to-one relationship with the message to reduce the calculation complexity (shorter message)
- Sender can sign the Message Digest (MD), and receiver can verify the MD
It's like signing a summary instead of the entire book - faster but just as secure since the summary is unique to that exact book.
Trusted Center for Non-repudiation
Image shows Alice, Bob, and Trusted Center interaction

Flow:
- Alice sends message with her signature to Trusted Center
- Trusted Center verifies Alice's signature using Alice's public key
- Trusted Center signs the message with its private key
- Bob verifies Trusted Center's signature using Trusted Center's public key
- Bob then verifies Alice's signature
Need for Trust
- Trust in human interactions
- Trust with respect to Individuals, Institutions (bank, hospital, car dealer), Artifacts (car, Internet browser, antivirus software)
- Trust in small village vs. big city
- Small village: implicit trust
- Everybody knows everybody
- Mr. X "feels" how much he can trust Mr. Y
- Small village: implicit trust
- Big city: need to consider trust explicitly
- Ask around to find trusted entities
- Inquire friends, office mates about good car dealer or good dentist
- Check "reputation databases"
- Ask around to find trusted entities
Selected Trust Characteristics
-
Trust comes in with
- Degree of trust (A trust threshold is a degree to which we are willing to believe an unidentified individual)
vs. - binary trust (with a single trust threshold)
- Degree of trust (A trust threshold is a degree to which we are willing to believe an unidentified individual)
-
Ubiquity of trust in social and artificial systems
- Many users/computer systems trusted blindly (without evidence or verification!)
- OS trusts all application programs
- any one is allowed to run on it
- Users trust unknown web sites with personal data
- OS trusts all application programs
- Many users/computer systems trusted blindly (without evidence or verification!)
Forms of Trust
In electronic communication, we must develop ways for two people to establish trust without having to meet
Forms of trust:
- Appearance of authenticity: printed, signed form (Not original one e.g. by fax)
- Outside information: credit report
- "friend of" relationship: trust a friend of a friend
- "vouch for" relationship:
- Someone I trust trusts this other person
- A basis for trust in commercial settings where two parties do not know each other
MEANS OF BUILDING TRUST
"TRUST BUT VERIFY": A RUSSIAN PROVERB
- Familiar with X
- Person: face, voice, handwriting
- Institution: company name, image, good will
- Artifact: manufacturer name, perceived quality
- First-hand experience with X's activities/performance
- Good or bad experience (trust or distrust grows)
- Reputation of X determined by evidence / credentials
- Reputation = second-hand knowledge of X's actions/performance
- Reputation databases with good evidence or lack of bad evidence
- Credentials: X's driver license, library card, credit card
- Affiliation of X with person/institution/artifact Y
- Trust/distrust toward Y rubs off on X
Means of Building Trust
-
Need similar and common efficient/effective trust mechanisms in the cyberspace
-
Need somebody or something to:
- assume risks
- OR
- vouch for the other party
-
A trusted third party (TTP) is a basis for trust
- When two interacting parties do not trust each other sufficiently
Four Simple Rules
- Sign First, then Encrypt
- Compress before Encrypting
- Sign using your Private Key
- Encrypt using Receiver's Public Key
Algorithms
- Symmetric key algorithms:
- DES
- Triple-DES
- IDEA
- RC2, RC4
- AES
- Asymmetric key algorithms:
- RSA
- DSA
- ECC (Elliptic Curve Crypto Signing algorithms)
- Diffie-Hellman
Hash Algorithms & RNGs
-
Common hash algorithms:
- MD5 (128-bit digest)
- SHA-1 (160-bit digest) → not secure now
- SHA-2 (256, 512 bit digest)
- SHA-3
- RIPE-MD (128-bit and 160-bit Versions)
-
Random number generators:
- Blum-Blum-Shub
Key Size is Vital
- Key Size = Strength
Secure Storage of Private Keys
- File based storage:
- Using passphrase-based encryption
- Password+++
- PKCS#12
- Smartcard storage
- Hardware Security Module (HSM) storage
- PKCS#11
Cryptography: Further Reading...
| Publication | Author/Source |
|---|---|
| Applied Cryptography. | Bruce Schneier. Wiley Press. |
| Answers to Frequently Asked Questions about Today's Cryptography. | RSA. Version 4 Available at WWW.RSA.COM |
| Crypto Law Survey | KOOPS: http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm |
| Architecture for Public Key Infrastructure | The Open Group |
| Cryptography & Network Security Principles & Practice (2nd Edition) | William Stallings: Prentice Hall |
One More Problem to Solve:
How do we know who the public key belongs to?
Answer: Digital Certificates!
Issue by CA (Certificate authority), in Thailand, we have ThaiDigitalCA, INET CA
Digital Certificates & Public Key Infrastructure
About Certificates
- A Certificate binds a public key to an owner
- It is the 'envelope' in which the public key is distributed
- It is usually signed by a third party, which has first verified that it contains a valid key and that the owner is who he or she say they are.
A certificate contains:
- Details about Bob
- Details about the certificate issuer
- Bob's public key
- Validity and Expiration dates
- A digest of the certificate contents. The certificate digest is signed by the CA
X.509 DIGITAL CERTIFICATES

How to get certification
0. User generate key pair (Public, Private key)
- User contact CA (buy cert from CA)
- User submits application form + public key → Send to CA
- CA issues cert to user
CA copies the issued certificate in their directory
- ดังนั้นเวลาเรียนเขียน Web App เงี้ย, เราต้องเช็คกับ CA (CRL Distribution Point) ว่า Certificate นั้น ๆ ถูก revoke ไปรึยังไรงี้— DN (Distinguished Name) (O, OU, C, CN), expiry information, cert status, signature, Issuer (CA)
- พวก Adobe ใช้กันแบบนี้
- CRL = Certification Revocation List
Certificates - Issuing
How Bob gets a certificate:
- Bob's Registration Agent (RA) - or end user software - generates public / private key pair
- Bob's Registration Agent checks Bob's ID
- The Registration Agent sends a certificate request (which contains the public key) to the CA
- CA issues certificate and signs it, then returns it to Bob and publishes his certificate
- Bob's software stores certificate
Certificates - Validation
To ensure that Bob's certificate is valid (and hence his public key is valid):
Alice gets Bob's certificate
- Alice's software performs the following:
- Gets certificate of CA that signed his certificate
- Decrypts Bob's certificate digest using the CA's public key
- Takes a digest of Bob's certificate
- Compares the digests
- Checks the expiration dates in Bob's certificate
Certificates - Revocation
- Reasons:
- CA Compromise
- Key Compromise
- Change of Status
- Suspension
- Other
- Certificate Revocation Lists (CRLs) are issued and signed by the CA
- Upon receipt of a Certificate, check the CA's CRL
Certification Revocation Methods
- Check CRLs
- Published in batch (not real-time) (e.g. every X minutes)
- For example, CRL pub period = 5 mins (Every 5 mins, new CRL records/CRL file is updated)
- If latest CRL was published on 8:00 am, the customer made a revocation request on 8:01 am. What’s the problem?
- Maybe stolen key is used at 8:02 am
- Problem: Status of the certificate is still VALID
- CRL is not updated because the next update is at 8:05 am.
- High frequency of CRL update → High communicateion cost (esp. CRL is big)
- Check OCSP (Online Certificate Status protocol)
- Realtime revocation
- Depends on CA software (handling the revocation function)
- Advantage: realtime update of cert status
- Disadvantage: more complex, requires more features and services to support OCSP
- Suitable for sensitive transactions
Securing and Desecuring a Message
Securing a message (Alice sending to Bob):
- Alice creates Bob's payslip
- Hash the document with SHA-2
- Sign the hash with Alice's Private Key (RSA) → Alice's Digital Signature
- Encrypt the document with randomly generated symmetric key (AES)
- Encrypt the symmetric key with Bob's Public Key (RSA)
- Send encrypted document + encrypted key + digital signature to Bob
Desecuring a message (Bob receiving from Alice):
- Bob receives the package
- Decrypt the symmetric key using Bob's Private Key (RSA)
- Decrypt the document using the decrypted symmetric key (AES)
- Verify signature:
- Decrypt Alice's signature using Alice's Public Key (RSA) to get hash
- Hash the received document with SHA-2
- Compare the two hashes
- If same → verified!
This is like putting a letter in a locked box (encryption), signing the outside (digital signature), and giving only the recipient the key (asymmetric cryptography).
Public Key Cryptography
...but public key cryptography, on its own, is not enough if we are to truly re-create the conditions for traditional paper-based commerce in an electronic world. We also need:
-
Security policies to define the rules under which the cryptographic systems should operate
-
Products to generate, store and manage the keys
-
Procedures to dictate how the keys and certificates should be generated, distributed and used
The Components of a PKI
- A Public Key Infrastructure is a combination of hardware and software products, policies and procedures.
- It provides the security required to carry out electronic business so that users who do not know each other can communicate securely through a chain of trust.
- PKI is based on digital IDs known as "digital certificates" which act like "electronic passports", and bind the user's digital signature to his or her public key.
Certification Authorities
- The CA system is the trust basis of a PKI, as it manages public key certificates for their whole life cycle. The CA will:
- Issue certificates by binding the identity of a user or system to a public key with a digital signature
- Schedule expiry dates for certificates
- Ensure certificates are revoked when necessary by publishing Certificate Revocation Lists (CRLs)
- X.500 Standard for Directory
When implementing a PKI, an organisation can either operate its own CA system, or use the CA service of a Trusted Third Party.

RA - Registration Authorities
- Interface between CA and end entities
- Identifies end entity
- The quality of this authentication process determines the level of trust that can be placed in the certificates.
- Keep records of end entities

Directories
- Provide distribution points for certificates and certificate revocation lists
- Can be distributed over networks
- X.500 standard
- for example LDAP server
- (May also be repositories for other information)

Certificate Chain
- Your Cert is signed by your CA
- Your CA's Cert is signed by its CA
- ...and so on
- "Chain of Certificates"
- Last certificate is self-signed by Root CA
- Not usually this long!
Image shows certificate chain visualization with William at top leading down to Root CA at bottom
Current Trends in PKI
- Government controls & CA regulation
- Digital signature legislation
- Key escrow
Emerging Government Controls on Cryptography
- Relaxation of export controls over stronger cryptography
- Move towards more commercially acceptable arrangements
- Voluntary licensing of Certification Authorities
- Access to keys under warrant for Law enforcement OR enforced decryption of cipher text
Key Escrow
- Use of strong cryptography is a concern for both Law Enforcement Agencies and National Security Agencies
- These agencies are promoting the concept of key escrow:
- Involves the back-up of encryption keys with Trusted Third Parties
- Keys released to government agencies upon obtaining a warrant
Key Escrow Vs. Key Archive
- Key Escrow originally favoured by governments as means of:
- controlling use of stronger cryptography
- enabling, under warrant, decryption of cipher text
- Key Archive is a business requirement enabling organisations primarily to recover from:
- loss of keys
- forgetting passwords
- departure of key individuals
BTW - Separate Keypairs
- The problem:
- Backing up private keys without losing non-repudiation
- The answer:
- Separate keypairs for encryption and signing
- Archive the encryption private key, but never the signing private key.
Separate อะไร ก็ Encryption key and Signing key ไง!!
Think of it like having two keys - one for your mailbox (can be copied for mail delivery) and one for your signature stamp (should never be copied).
Conclusion
- Symmetric cryptographic systems are secure provided the key is sufficiently long and secure
- Brute force attack – to try all possible ways to decrypt the ciphertext.
- The future of electronic commerce depends upon the ability to create trust between people that don't know each other
- Asymmetric cryptographic systems provide a range of services which will enable secured electronic commerce
- Once implemented, and operated correctly, PKIs will provide enterprises with security services needed to exploit technology securely
Final Quote
"Given the growing importance of public key cryptography to many applications from e-mail to electronic commerce, a PKI is probably the most critical information security investment a company will make in the next three years."
— Ira Machefsky, Giga Group
PKI
- Technology (Hardware, Software)
- CA
- RA
- Directory (store certs, CRLs)
- Procedure/Policy