Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encrypting with no padding inflates cipher text #29

Closed
paulw11 opened this issue Aug 24, 2016 · 3 comments
Closed

Encrypting with no padding inflates cipher text #29

paulw11 opened this issue Aug 24, 2016 · 3 comments
Assignees
Labels

Comments

@paulw11
Copy link
Contributor

paulw11 commented Aug 24, 2016

See SecKeyEncrypt SecPaddingNone iOS

I am basically doing encryption with two keys. The first step, using key A, uses SecPaddingPKCS1 and gives me an output of 256 bytes. After that, using Key B, I use SecPaddingNone. I assume that my output will remain 256 bytes, but it becomes 512 bytes. I am not sure what I am doing wrong, does anyone know? Am I thinking about this wrong?

@paulw11 paulw11 added the bug label Aug 24, 2016
@paulw11 paulw11 self-assigned this Aug 24, 2016
@paulw11
Copy link
Contributor Author

paulw11 commented Aug 24, 2016

RSA returns blocksize (in this case 128) bytes after encryption. If you encrypt more than blocksize bytes then the data is split into multiple chunks, each of which is encrypted, so you will get a multiple of blocksize bytes back.

When PKCS1 padding is used the effective blocksize is reduced by 11 bytes, which means that encrypting 128 bytes will return two blocks or 256 bytes (since 128 is > 128-11 or 117).

When no padding is used, the blocksize doesn't need to be reduced by 11, but SwiftyRSA still does this. I have tested without the 11 byte reduction using no padding and the second encryption, without padding, returns 128 bytes as expected. The regression tests still pass and I have confirmed that openssl can correctly decrypt the double encrypted data (first with padding and then encrypted a second time with no padding).

paulw11 added a commit that referenced this issue Aug 24, 2016
ldiqual added a commit that referenced this issue Sep 15, 2016
* Make SwiftyRSA compile with Swift 3.0

* Fixed all errors + warnings

* Fix spelling

* Added support to read multiple public keys from a PEM file (#22)

For a usecase where we may have multiple public keys that our content might have been signed with, we wanted to put multiple public keys into a single file, much like you may have multiple SSL certs in a chain file.

This method parses out any data between `-----BEGIN PUBLIC KEY-----`  and `-----END PUBLIC KEY-----`, and then uses `publicKeyFromPEMString` to try to parse it.

Tests added for a really insane usecases, an empty string, and reading one of the test private keys for fun. All added code has 100% coverage, and the new method is commented.

* Added targets for watchOS and tvOS (#23)

- Added additional targets for watchOS and tvOS platforms
- Tests pass on tvOS
- Changed the master `SwiftyRSA.h` file to pull in Foundation and not UIKit/Cocoa since those frameworks aren't needed
- The current CI pipeline doesn't assume multiple targets/schemes, so I refactored `.travis.yml` to allow for AppleTV, iOS, and watchOS targets, and based on how Alamofire does theirs for multiple platform support
- Updated `podspec` to show multiple platform support
    - Also raised iOS version to 8.3 since Travis platform doesn't seem to have support for iOS 8.0-8.2

* Updated changelog

* Bump to 0.4.0

* Update to Xcode 8.0 beta 4

* Migrate to Xcode 8 beta 6

* Don't reduce maximum block size when padding is `none`
Closes #29

* Update CHANGELOG.md

#29

* Fix OSStatus -34018 on iOS 10

* Update travis to support xcode 8
@anirudhamahale
Copy link

anirudhamahale commented Dec 1, 2017

Try this
let encrypted = try content.encrypted(with: publicKey, padding: [])

@jeffery812
Copy link

jeffery812 commented Apr 6, 2018

does padding: [] mean no padding?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants