in short – because corporations cannot TRUST their employees (enough).
If an email is truly confidential, then only the recipient is able to decrypt the message and read the contents. If the message could be decrypted by anyone else than the recipient, then the message is not truly confidential. Corporations have legitimate security reasons to want to “inspect” the contents of messages, both of those being sent ( authorization ) and those being received (protection). Considering just the sending of messages, corporations will naturally want a mechanism to inspect message contents either before effectively leaving the company premises or in less security conscious environments, being able to analyze the sent contents after sending. Without this possibility, the corporation would have to trust it’s employees absolutely to not abuse the communication possibilities. For example an employee sending company secrets to a legitimate business partner, let alone an email of wikileaks.
In the consumer world, where individuals are working on their own behalves, it is possible that End2End encrypted email systems will become more popular as usability improves and awareness of the insecurity of traditional email increases. I don’t believe Email will suffer extinction because there is no standard alternative for business to consumer communication. This process is very slow, secure email has been around for a long time like ZSentry even if the Lavabit / Darkmail is successfully riding a hype wave thanks to Snowden.
In the corporate world, where employees are working on behalf of some corporation, internal email messaging need not be truly confidential – since the communication takes place within the corporation’s trust boundaries. For messaging from inside to outside corporate boundaries, corporations are unlikely to trust their employees enough to embrace truly confidential email. There may be hybrid “gateway” like products which try to satisfy corporations security requirements – but this will not be truly end2end encryption, the one end of the encryption will still be under the control of the corporation and not in the hands of the employee.
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.
I’m proud to announce the birth of SMT – Secure Messaging Transport. This specification is about a secure asynchronous transport mechanism – think of email for business applications.
This is currently just a concept waiting to be taken to a whole new level.
Often in IT discussions regardless of how formal or informal, with business persons or experts, there is often a fair amount of confusion about the concepts of address and identity.
An address is a topological identifier, a “position” in some space. In order for any two distributed parties to communicate requires a communication channel, with a party at each end. The channel will have an address at each endpoint.
- a chat room name is an address in a chat provider’s collection of chat rooms.
- a GPRS coordinate is an address in the coordinate system of GPRS.
- a map coordinate is an address in the Geographic coordinate system.
- a postal address or POBOX is an address in a national postal services
- a telephone number is an address in the global space of telephone numbers.
- an InternetProtocol address is an address in the Internet.
- a domainname is an address in the DNS namespace, where the function of DNS is to map domainnames to InternetProtocol addresses.
- an email address is the name of a mailbox to which emails can be sent, and received from.
- a JMS queue/Topic is an address in the local namespace of a JMS ServiceProvider.
Eventhough a map coordinate has on first thought nothing to do with communications, it can still be used as the point at which communication can take place with over time. For example two people could exchange letters by going to a specific map coordinate each day but at different times. This can be represented as a communication channel where each endpoint has the same spacial Address, but a different time. In information theory, a communication channel’s endpoints can have both spacial and time dimensions.
An identity is a name associated with an “actor” or “agent” of a system which actively participates in some process. Identities need authentication at the service provider ( so that the service provider can trust the agent claiming the identity is who he says he is ). Once the identity is proven, the service provider can determine the authorizations of the identity – through some prior trust, directory lookup, SSO, or some federated mechanism like XACML.
- Any username used in a login scheme is an Identity.
- Any X.509 certificate claims an Identity of the certificate’s subject attribute.
In the “login” sense above, an email address is also an Identity when someone trying to send or receive email logs into the service provider providing the email address as username together with a password.
This overlapping usage can be a source of confusion, i.e. when an address is used as an identity in some use-case.
In one phrase: lack of interoperability.
Now the reasoning behind the phrase….
ProtocolBuffers is a language independent data format and a set of tools or libraries which Google released into the public domain a few years ago. The unique selling points are language independence and high efficiency / performance. ProtocolBuffers RPC is a remote procedure call client and server side “interface” specification which utilizes the protocol buffer messages and defines “Services”. The RPC api has some very interesting features which are arguably interesting for service providers – like call cancellation, and asynchronous callback on completion.
Now the ProtocolBuffers serialization is very performant – much more so than say SOAP WebServices. Unfortunately Google did not release their own implementation of a RPC library into the public domain. This would not be a problem if they had defined a standard which would standardize interoperability of the RPC services between different implementations – between clients and servers made available by different parties with differing technologies and programming languages. The lack of a “wire format specification” in particular
- means providers need to provide own libraries in all supported languages if they want to achieve a reasonably wide adoption. The current list of Official RPC Implementations shows that most libraries only support 1 language. A few RPC implementations support 2 languages, and the only library ICE which says it supports multiple ( all ) is not actually an Protobuf RPC implementation, but a library which was an existing multilanguage proprietary RPC library which was just extended to support Protobuf message payloads.
- means software vendors cannot choose one library since they’re not compatible with other libraries. For example JBoss application server would not use Tomcat if it were not a standard web application container.
Google could do things differently – example Thrift from Facebook. Thrift provides a reference implementation with each language binding. Having said that, I do appreciate why Google was not prepared to release their RPC implementation(s). You need more than just wireformat to define interoperability. For example
- a service naming concept – or “directory service” ( DNS ). Cloud service providers find themselves partitioning services – not all service providers are going to load balance behind one hostname.
- application layer identity management, authentication and authorization mechanisms
- transport layer security and protection mechanisms.
- logging mechanisms
- accounting mechanisms
- monitoring and administrative remote control of all the above.
I guess if Google were to release an implementation which did all the above, they would be giving up some of their very precious strategic operational advantages.