1

When receiving the credentials for a new device as described in http://cumulocity.com/guides/reference/device-credentials/ we also get the new password, that the cumulocity server has generated for the device.

We would assume that this password contains only printable characters, even though that might not be a general requirement, if seen from a machine2machine point of view.

Is that assummption correct? If not, are there some characters that we can be sure will never appear in those passwords?

Background: we want to encrypt this password and need to chose a padding strategy. It would be easy, if we knew which bytes are safe to use, because they cannot be part of any of the generated passwords.

rob retro
  • 70
  • 5

1 Answers1

1

PKCS#7 padding is safe because the padding bytes are the length of padding.

Note that padding must be applied to every encryption so the padding length is always present. That means that if the data to be encrypted is a block size multiple an entire block of padding myst be added.

But since the application is not fully provided there may be better ways of handling the encryption. One assumption is that HTTPS can not be used for the transport because if it was that would provide the necessary transport security.

There is also how the encryption is done, it is not easy to get security correct.

zaph
  • 111,848
  • 21
  • 189
  • 228
  • Very good idea, we didn't think about that, thank You! You're right, HTTPS is not applicable, otherwise we would just go with that. We need to transmit the password via different protocols, for example MQTT, and it is possible that some parties can't do TLS for that. – rob retro Nov 02 '17 at 09:12