I have to select a secure file transfer protocol, to be implemented in a pre-boot system. I have access to libraries with the basic network functionalities (IP, TCP, UDP, etc...). I might also have access to the OpenSSL library.

I need to know which would be the easiest one to implement, in case I have the OpenSSL library available, and also if I do not. I do not have a SSH client, so I would have to implement it in case of using SFTP.

Finally, I would really like if someone could give me a justified statement on which is easier to implement (and by easier I mean less time consuming) between SSH or SSL/TLS.

  • 1
    From my reading this doesn't really fit into the purpose of this site. We focus more on" ...protecting assets from threats and vulnerabilities." than straight development, it also comes across as fairly subjective which is frowned upon. Please have a read of the FAQ to see what I mean. Please clarify the security aspects, or it may get moved to one of our sister-sites where it could receive some better traction. – Scott Pack Sep 22 '11 at 18:17
  • 2
    Agree with @Scott - this is not actually a security question, it is an implementation question. But it seems too subjective in any case: I might find it easy to implement SSL/TLS where someone else might fint SFTP easier... – Rory Alsop Sep 22 '11 at 18:25
  • I have read the FAQ and I agree, I would appreciate you moving it to one of your sister-sites cause the topic is about ease to implement, not about security comparison. – Daniel J. García Sep 23 '11 at 14:49

If you have OpenSSL then use SSL/TLS: the protocol which is simplest to implement is the one which is already implemented. SSL just offers a raw tunnel, so you would have to include some kind of management protocol which organizes the actual "file transfer", e.g. HTTP. HTTP within SSL is known as HTTPS: that's standard, so the hard work of specifying the protocol is already done.

Without OpenSSL, I would still personally recommend SSL/TLS for the following reason: I have done it (SSL client and server for embedded systems, each fits in less than 20 kB of code). So I know it is doable. Also, there are other SSL/TLS libraries targeted at small systems, e.g. CyaSSL or axTLS.

Reimplementing the SSH protocol should not be awfully harder than reimplementing SSL, but the SSH specification is bigger (it begins at RFC 4251, which describes the architecture, and the actual protocol is spread over several subsequent RFC; on the other hand, SSL/TLS fits in the single RFC 5246). That's obviously a not-very-objective way of choosing a protocol, but it is not totally uncalled for either.

For SSL/TLS, I suggest the following:

  • Use TLS 1.2 and do not bother with previous versions (you control the client and the server, so you can enforce a specific version). TLS 1.2 requires the implementation of only one hash function, while previous versions required both MD5 and SHA-1.

  • Use a single cipher suite (e.g. TLS_RSA_WITH_AES_128_CBC_SHA256). This simplifies things quite a bit and allows you to hardcode things like block size or MAC length.

  • Use RSA key exchange and arrange for your system to be the "client": this allows it to use RSA in encryption mode only, which is notably simpler to implement than decryption. Also, the client needs not store an asymmetric private key, which is good since secure key storage is difficult.

  • Do not try to decode certificates. In normal SSL/TLS, the server sends its public key to the client as part of an X.509 certificate chain; the client is supposed to validate the chain with regards to a hard-coded public key. Just cut the middle-man, and hardcode the server public key in the client (X.509 certificate chain validation can be done -- even in 6 kB of code -- but it is utterly tricky).

Either way, without a crypto library on hand, you will have to reimplement a few basic algorithms, and that's known not to be easy (especially if you want to avoid side-channel attacks, which are always a concern with embedded systems). You will also need access to a cryptographically secure source of random number: on a pre-boot system, this may prove difficult. But it is extremely important for security.

  • 1
    Thank you very much for your answer, you do not know how much you have helped me :) – Daniel J. García Sep 23 '11 at 14:49

I'd vote for scp. Very simple, secure, and lots of options to customize. sftp is in the same boat, other than being slightly more complicated.

  • 1
    I think the "very simple" part only is for the SCP protocol itself, but you still need the underlying SSH protocol for the "secure" part, and this is not "very simple". SFTP might be more performant for high-latency connections than SCP, since it needs less round-trips, if implemented right. – Paŭlo Ebermann Oct 4 '11 at 9:50

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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