Data Protection Settings

Prev Next

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

  1. 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.

  2. Do Not Store:

    • Avoid storing message content unless necessary.

    • If storage is not required, ensure that data is deleted immediately after processing or transmission.

  3. 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

  1. 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.

  2. 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.

  3. 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.