Archive

Monthly Archives: August 2013

I’ve just managed to successfully implement a java technology proof of concept for the SMT encryption scheme, ecies384-aes256 and ecies384+rsa-aes256

The concrete schemes are defined as:

encryption( M, PF, (K-A,K-a), K-B, A-B ) -> E, L
{
validate A-B must be a 384bit X.509 encoded EC sessionKey.
EC key generate (A-A,A-a), an EC keypair on secp384r1
ECDH key agreement (A-a,A-B) => shared secret S
PFS := SHA256(PF) – convert the PF into a shared secret.
SKe || IVe:= SHA384(S||PFS),
where SKe is a 256bit AES encryption key,
IVe is a 128bit initialization vector for the AES encryption
E := AES256/CTR(SKe,IVe,ZLib(M||Sign(K-a,M||byte-len(M))))
L := byte-len(M) || A-A
where byte-len(M) is the length of M in bytes represented as 8-byte fixed length big-endian integer.
A-A is a X.509 encoded EC public key – aka the sender’s messageKey
}
The encrypted data E is the compressed message and signature symmetrically encrypted with the derived secret key. The encryption context L is the concatenation of the message plaintext length with the unique EC public key of the originator. The length of the plaintext message is known outside the encrypted data so that suitable buffer space can be made available at decryption time and bound the decompression.

decryption( PF, (K-B, K-b), (A-B, A-b), K-A, E, L ) -> M
{
E := AES256/CTR(SKe,IVe,ZLib(M||Sign(K-a,M)))
L := byte-len(M) || A-A
where byte-len(M) is the length of M in bytes represented as 8-byte fixed length big-endian integer.
A-A is a X.509 encoded EC public key

PFS := SHA256(PF) – convert the PF into a shared secret.
ECDH key agreement (A-b,A-A) => shared secret S
SKe || IVe:= SHA384(S||PFS),

M || Sign(K-a,M) := GUNZIP(byte-len(M), AES256/CTR(SKe,IVe,E))
where decompression fails if invalid stream or if decompressed length > byte-len(M) or stream ends before byte-len(M) bytes are decompressed.
verify(K-A, M, Sign(K-a,M)) and fail if signature incorrect.
}

The ecies384+rsa-aes256 is a minor variant on ecies384-aes256 where

L := RSAEncrypt( K-B, byte-len(M) || A-A )

The encryption-context is encrypted with the destination user’s RSA public 2048bit key. This scheme “hides” the senders messageKey, by encrypting it with K-B. Only the destination can decrypt the messageKey and message length the destination’s private key K-b.

A lot of my time was spent implementing a temporary file backed input and output streams, so that the indefinitely long data could be written and read with encryption/decryption happening on the fly. I will eventually release the code under some open license – but first i want to get some kind of feedback from the crypto community about the value of the scheme itself. I also want to implement a cascading of AES with some other block/stream cipher. This is discussed by Zooko at the The Least-Authority File System blog.

Advertisements

One of the main features of SMT is that the message encryption scheme is “forward secure”. This means that if the loss or compromize of the recipient’s encryption private key does not allow the attacker to decrypt “past” messages the attacker is assumed to have. The attacker can only decrypt the messages going “forward” with the stolen key. The forward security is achieved generally by “changing the key” with time. For instance with TLS/SSL’s ECDHE provides forward security through the sender and receiver agreeing a new session key for each new TLS session. In SMT, I proposed that the receiver publishes new session keys over time ( as often as it wants ) and that these are back-propagated to the senders. I was worried if there was some “vulnerability” in re-using the ECDH public key of the recipient for an entire session ( in contrast to TLS which uses a new “ephemeral” key for each session ).

Thankfully i came across a question on Crypto Stackoverflow which pointed me to the information about Integrated Encryption Schemes, where the scheme i propose in SMT is basically ECIES which is standardised in IEEE P1363a, but where the static EC public key of the session is changing with time.

SMT could also support a variety of DiffieHellmann based schemes, like ECIES-KEM, PSEC-KEM, ACE-KEM like mentioned in A Proposal for an ISO Standard for Public Key Encryption.

Given that many very clever people have been thinking about this encryption scheme for a long time gives me more confidence in the security of SMT.