Storing Message Content and Phone Numbers
When handling sensitive data such as message content and phone numbers, it is crucial to implement robust data protection measures to ensure privacy, security, and compliance with legal regulations. Below is a breakdown of the key considerations for storing this data securely:
Message Content
Store Securely:
If message content must be stored, ensure it is kept in a secure environment with restricted access.
Use strong access controls, such as role-based permissions, to limit who can view or modify the data.
Regularly audit and monitor access logs to detect unauthorized activity.
Do Not Store:
Avoid storing message content unless necessary.
If storage is not required, ensure that data is deleted immediately after processing or transmission.
Encrypt & Store:
If storage is necessary, encrypt the message content both at rest and in transit using industry-standard encryption protocols (e.g., AES-256).
Implement key management practices to securely store and rotate encryption keys.
Mobile Number
Store Securely:
Store phone numbers in a secure database with strict access controls.
Use pseudonymization or tokenization techniques to reduce the risk of exposing raw data.
Do Not Store:
Avoid storing phone numbers unless required for operational or legal purposes.
If storage is unnecessary, ensure the data is discarded after use.
Encrypt & Store:
Encrypt phone numbers using strong encryption algorithms to protect them from unauthorized access.
Ensure encryption keys are managed securely and stored separately from the encrypted data.
Encryption Methods
The following table illustrates the multiple encryption methods used for encrypting the message content and mobile numbers of users in Wisely.
Algorithm | Type | Key Size / Hash Size | Use cases |
---|---|---|---|
AES-128 | Symmetric Encryption | 128-bit key | Fast encryption |
AES-256 | Symmetric Encryption | 256-bit key | High-security encryption |
HMAC-SHA256 | Message Authentication | 256-bit hash | API security, JWT, TLS |
HMAC-SHA512 | Message Authentication | 512-bit hash | High-security authentication |
SHA-256 | Hashing | 256-bit hash | Blockchain, SSL certificates, digital signatures |
SHA-512 | Hashing | 512-bit hash | Password hashing, high-security encryption |
Encryption Modes
When using encryption algorithms like AES, the mode of operation determines how data blocks are encrypted and linked together. Here’s a breakdown of four common modes:
CBC (Cipher Block Chaining) Mode
How it Works:
Encrypts data in fixed-size blocks (e.g., 128-bit for AES).
Uses an Initialization Vector (IV) to add randomness to the first block.
Each block’s encryption depends on the previous block’s ciphertext, creating a chaining effect.
CFB (Cipher Feedback) Mode
How it Works:
Turns a block cipher into a stream cipher.
Instead of encrypting whole blocks, it encrypts smaller segments (e.g., 8-bit, 128-bit).
Uses an IV, and each encrypted segment is fed back into the cipher for the next encryption.
CTR (Counter) Mode
How it Works:
Encrypts blocks using a counter value that increments with each block.
Works like a stream cipher, where the counter is encrypted and XORed with plaintext.
Encryption and decryption can happen in parallel since each block is independent.
OFB (Output Feedback) Mode
How it Works:
Turns a block cipher into a stream cipher like CFB.
Instead of using ciphertext feedback, it uses the output of the encryption function.
The same keystream can be reused for encryption and decryption.
Which Mode Should You Use?
For high-speed encryption: Use CTR mode.
For file encryption: Use CBC mode.
For streaming data: Use CFB or OFB mode.
For security-critical applications: Ensure IVs/counters are never reused!
Padding Schemes
Block ciphers (like AES) work with fixed-size blocks (e.g., 128-bit). If the plaintext size isn’t a multiple of the block size, padding is added to fill the gap. Different padding schemes exist to handle this.
ANSI X.923 Padding
How It Works:
The missing bytes are filled with zeroes (0x00) except for the last byte, which stores the number of padding bytes.
Example (AES with 8-byte block size):
Plaintext:
HELLO
(5 bytes)Padded:
HELLO 00 00 03
(8 bytes, last byte =03
)
ISO/IEC 9797-1 Padding
How It Works:
Similar to ANSI X.923, but the first padding byte is set to 1 (0x80), and the rest are zeroes (0x00).
Example (AES with 8-byte block size):
Plaintext:
HELLO
(5 bytes)Padded:
HELLO 80 00 00
(8 bytes)
PKCS5 Padding
How It Works:
The padding bytes all have the same value, equal to the number of padding bytes added.
Example (AES with 8-byte block size):
Plaintext:
HELLO
(5 bytes)Padded:
HELLO 03 03 03
(8 bytes)
PKCS7 Padding
How It Works:
Works like PKCS5, but supports any block size (not just 8 bytes).
Example (AES with 16-byte block size):
Plaintext:
HELLO
(5 bytes)Padded:
HELLO 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B
(16 bytes)
Which Padding Should You Use?
For AES encryption: Use PKCS7 (most widely supported).
For legacy DES encryption: Use PKCS5.
For banking systems: Use ANSI X.923 or ISO 9797-1.