PKCS#7 encryption versus W3C standard?

[danielweck]

Thanks for @drminside for reporting this! CC @Mantano @mmenu-mantano @edrlab @clebeaupin @TEA-ebook @RemiBauzac

Verbatim quote from Taehyun Kim:
(Note: as the readium/readium-lcp-server repository is currently private, I am not hiding the content server URLs, so the links are quoted below in plain text)

---

Encrypted EPUB and license was downloaded from http://www.neovento.net:8989/manage/

Here are test results which are different from our understanding on the W3C encryption standard.

1. PKCS#7 padding algorithm is used, which is default provided by OpenSSL.

But W3C Encryption standard requires other method, which is filled with any bytes until the last byte-1 at the last block, and the padding size should be specified by the last byte. (Please 5.2 Block Encryption Algorithm/padding part).

PKCS#7 is more delicate padding method than W3C Encryption standard. So decryption algorithm having PKCS#7 may occur error during encrypted data with W3C method, but not vice versa.

2. Encryption/content_key/encrypted_value in the license has padding. It is normal when original size is random and not multiple of data block size. But when the size of original data is always well known as multiple of block size, it doesn’t need padding. (Please 5.2 Block Encryption Algorithm/padding part)

3. And we need to share the root certificate for the interoperability of signature validation.

Except these mismatches, I have succeeded to decrypt resources with the content_key in the license.

And if you want to test with encrypted EPUBs from DRM inside, you may download from
http://www.drminside.com/LCP/
=>Download=>Test Material
All passphrase is ‘lcptest’

I am not asserting our understanding is correct or true. But I am worrying any other implementer of the LCP may interpret other way in this parts.

---

Note that Mantano's test file in GitHub ( https://github.com/Mantano/mantano-lcp-client/tree/develop/test/lcp-client-lib/data ) may need replacing with updated versions from http://www.neovento.net:8989/manage/ (just to make sure the provider certificate etc. is up to date)

Also note that DRM-Inside have test files in GitHub (private repository): https://github.com/drminside/readium-drm/tree/master/LCP/TestData

[mickael-menu-mantano]

Here are answers from Artem to Taehyun. You should be able to talk to him directly once he will have access to this repo.

---

1. PKCS#7 padding algorithm is used, which is default provided by OpenSSL.
   But W3C Encryption standard requires other method, which is filled with any bytes until the last byte-1 at the last block, and the padding size should be specified by the last byte. (Please 5.2 Block Encryption Algorithm/padding part).
   PKCS#7 is more delicate padding method than W3C Encryption standard. So decryption algorithm having PKCS#7 may occur error during encrypted data with W3C method, but not vice versa.

Yes you are right, W3C Encryption standard describes more general padding mechanism, in fact the PKCS#7 is a special case of the described one. The PKCS#7 is de facto standard for block ciphers padding, so it will be enough in most cases, but I agree, we can implement padding scheme from W3C document to avoid problems in the future.

Most crypto libraries do not support this padding scheme, but we can implement it by our own. In fact it looks like ISO 10126 padding standard which was withdrawn in 2007.

1. Encryption/content_key/encrypted_value in the license has padding. It is normal when original size is random and not multiple of data block size. But when the size of original data is always well known as multiple of block size, it doesn’t need padding. (Please 5.2 Block Encryption Algorithm/padding part)
   

Yes, we know original size of some fields, but usually if cipher text size is a multiple of block size we add one dummy block, in another case decryptor will read the last byte and use it as padded bytes count. It will remove last byte-1 bytes. Decryptor doesn't have possibility to find out that encrypted data does not have padding, except CBC-CTS mode. Correct me if I'm wrong.
If we would be the one who generates license, we could generate those fields without padding and read them accordingly.

[thkim2015]

Most crypto libraries do not support this padding scheme, but we can implement it by our own. In fact it looks like ISO 10126 padding standard which was withdrawn in 2007.

Yes, W3C document explains ISO 10126, but it does not use the term ISO any longer.
If you would do, you may keep the sever side because an encrypted resource padded with PKCS#7 can be decerypted by decyprtor with W3C standard method.
But it is necessary to update the client side.

Yes, we know original size of some fields, but usually if cipher text size is a multiple of block size we add one dummy block, in another case decryptor will read the last byte and use it as padded bytes count. It will remove last byte-1 bytes. Decryptor doesn't have possibility to find out that encrypted data does not have padding, except CBC-CTS mode. Correct me if I'm wrong.

If we already know the data is multiple of block size, it can be decrypted by decryptor with ‘nopad’ option, even though it has no extra padding. In this case, decryptor regards the number of padding is 0 without any padding data. And we have to remind that if the encryption algorithm is block cipher, ‘Encryption/content_key/encrypted_value’ of the LCP license is used only for encrypted key value whose size is always multiple of block size.

[jpbougie]

My own answers, taken from our Slack channel:
About 1: Yes it is an issue for decryption, where it should be well-specified. In the encryption, PKCS#7 is, as you pointed out, a valid form of the W3C padding algorithm, with the arbitrary bytes in the W3C algorithm being set to the length of the padding. I would thus suggest keeping it like that, to help interoperability.

About 2: I do not have the same interpretation of the relevant sentence:

Since the data being encrypted is an arbitrary number of octets, it may not be a multiple of the block size. This is solved by padding the plain text up to the block size before encryption and unpadding after decryption.

The language here is unclear about a content whose (fixed) size is already a multiple of the block size, as it just assumes the content is arbitrary. But, given that our profiles do not require the EPUB resources and the content key in the license document to be encrypted with the same algorithm (and thus are not required to have matching block lengths), it might be safer to require padding there as well.

[thkim2015]

@jpbougie

About 1: Yes it is an issue for decryption, where it should be well-specified. In the encryption, PKCS#7 is, as you pointed out, a valid form of the W3C padding algorithm, with the arbitrary bytes in the W3C algorithm being set to the length of the padding. I would thus suggest keeping it like that, to help interoperability.

You're right that PKCS#7 is a subset of the W3C padding algorithm. So you may keep it as it is in the server side. But in the client, if you uses PKCS#7 for the padding, the encrypted resource used W3C padding algorithm would not work. It needs to make clear in the specification, I think.

About 2: I do not have the same interpretation of the relevant sentence:
The language here is unclear about a content whose (fixed) size is already a multiple of the block size, as it just assumes the content is arbitrary. But, given that our profiles do not require the EPUB resources and the content key in the license document to be encrypted with the same algorithm (and thus are not required to have matching block lengths), it might be safer to require padding there as well.

The ways of decryption based on the specific encryption algorithm always depends on the algorithm itself. If one LCP profile uses stream cipher instead of block cipher, it doesn't need any kind of padding. If it uses even asymmetric one with OAEP, only decrypter should do process according to the OAEP algorithm. So it is matter of profile specification, not general LCP specification. Therefore if a profile of the LCP decides to use any block cipher algorithm specified in the 5.2 Block Encryption Algorithms of W3C document, we need to define clearly whether it is with or without padding at the Encryption/content_key/encrypted_value part. As you know the key size of the block cipher is always multiple of the block size. There will be no harm or any malfunction when the any block cipher key is encrypted and decrypted without padding.

[0xartem]

If we already know the data is multiple of block size, it can be decrypted by decryptor with ‘nopad’ option, even though it has no extra padding. In this case, decryptor regards the number of padding is 0 without any padding data. And we have to remind that if the encryption algorithm is block cipher, ‘Encryption/content_key/encrypted_value’ of the LCP license is used only for encrypted key value whose size is always multiple of block size.

We can decrypt data with no padding option if it is multiple of block size, that's true. But usually padding is added in that case too, if there is no any specific requirements. This is standard behavior. And as you mentioned before, we have to remind that we use block cipher and we decrypt specific value ‘Encryption/content_key/encrypted_value’. I think that 16 bytes (which is padding in this case) only for one specific field is not the reason to complicate encryption/decryption process and to create additional profile specifications. I guess it may mislead developers and cause errors.
Sure, we can use encryption without padding for ‘Encryption/content_key/encrypted_value’, but should we?

[0xartem]

Yes, W3C document explains ISO 10126, but it does not use the term ISO any longer.
If you would do, you may keep the sever side because an encrypted resource padded with PKCS#7 can be decerypted by decyprtor with W3C standard method.
But it is necessary to update the client side.

Yes, as I mentioned before, I agree that we need to implement this padding scheme.

[thkim2015]

According to the W3C document,

Padding : Since the data being encrypted is an arbitrary number of octets, it may not be a multiple of the block size. This is solved by padding the plain text up to the block size before encryption and unpadding after decryption.

