0

I am new to the whole encryption thing. I've been reading a lot about it lately but still have some questions. So I am tasked with building a sign on solution on our side that will securely transmit information from our servers to a SaaS.

This information is highly sensitive (not passwords though) and thus why we need to encrypt it. What I am trying to wrap my head around is how I go about sending information about how to decrypt this information to the SaaS. Right now I've got it setup in .net that I encrypt it using AES with a 256b bit key, 128 bit IV, using PKCS7 padding, and the CBC cipher mode. I've read conflicting information on whether or not I should change the key and IV every time or not. If I do change the Key and IV every time how do I securely tell my SaaS about that so that they can decrypt the information? Is there another better practice I should be doing to send this information to the SaaS to be decrypted?

Improve this question
1
  • Is there a reason you cannot simply use https? Https has public key infrastructure already, can be set up to verify client identify, does key exchange properly and if you use TLS 1.2 and appropriate ciphers, is probably stronger than anything you create yourself.
    – crovers
    Sep 15, 2016 at 14:05

2 Answers 2

Reset to default
1

First, I suggest you do not attempt to reinvent the wheel: from your description, you're already out of your depth here and should attempt to build your own security this way (even using known good primitives).

Basically, you have to understand first if you want to protect your data in transit or at rest (or both).

If you want to encrypt data in transit, then use TLS. You can discuss what type of certificate or authentication, ponder about what support you need but at no point should you attempt to replace it with something of your own.

If you want to encrypt data at rest, things are a bit less clear cut. The general rule, however, stay the same: pick a set of standard that fits your need (S/MIME, PGP, PKCS#12 to name a few examples) and use that. You will quickly find out that the hard part is not encryption but key management: storing your cryptographic keys securely while still allowing them to be used when needed is a real challenge in pretty much all cases.

Here are however, a couple of answers to your questions:

IVs should be re-generated for EACH message and never reused. That is a requirement for CBC to be "secure". (note that, personally, when I had to deal with CBC I would rather perpend the data with a single block of random data that I would discard it when decrypting. I found it easier to deal with than keep track of IVs).

The key, however, is secret. Depending on your exact need, it can be static (never changing during normal operation) or dynamic (could be unique to each message and derived from either a key exchange protocol or randomly generated before being encrypted with an asymmetric cypher like RSA).

Speaking of CBC, know that it is NOT considered a secure mode: it can be vulnerable to padding oracle attacks.

Improve this answer
0

Yes, for every application that requires strong security, reusing keys is a bad idea (cough rolling code car keys cough). But changing them without transmitting was always a hard problem. Then assymetric encryption showed up.

I think what you're looking for is the Diffie-Hellman Ephemeral Key Exchange protocol. This is a way to renegotiate keys without an eavesdropper being able to aquire the key.

More info

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .