mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-08-04 09:50:19 +03:00
Mahipal
2fb6a9faff
Each rewritten description now states both what the skill does (concrete capability, named tools/artifacts) and an explicit when-to-use trigger, improving agent discovery/activation. Grounded in each skill's own body; changes confined to the `description` field only (bodies and all other frontmatter untouched). Produced by a gated audit->rewrite->recheck loop (548 -> 0 flagged) with a sampled anti-invention check (0 ungrounded). Schema: 817/817 pass. Framework-ID gate: 0 defects.
87 lines
3.3 KiB
Markdown
87 lines
3.3 KiB
Markdown
---
|
|
name: implementing-end-to-end-encryption-for-messaging
|
|
description: Implements a simplified Signal Protocol-style end-to-end encryption scheme for messaging, covering key exchange, forward secrecy, and the core cryptographic components so no server or intermediary can decrypt messages. Use when designing or building E2EE messaging, or evaluating forward-secrecy and key-management tradeoffs for a messaging system.
|
|
domain: cybersecurity
|
|
subdomain: cryptography
|
|
tags:
|
|
- cryptography
|
|
- encryption
|
|
- e2e
|
|
- messaging
|
|
- signal-protocol
|
|
version: '1.0'
|
|
author: mahipal
|
|
license: Apache-2.0
|
|
nist_csf:
|
|
- PR.DS-01
|
|
- PR.DS-02
|
|
- PR.DS-10
|
|
mitre_attack:
|
|
- T1600
|
|
- T1573
|
|
- T1553
|
|
- T1486
|
|
---
|
|
# Implementing End-to-End Encryption for Messaging
|
|
|
|
## Overview
|
|
|
|
End-to-end encryption (E2EE) ensures that only the communicating parties can read messages, with no intermediary (including the server) able to decrypt them. This skill implements a simplified version of the Signal Protocol's Double Ratchet algorithm, using X25519 for key exchange, HKDF for key derivation, and AES-256-GCM for message encryption.
|
|
|
|
|
|
## When to Use
|
|
|
|
- When deploying or configuring implementing end to end encryption for messaging capabilities in your environment
|
|
- When establishing security controls aligned to compliance requirements
|
|
- When building or improving security architecture for this domain
|
|
- When conducting security assessments that require this implementation
|
|
|
|
## Prerequisites
|
|
|
|
- Familiarity with cryptography concepts and tools
|
|
- Access to a test or lab environment for safe execution
|
|
- Python 3.8+ with required dependencies installed
|
|
- Appropriate authorization for any testing activities
|
|
|
|
## Objectives
|
|
|
|
- Implement X25519 Diffie-Hellman key exchange for session establishment
|
|
- Build the Double Ratchet key management algorithm
|
|
- Encrypt and decrypt messages with per-message keys
|
|
- Implement forward secrecy (compromise of current key does not reveal past messages)
|
|
- Handle out-of-order message delivery
|
|
- Implement key agreement using X3DH (Extended Triple Diffie-Hellman)
|
|
|
|
## Key Concepts
|
|
|
|
### Signal Protocol Components
|
|
|
|
| Component | Purpose | Algorithm |
|
|
|-----------|---------|-----------|
|
|
| X3DH | Initial key agreement | X25519 |
|
|
| Double Ratchet | Ongoing key management | X25519 + HKDF + AES-GCM |
|
|
| Sending Chain | Per-message encryption keys | HMAC-SHA256 chain |
|
|
| Receiving Chain | Per-message decryption keys | HMAC-SHA256 chain |
|
|
| Root Chain | Derives new chain keys on DH ratchet | HKDF |
|
|
|
|
### Forward Secrecy
|
|
|
|
Each message uses a unique encryption key derived from a ratcheting chain. After a key is used, it is deleted, ensuring that compromise of the current state does not reveal previously sent/received messages.
|
|
|
|
## Security Considerations
|
|
|
|
- Delete message keys immediately after decryption
|
|
- Implement message ordering and replay protection
|
|
- Use authenticated encryption (AES-GCM) for all messages
|
|
- Protect identity keys with device-level security
|
|
- Verify identity keys out-of-band (safety numbers)
|
|
|
|
## Validation Criteria
|
|
|
|
- [ ] X25519 key exchange produces shared secret
|
|
- [ ] Messages encrypt and decrypt correctly between two parties
|
|
- [ ] Different messages produce different ciphertexts
|
|
- [ ] Forward secrecy: old keys cannot decrypt new messages
|
|
- [ ] Out-of-order messages can be decrypted
|
|
- [ ] Tampered messages are rejected by authentication
|