I don't think we should interpret this sentence that the padding is always default.
Someone may think without-padding is default and more efficient when we know that all resource is certainly a multiple of the block size.

This is a matter of interpretation way of implementer, not standard default, which may lead not interoperable in the end.
So I think we need to specify somewhere document no matter what it is.

[0xartem]

I mean that most implementations of padding scheme for block ciphers has the same behavior for all data whether it's multiple of the block size or not. For example like PKCS7, ANSI X.923 etc. We do not have standard in our case, but I believe that it's better to use the same padding scheme all over the project, no matter what kind of field we are trying to decrypt.
If you think we should create a document to specify details - I am okay with that.

[thkim2015]

Now, I think we've got a consensus to have to use always the ANSI X.923 padding scheme to encrypting resource, no matter what the size of it. And these should be specified in a document as a normative information. Am I correct?

[0xartem]

I wrote about the ANSI X.923 as an example. This standard does not fit to the W3C document as far as I can see. And if we use it we get the same problem we had with the PKCS7. As you wrote before using PKCS7 or (ANSI X.923) may lead to errors during decryption. So I guess we can specify in a document that padding scheme from W3C method should be used, but clarify that padding must always be added.

Actually I guess we can interpret that padding should be added even if data to encrypt is multiple of the block size. It's not very clear though:

The padding algorithm is to calculate the smallest non-zero number of octets, say N, that must be suffixed to the plain text to bring it up to a multiple of the block size. We will assume the block size is B octets so N is in the range of 1 to B.

We can see that N can be equal to B which equals to the block size here.

For example, assume an 8 byte block size and plain text of 0x616263. The padded plain text would then be 0x616263????????05 where the "??" bytes can be any value. Similarly, plain text of 0x2122232425262728 would be padded to 0x2122232425262728??????????????08.

In the last example padding is equal to the block size.

[thkim2015]

Yes. You're right. ANSI X.923 is just another subset of the W3C method. Because it should put zeros , not random digit before last one. I misunderstood. So we have to use the term W3C padding method.

However even though the explanation of the text contains N is B case, it just explains one special case out of all cases which can come out when source size is arbitrary. But padding may not still necessary when we know the size is not arbitrary and fixed to multiple to the block size.

[0xartem]

Anyway, we need to make a decision about scheme we will use. As I mentioned before I think that padding scheme should be all-sufficient, which means that we do not need to know what kind of data we are trying to encrypt or decrypt. This means for me that we have unambiguous formula and to apply this formula we do not need to refer to LCP specific information.

If we look at the existing padding standards, like PKCS7 http://tools.ietf.org/html/rfc5652#section-6.3, it has statements like:

...Some content-encryption algorithms assume the input length is a
multiple of k octets, where k is greater than one. For such
algorithms, the input shall be padded at the trailing end with
k-(lth mod k) octets all having value k-(lth mod k), where lth is
the length of the input...
...The padding can be removed unambiguously since all input is padded,
including input values that are already a multiple of the block size...

Here we have k-(lth mod k) formula which describes padding without any additional references. I think it's a right way to formulate padding schemes. This is a standardized document which is used in cryptography widely. Eventually, the only difference between PKCS7 and our padding scheme is that we pad with random data while PKCS7 pads with exact digit.

So I think we can specify our padding bytes count with the same formula.

[thkim2015]

I am writing a specification for LCP profile which includes additional encryption algorithms (GCM), padding method and unique secret key for the User Key.

What do you think about following description for the padding method?

Padding Method

All plain text to be encrypted with AES-CBC encryption (including Content Key) shall be padded before encryption. The padding algorithm is to calculate the smallest non-zero number of octets, say N, that must be suffixed to the plain text to bring it up to a multiple of the block size. The block size in this profile is always 16 octets so N is in the range of 1 to 16. Pad by suffixing the plain text with N-1 arbitrary pad bytes and a final byte whose value is N. On decryption, just take the last byte and, after sanity checking it, strip that many bytes from the end of the decrypted cipher text.

For example, assume a plain text of 0x616263. The padded plain text would then be 0x616263????????????????????????0D where the "??" bytes can be any value. Similarly, plain text of 0x2122232425262728292A2B2C2D2E2F20 would be padded to 0x??????????????????????????????10 so that the whole result would be 0x2122232425262728292A2B2C2D2E2F20??????????????????????????????10.

[danielweck]

@thkim2015 the term "shall" seems inappropriate. Is MUST a better conformance requirement, or is the intent to indeed express optionality? (MAY)

[danielweck]

@thkim2015 have you reached a conclusion about CBC (with padding rule) vs. GCM? Any performance gain? Or any particular technical rationale for choosing one or the other for LCP?

[thkim2015]

@danielweck padding is necessary for the CBC mode, could not not be optional.
I couldn't see any comments on this issue.

GCM could be a better choice in terms of padding because it does not need padding.
But in performance point of view, CBC is better than GCM in the client side.

[danielweck]

@thkim2015 oh sure, I understand that CBC requires padding. I was wondering about choosing between CBC and GCM in the LCP server and client implementations. Right now, I believe it is CBC, which offers better decryption performance. So it looks like we should stick to this current encryption profile, right?

[thkim2015]

@danielweck Recently I found that GCM has become only one encryption algorithm in the basic encryption profile.

[jpbougie]

I put GCM instead of CBC in the basic profile in light of recent attacks on CBC, and the fact that GCM is now the recommended widespread cipher mode. Of course, that change can be reverted given enough objective evidence. Do you have any data on the performance difference between CBC and GCM, and how impactful it is on the whole performance of rendering an EPUB? In the typical text epub, and in one with large media elements? That could help us justify a decision, one way or another.

[danielweck]

I see, thank you guys for the clarifications.
One thing is for sure: we need consistency :) If the profile says "GCM", we need to update both LCP server and client to support GCM by default. I believe the implemented default is currently CBC.

[thkim2015]

@jpbougie What kind of attack for the CBC did you see? Padding oracle attack? If it is, W3C padding method is one of the main reasons to remove the vulnerability of the PKCS#7.

And regarding the rendering performance, theoretically CBC is better than GCM because GCM needs HMAC operation and counter calculation works more.

And we have a test result for the CBC and GCM on the android and iOS phones.

Even though we removed the HMAC verification process in large media resources since it needs whole data reading I/O job (it is almost impossible), some iOS version showed lower performance (almost 30% I remember although I don't know the reason) with GCM than CBC.
In text and android cases, there was no critical differences between CBC and GCM.

I'll upload the detail test results which we have done later.

[llemeurfr]

We should not forget that it is not in the Readium LCP charter to be the ultimate rock-solid DRM technology. It the performance loss is really 30% with CGM in some instances, the choice will be easy.

[0xartem]

I saw your discussion and decided to add my opinion about this question. As @thkim2015 said GCM supports HMAC operation which provides integrity for ciphertext. It's so-called authenticated encryption scheme. But since we use RSA-SHA256 digital signature algorithm, it already provides authenticity of data for us. So I think CBC is a good option to provide confidentiality without performance loss.

Though if performance is very important there is one another option: to use CTR mode. It faster than CBC because it supports parallel processing and it can give great performance growth on modern multi-core processors.

[thkim2015]

Please refer the performance test results on CBC and GCM in the client side.

We have tested with 400MB and 1GB resources.
And HMAC verification time was excluded on the GCM.

device (CBC/GCM sec)
android 0.01449 0.01706
ios_padmini 0.01634 0.02504
ios_ph6s 0.0091 0.01537
ios_vm 0.0004 0.00052
win_x86 0.000325 0.000655

[HadrienGardeur]

But since we use RSA-SHA256 digital signature algorithm, it already provides authenticity of data for us.

@artem-brazhnikov we use RSA-SHA256 to sign the license itself, which means that we only get authenticity for that file. In the case of GCM, it would provide it for all assets in the container, it's really not the same.
GCM also uses CTR but in addition to it, it also provides authentication through HMAC.

@thkim2015 are these decryption time for the whole resource? Seems too fast for the whole resource.

[thkim2015]

@HadrienGardeur It is average time per 1MB

[HadrienGardeur]

@thkim2015 thanks for the additional info.

So even through relatively it can be quite slower, the difference won't be really perceivable, not even for video (1080p video is around 8 Mb/s)

GCM is the de-facto standard these days for SSL, worst case scenario we'll be on par with that.

[thkim2015]

@HadrienGardeur Above result is one after excluding HMAC processing. So it means it is close toward CBC vs. CTR rather that GCM.
If we have to use GCM algorithm for video resource, we have to give up random access feature or turn off the HMAC processing.

And SSL is a protocol which needs message authentication necessarily. So GCM could be a proper algorithm for it. But for the normal resource encryption, CBC is still de-facto standard, not GCM.
GCM is usually used for small series of message where payload size is under 4KB.

Moreover, LCP has RSA-SHA256 signature in the License Document.
So if LCP specification requires GCM algorithm in the User Key section, it would be a kind of double authentication.

[0xartem]

@HadrienGardeur Oh yes, you right, I totally forgot about the files encryption, it was long time ago. Then GCM is the right choice for you I guess.

[HadrienGardeur]

@thkim2015 why would we need to give up random access feature with GCM? It's designed to support it, that's part of the reason it uses GHASH instead of true HMAC.

I've already replied to the same comment from @artem-brazhnikov regarding RSA-SHA256: we use it strictly for the license vs resources for GCM.

The only part where I agree with you is that if we don't need authentication for resources, then CTR is faster.

[llemeurfr]

Hi experts, we must come to a choice and finalize the readium LCP 1.0 Profile, so that we can begin interop tests shortly.
If we follow @jpbougie and @HadrienGardeur advice, the choice is GCM, both for the Basic Profile and the Readium LCP 1.0 Ecosystem Profile.
It means that the Go Server code must be updated, and the client SDK also.
The client SDK (incl. the LCP client module we'll release asap) would then have a compile time directive to verify or not the encrypted content.

[danielweck]

Note that I have "ported" @jpbougie 's PR to the new LSD / LCP server architecture.
See: #35 (comment)

[danielweck]

Hello all!
We need to reach a consensus regarding the padding issue.

Currently, both the LCP Go server and C++ client use PKCS#7 (am I right?)

1. AES-256-CBC is used in the LCP JSON for encrypting the content key, and also for the user key check, and also for the user data fields.

2. AES-256-CBC too is used for encrypting EPUB resources listed in encryption.xml, but note that AES-256-GCM support is underway. The Go server implementation seems complete ( GCM #101 ), but C++ client decryption routines are not working yet ( GCM readium-lcp-client#21 ). So GCM is work in progress, hopefully will be finalized soon ( @artem-brazhnikov could you please share your email address with me, I would like to ask your advice).

Just to clarify: we want to use the exact same padding method in both cases (1) and (2), right?
Another clarification: with GCM, do we also need to make a decision about the padding strategy? Or is that irrelevant?

So, we can either continue to use the current CBC padding method, or update our implementations to support another padding scheme. Either way: we need to update the profile specification to explicitly document the type of padding used, right? Do we also need to refine the algorithm URI (which only generically references CBC), or can a decryptor simply look at the encrypted content to discover the padding method used?

Any other points of discussion?

[llemeurfr]

We'll close this issue with the following choice, which will be written in the Readium LCP Encryption Profile 1.0:
The encryption and decryption padding scheme MUST be PKCS#7.

[danielweck]

I will add comments in Go and CryptoPP code.

[danielweck]

FYI, client-side comment: readium/readium-lcp-client@7b258d5
server-side comment: 5c7cdc9

[thkim2015]

I am sorry for late comment.

I disagree with the conclusion on this matter to be PKCS#7.
It is not the common opinion in the whole discussion flow.
We had reached to the W3C standard.

According to the discussion flow in this issue, if we use the CBC algorithm ID, "http://www.w3.org/2001/04/xmlenc#aes256-cbc", we should follow the W3C guideline like what I described in the above comment on 8 Jul 2016.
Technically, IMO, CBC with PCKS#7 is not "http://www.w3.org/2001/04/xmlenc#aes256-cbc".

And personally, I think W3C padding method is stronger than PKCS#7 against the padding oracle attack which is one of the weakness of CBC algorithm.

Even though the padding scheme is explained in the W3C document well, IMO, the proposed text (on 8 Jul 2016) should be added in the LCP Encryption Profile 1.0 specification for the reminding the importance of the padding scheme again.

Or in the LCP Encryption Profile 1.0, we can use GCM algorithm even for the Content Key in order not to consider the padding matter.

[danielweck]

@thkim2015 thanks for chiming in!

Regarding AES-256-GCM, we have a perfectly fine Go server implementation. But, please see: #109
There are implementation issues in the LCP client lib related to audio/video "streaming", due to using CryptoPP for GCM decryption (which does not support "seeking" out-of-the-box in its pipelining API).

If DRM-Inside successfully implemented non-authenticated GCM decryption of partial cypher buffers / HTTP byte-range responses, could you please share details? Thank you very much.

[danielweck]

@thkim2015 regarding the use of the URI http://www.w3.org/2001/04/xmlenc#aes256-cbc, and the associated assumption that W3C padding scheme is used (not PKCS#7): I see your point.

I am copying the "padding method" explanation you wrote further up in this discussion thread:
#18 (comment)

All plain text to be encrypted with AES-CBC encryption (including Content Key) shall be padded before encryption. The padding algorithm is to calculate the smallest non-zero number of octets, say N, that must be suffixed to the plain text to bring it up to a multiple of the block size. The block size in this profile is always 16 octets so N is in the range of 1 to 16. Pad by suffixing the plain text with N-1 arbitrary pad bytes and a final byte whose value is N. On decryption, just take the last byte and, after sanity checking it, strip that many bytes from the end of the decrypted cipher text.

For example, assume a plain text of 0x616263. The padded plain text would then be 0x616263????????????????????????0D where the "??" bytes can be any value. Similarly, plain text of 0x2122232425262728292A2B2C2D2E2F20 would be padded to 0x??????????????????????????????10 so that the whole result would be 0x2122232425262728292A2B2C2D2E2F20??????????????????????????????10.

Would you be able to create a pull request for the Go server?
related commit:
5c7cdc9

aes_cbc.go:
https://github.com/readium/readium-lcp-server/blob/manage-frontend/crypto/aes_cbc.go#L51

padded_reader:
https://github.com/readium/readium-lcp-server/blob/manage-frontend/crypto/pad.go#L32

On the client side, CryptoPP "natively" handles PKCS (PKCS#7, even though it is internally named as synonymous PKCS#5, see https://github.com/readium/readium-lcp-client/blob/develop/src/third-parties/cryptopp/filters.h#L457 ), and Readium's existing code would need to be updated to handle the W3C padding algorithm (i.e. reading the correct offset inside the padding to determine the length, etc.):
related commit:
readium/readium-lcp-client@7b258d5

AesCbcSymmetricAlgorithm.cpp (function PlainTextSize(), see outSize):
https://github.com/readium/readium-lcp-client/blob/develop/src/lcp-client-lib/AesCbcSymmetricAlgorithm.cpp#L103

(function Decrypt(), see BlockPaddingSchemeDef::BlockPaddingScheme padding = BlockPaddingSchemeDef::NO_PADDING;):
https://github.com/readium/readium-lcp-client/blob/develop/src/lcp-client-lib/AesCbcSymmetricAlgorithm.cpp#L129

So, can anybody create a pull request for this too?

Thanks for your contributions!

[danielweck]

@thkim2015 in DRM-Inside client implementation, you are using <openssl/aes.h>, not Crypto++, right?

[thkim2015]

@danielweck Right! ... DRM inside uses <openssl/aes.h>. However since there is just a little difference between PCKS#7 and W3C standard, we might be able to make a pull-request on the GO server for it.

BTW would you add our company id 'drminside' into the private git 'readium/readium-lcp-server' and 'readium/readium-lcp-client' projects?

[danielweck]

@rkwright can you please add drm-inside?

[rkwright]

I am not sure mailing lists can be added. Will check when I get to NYPL

[danielweck]

organisation:
https://github.com/drminside

[rkwright]

@thkim2015 , @danielweck But that is their repo, not adding them to a team with access to a repo. I just checked and tried to add "drm-inside" , but github refuses, saying "drm-inside is not a github team member". I can add the members of the team, but need to do it person by person with their github username.

[danielweck]

have you tried drminside without the hyphen character?

[thkim2015]

@rkwright @danielweck We added new e-mail address "[email protected]" for "drminside" github account. So could you add our new e-mail address?

[rkwright]

Did you actually create a "drminside" github iser account? That is the key

[thkim2015]

@rkwright We have a valid account "drminside' that you can verify at https://github.com/drminside'

[rkwright]

@thkim2015 that worked and I sent an invite. Let me know if that doesn't work.

[thkim2015]

@rkwright Now, 'drminside' account can access the lcp-server and lcp-client repo. Thanks.

[danielweck]

Thanks to @drminside @thkim2015 for helping with the client-side implementation of W3C padding :)
readium/readium-lcp-client#26
(includes a patch to Crypto++)

[danielweck]

Thanks to @drminside @thkim2015 for also helping with the server-side implementation of W3C padding.
#111