Zbr's days.
June
Sun Mon Tue Wed Thu Fri Sat
23
         
2008
Months
Jun
Oct Nov Dec

About TODO Blog RSS Old blog Projects Gallery Notes

Mon, 23 Jun 2008

Crypto processing in POHMELFS. OpenSSL vs GNU TLS.

If I did not miss something, GNU TLS (I never worked with it) supports very limited amount of ciphers and hashes, so it is not appropriate for filesystem data protection layer.
According to its documentation GNU TLS only supports AES, RC4 and 3DES ciphers and SHA1 and MD5 hashes. There is also only CBC chaining mode and several hash/cipher schemes.

So, POHMELFS server will use OpenSSL for data protection. Sooner or later OpenSSL will get hardware crypto support on Linux too (well, Linux crypto stack should first implement userspace API, which does not exist yet, although there is a work by Loc Ho from AMCC to add such support).

So far I decided to implement following protection scheme: checksumm or encryption will cover full transaction data, but will be applied by chunks:

  • Transaction 'first-level' data, i.e. header and data immediately placed after transaction header. For all commands except page writing it will be finish.
  • For write pages command, each header is generated dynamically and does not exist until data is really being sent, so crypto code will run over all pages and update checksum processing headers and data pages separately. Checkum update should be simple enough, since there are crypto helpers to update and finalize checksum, but encryption is more complex: I requires all chunks to be setup in advance in single scatterlist chain, with dynamic header generation it is too big overhead (it requires not only scatterlist allocation, but also header allocation just for encryption), so encryption will be done separately for headers and pages, and I will have to create some IV propagation scheme (like last bytes of previous unencrypted chunk will become IV for the next chunk, or something like that). I understand, that it may be not very secure approach though.
  • Reading data back from server is simpler, since there are no transactions, and data will be encrypted/checksummed like in the first step above. It is possible, that it will force to increase network header structure a bit (32 or 16 bits to store size of the attached checksumm).

/devel/fs :: Link / Comments (4)

nim wrote at 2008-06-23 17:17:

For what's worth Fedora and Red Hat are slowly draining the security lib swamp and converging on nss (first because OpenSSL has an history of regular API breakage, and second because they've inherited some nss developpers when they bought the Netscape Directory team from AOL)

Zbr wrote at 2008-06-23 17:47:

Yes, the same issue was brought to me in private email, but NSS has lots of problems with server-side development.

First, kernel does not (and should not I think) support SSL and TLS, so there should be some kind of low-level fine-grained crypto support at server side. There is no such support in NSS, so it can not process whole socket dataflow as encrypted stream.

Second, it has very small number of supported ciphers. Documentation says only about rc2/4 and 3des. 3.12 sourse (nss-3.12/mozilla/security/nss/lib/freebl/) also has camellia and rijndael (aes).

valyala wrote at 2008-07-14 19:17:

Give a try to CyaSSL http://www.yassl.com/cyassl-0.9.8.zip . It has much clearer design than OpenSSL and has very small footprint. "The complete SSLv3/TLSv1.1 client/server footprint is under 60K, and smaller versions can be built." - the http://yassl.com site claims ;)

Zbr wrote at 2008-07-15 10:44:

I've checked it, and there is no yassl package in debian. Also its set of supported ciphers is rather miserable, and since kernel does not have asymmetric ciphers it can not perform full SSL encryption, and thus particular this ability in not needed, but lower crypto layer only.

Please solve this captcha to be allowed to post (need to reload in a minute): 35 + 89

Name:
URL (optional):
Captcha:
Comments: