title: Disadvantage of using Amazon KMS to encrypt / decrypt small application data
body: <p>A pair of Amazon Lambdas will symmetrically encrypt and decrypt a small piece of application data. I want to use Amazon KMS to facilitate this, because it solves the problems of secret storage and key rotation, and then some.</p>
  
  <p>The <a href="https://docs.aws.amazon.com/kms/latest/developerguide/programming-encryption.html" rel="nofollow noreferrer">Amazon KMS Developer Guide</a> indicates:</p>
  
  <blockquote>
    <p>These operations are designed to encrypt and decrypt data keys. They use an AWS KMS customer master key (CMK) in the encryption operations and they cannot accept more than 4 KB (4096 bytes) of data. <em>Although you might use them to encrypt small amounts of data, such as a password or RSA key, they are not designed to encrypt application data.</em></p>
  </blockquote>
  
  <p>It goes on to recommend using <a href="https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html" rel="nofollow noreferrer">AWS Encryption SDK</a> or the <a href="http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html" rel="nofollow noreferrer">Amazon S3 encryption client</a> for encrypting application data.</p>
  
  <p>While the <a href="https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html" rel="nofollow noreferrer">listed advantages of the AWS Encryption SDK</a> are clear as day, and very attractive, especially to a developer who is not a cryptographer, let's assume for the purpose of this question that circumstances are not favorable to those alternatives.</p>
  
  <p><strong>If my application data is sure never to exceed 4k, why <em>specifically</em> shouldn't I simply use Amazon KMS to encrypt and decrypt this data?</strong></p>
  
  <p><em>Use case</em></p>
  
  <p>My team is implementing a new authentication layer to be used across the services and APIs at our company. We're implementing a JWT specification, but whereas we intend to steer clear of the widely documented cryptographic grievances beleaguering JWE / JWS compliant token signing, we're symmetrically encrypting the payload. Thus, we keep the advantage of standard library implementations of non-cryptographic token validation operations (expiry and the rest,) and we leave behind the cryptographic "foot-gun."</p>