5
$\begingroup$

For part of my bachelor thesis (which will be involved in a commercial product), I need to build a cryptosystem that will be used to encrypt and decrypt continuous medical data that is transmitted from a patient to their doctor. The data must be encrypted and decrypted very fast in case of emergency.

Which encryption algorithm should I use? I think I should use AES. Should I involve a public key encryption to exchange shared keys? But I am afraid it may slow down the system and compromise the consistency of data transfer.

Update: The data will be sent from wearable devices on a patient to their doctor so the computing power might be limited. My thesis will not touch on the hardware and networking aspects directly. However, they should be included in the discussion and analysis of my report.

Improve this question
$\endgroup$
14
  • 1
    $\begingroup$ Unless you have severely constrained devices (e.g. smartcards) any encryption is fast. An RSA operation will cost perhaps 10ms on a desktop computer. $\endgroup$
    – CodesInChaos
    Aug 5, 2016 at 7:00
  • 2
    $\begingroup$ This is just a practice project and will never be used in production, right? $\endgroup$
    – CodesInChaos
    Aug 5, 2016 at 7:02
  • $\begingroup$ @CodesInChaos This is part of my bachelor thesis, and I was informed that my thesis will be involved in a commercial product. The data is mostly sent from wearable medical devices and I don't know how constrained they are. $\endgroup$
    – Khoi Tran
    Aug 5, 2016 at 10:48
  • 1
    $\begingroup$ Updated the question accordingly (as there is a big difference between a school project and a bachelor thesis with commercial implementation). As for the consistency of data transfer, I would look at the potential hardware first and ensure there aren’t any network issues you may have to cope with first (eg: working around potential network outages caused by walls between patient/sender and doc/receiver, etc.)… in the end, an instable network (resulting in inconsistent data) can’t be made stable via cryptography. $\endgroup$
    – e-sushi
    Aug 5, 2016 at 13:04
  • 1
    $\begingroup$ @KhoiTran How about using an existing TLS implementation targeting embedded systems? $\endgroup$
    – CodesInChaos
    Aug 5, 2016 at 14:28

1 Answer 1

Reset to default
3
$\begingroup$

The data must be encrypted and decrypted very fast in case of emergency.

Which encryption algorithm should I use? I think I should use AES.

Indeed, symmetric cryptography (such as AES) is a good choice for performances. But a significant factor that you did not mentioned is the platform on which the algorithms will run. Does it contains cryptographic hardware accelerators? If yes, for which kind of algorithms (ECC, AES, RSA, ...)?

That will determine which algorithm will be the most relevant.

For example, if you have hardware accelerators for ECC or RSA, involving asymmetric cryptography to exchange the secret keys used for encryption should not slow down the system that much. In the other case, it can be very challenging to implement it in software with good performances on an embedded device.

This is also the same compromise for the choice of the symmetric algorithm. If you have a hardware accelerator for AES, then you should probably use it. In the other case, AES will not be the fastest algorithm. For efficient software implementations on embedded devices, you can take a look at lightweight ciphers.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thanks for your input. The project will be software implementation on wearable medical devices. I have no knowledge of hardware accelerators. $\endgroup$
    – Khoi Tran
    Aug 5, 2016 at 12:14
  • $\begingroup$ @KhoiTran If your protocol should be implemented in software on wearable devices, then asymmetric cryptography could introduce a significant overhead.But once again, it depends on the platform. $\endgroup$
    – Raoul722
    Aug 5, 2016 at 12:21
  • 2
    $\begingroup$ Just a note related to power: If you don't have a hardware accelerator, SPECK is a good choice for power in software. Even in hardware, the cost of AES is about 80 times the power of raw data (this is a per Joule calculation that seems to be ballpark when you actually test ICs). @KhoiTran I would suggest sending the least amount of data as possible because data transfer is actually your greatest power consumer. $\endgroup$
    – b degnan
    Aug 5, 2016 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.