[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-6978":3},{"id":4,"name":5,"fullName":6,"owner":5,"repo":5,"description":7,"homepage":8,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":15,"stars30d":15,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":20,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":15,"starSnapshotCount":15,"syncStatus":25,"lastSyncTime":26,"discoverSource":27},6978,"RNCryptor","RNCryptor\u002FRNCryptor","CCCryptor (AES encryption) wrappers for iOS and Mac in Swift. -- For ObjC, see RNCryptor\u002FRNCryptor-objc","https:\u002F\u002Fgroups.google.com\u002Fforum\u002F#!forum\u002Frncryptor",null,"Swift",3359,516,114,7,0,30.14,"MIT License",false,"master",true,[],"2026-06-12 02:01:32","# RNCryptor\n\n[![BuddyBuild](https:\u002F\u002Fdashboard.buddybuild.com\u002Fapi\u002FstatusImage?appID=57ea731dbd45750100873fb1&branch=master&build=latest)](https:\u002F\u002Fdashboard.buddybuild.com\u002Fapps\u002F57ea731dbd45750100873fb1\u002Fbuild\u002Flatest)\n\nCross-language AES Encryptor\u002FDecryptor [data format](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-Spec\u002Fblob\u002Fmaster\u002FRNCryptor-Spec-v3.md).\n\nThe primary targets are Swift and Objective-C, but implementations are available in [C](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-C), [C++](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-cpp), [C#](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-cs), [Erlang](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-erlang), [Go](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-go), [Haskell](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002Frncryptor-hs), [Java](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FJNCryptor),\n[PHP](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-php), [Python](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-python),\n[Javascript](https:\u002F\u002Fgithub.com\u002Fchesstrian\u002FJSCryptor), [Ruby](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002Fruby_rncryptor), and [Dart](https:\u002F\u002Fgithub.com\u002Ftzraikov\u002Fflutter_rncryptor).\n\nThe data format includes all the metadata required to securely implement AES encryption, as described in [\"Properly encrypting with AES with CommonCrypto,\"](http:\u002F\u002Frobnapier.net\u002Faes-commoncrypto) and [*iOS 6 Programming Pushing the Limits*](http:\u002F\u002Fiosptl.com), Chapter 15. Specifically, it includes:\n\n* AES-256 encryption\n* CBC mode\n* Password stretching with PBKDF2\n* Password salting\n* Random IV\n* Encrypt-then-hash HMAC\n\n## Contents\n\n* [Format Versus Implementation](#format-versus-implementation)\n* [Basic Password Usage](#basic-password-usage)\n* [Incremental Usage](#incremental-usage)\n* [Installation](#installation)\n* [Advanced Usage](#advanced-usage)\n* [FAQ](#faq)\n* [Design Considerations](#design-considerations)\n* [License](#license)\n\n## Format Versus Implementation\n\nThe RNCryptor data format is cross-platform and there are many implementations. The framework named \"RNCryptor\" is a specific implementation for Swift and Objective-C. Both have version numbers. The current data format is v3. The current framework implementation (which reads the v3 format) is v4.\n\n## Basic Password Usage\n\n```swift\n\u002F\u002F Encryption\nlet data: NSData = ...\nlet password = \"Secret password\"\nlet ciphertext = RNCryptor.encrypt(data: data, withPassword: password)\n\n\u002F\u002F Decryption\ndo {\n    let originalData = try RNCryptor.decrypt(data: ciphertext, withPassword: password)\n    \u002F\u002F ...\n} catch {\n    print(error)\n}\n```\n\n## Incremental Usage\n\nRNCryptor supports incremental use, for example when using with `NSURLSession`. This is also useful for cases where the encrypted or decrypted data will not comfortably fit in memory.\n\nTo operate in incremental mode, you create an `Encryptor` or `Decryptor`, call `updateWithData()` repeatedly, gathering its results, and then call `finalData()` and gather its result.\n\n```swift\n\u002F\u002F\n\u002F\u002F Encryption\n\u002F\u002F\nlet password = \"Secret password\"\nlet encryptor = RNCryptor.Encryptor(password: password)\nlet ciphertext = NSMutableData()\n\n\u002F\u002F ... Each time data comes in, update the encryptor and accumulate some ciphertext ...\nciphertext.appendData(encryptor.updateWithData(data))\n\n\u002F\u002F ... When data is done, finish up ...\nciphertext.appendData(encryptor.finalData())\n\n\u002F\u002F\n\u002F\u002F Decryption\n\u002F\u002F\nlet password = \"Secret password\"\nlet decryptor = RNCryptor.Decryptor(password: password)\nlet plaintext = NSMutableData()\n\n\u002F\u002F ... Each time data comes in, update the decryptor and accumulate some plaintext ...\ntry plaintext.appendData(decryptor.updateWithData(data))\n\n\u002F\u002F ... When data is done, finish up ...\ntry plaintext.appendData(decryptor.finalData())\n```\n\n### Importing into Swift\n\nMost RNCryptor symbols are nested inside an `RNCryptor` namespace.\n\n## Installation\n\n### Requirements\n\nRNCryptor 5 is written in Swift 3 and does not bridge to Objective-C (it includes features that are not available). If you want an ObjC implementation, see [RNCryptor-objc](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-objc). That version can be accessed from Swift, or both versions can coexist in the same project.\n\n### The Bridging Header\n\nCommonCrypto is not a modular header (and Apple has suggested it may never be). This makes it very challenging to import into Swift. To work around this, the necessary header files have been copied into `RNCryptor.h`, which needs to be bridged into Swift. You can do this either by using RNCryptor as a framework, adding `#import \"RNCryptor\u002FRNCryptor.h\"` to your existing bridging header, or making `RNCryptor\u002FRNCryptor.h` your bridging header in Build Settings, \"Objective-C Bridging Header.\"\n\n### Installing Manually\n\nThe easiest way to use RNCryptor is by making it part of your project, without a framework. RNCryptor is just one swift file and one bridging header, and you can skip all the complexity of managing frameworks this way. It also makes version control very simple if you use submodules, or checkin specific versions of RNCryptor to your repository.\n\nThis process works for most targets: iOS and OS X GUI apps, Swift frameworks, and OS X commandline apps. **It is not safe for ObjC frameworks or frameworks that may be imported into ObjC, since it would cause duplicate symbols if some other framework includes RNCryptor.**\n\n* Drag and link `RNCryptor\u002FRNCryptor.swift` and `RNCryptor.h` into your project\n* If you already have a bridging header file, add `#import \"RNCryptor.h\"` (or the path to which you copied `RNCryptor.h`).\n* If you don't have a bridging header:\n  * Swift project: In your target's Build Settings, set \"Objective-C Bridging Header\" to your path for `RNCryptor.h`. (Or create a bridiging header and follow instructions above.)\n  * ObjC project: Xcode will ask if you want to create a bridging header. Allow it to, and add `#import \"RNCryptor.h\"` to the header (or the path to which you copied `RNCryptor.h`)\n* To access RNCryptor from Swift, you don't need to import anything. It's just part of your module.\n* To access RNCryptor from ObjC, import your Swift header (*modulename*-Swift.h). For example: `#import \"MyApp-Swift.h\"`.\n\nBuilt this way, you don't need to (and can't) `import RNCryptor` into your code. RNCryptor will be part of your module.\n\n### [Carthage](https:\u002F\u002Fgithub.com\u002FCarthage\u002FCarthage)\n\n    github \"RNCryptor\u002FRNCryptor\" ~> 5.0\n\nThis approach will not work for OS X commandline apps. Don't forget to embed `RNCryptor.framework`. \n\nBuilt this way, you should add `@import RNCryptor;` to your ObjC or `import RNCryptor` to your Swift code.\n\nThis approach will not work for OS X commandline apps.\n\n### [CocoaPods](https:\u002F\u002Fcocoapods.org)\n\n    pod 'RNCryptor', '~> 5.0'\n\nThis approach will not work for OS X commandline apps.\n\nBuilt this way, you should add `import RNCryptor` to your Swift code.\n\n### [Swift Package Manager](https:\u002F\u002Fswift.org\u002Fpackage-manager)\n\n    dependencies: [\n        .package(url: \"https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor.git\", .upToNextMajor(from: \"5.0.0\"))\n    ]\n\nSwift Package Manager support requires Xcode 12.5 or higher.\n\nBuilt this way, you should add `import RNCryptor` to your Swift code.\n\n## Advanced Usage\n\n### Version-Specific Cryptors\n\nThe default `RNCryptor.Encryptor` is the \"current\" version of the data format (currently v3). If you're interoperating with other implementations, you may need to choose a specific format for compatibility.\n\nTo create a version-locked cryptor, use `RNCryptor.EncryptorV3` and `RNCryptor.DecryptorV3`.\n\nRemember: the version specified here is the *format* version, not the implementation version. The v4 RNCryptor framework reads and writes the v3 RNCryptor data format.\n\n### Key-Based Encryption\n\n*You need a little expertise to use key-based encryption correctly, and it is very easy to make insecure systems that look secure. The most important rule is that keys must be random across all their bytes. If you're not comfortable with basic cryptographic concepts like AES-CBC, IV, and HMAC, you probably should avoid using key-based encryption.*\n\nCryptography works with keys, which are random byte sequences of a specific length. The RNCryptor v3 format uses two 256-bit (32-byte) keys to perform encryption and authentication.\n\nPasswords are not \"random byte sequences of a specific length.\" They're not random at all, and they can be a wide variety of lengths, very seldom exactly 32. RNCryptor defines a specific and secure way to convert passwords into keys, and that is one of it's primary features.\n\nOccasionally there are reasons to work directly with random keys. Converting a password into a key is intentionally slow (tens of milliseconds). Password-encrypted messages are also a 16 bytes longer than key-encrypted messages. If your system encrypts and decrypts many short messages, this can be a significant performance impact, particularly on a server.\n\nRNCryptor supports direct key-based encryption and decryption. The size and number of keys may change between format versions, so key-based cryptors are [version-specific](#version-specific-cryptors).\n\nIn order to be secure, the keys must be a random sequence of bytes. See [Converting a Password to a Key](#converting-a-password-to-a-key) for how to create random sequences of bytes if you only have a password.\n\n```swift\nlet encryptor = RNCryptor.EncryptorV3(encryptionKey: encryptKey, hmacKey: hmacKey)\nlet decryptor = RNCryptor.DecryptorV3(encryptionKey: encryptKey, hmacKey: hmacKey)\n```\n\n## FAQ\n\n### How do I detect an incorrect password?\n\nIf you decrypt with the wrong password, you will receive an `HMACMismatch` error. This is the same error you will receive if your ciphertext is corrupted.\n\nThe v3 data format has no way to detect incorrect passwords directly. It just decrypts gibberish, and then uses the HMAC (a kind of encrypted hash) to determine that the result is corrupt. You won't discover this until the entire message has been decrypted (during the call to `finalData()`).\n\nThis can be inconvenient for the user if they have entered the wrong password to decrypt a very large file. If you have this situation, the recommendation is to encrypt some small, known piece of data with the same password. Test the password on the small ciphertext before decrypting the larger one.\n\nThe [v4 data format](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-Spec\u002Fblob\u002Fmaster\u002Fdraft-RNCryptor-Spec-v4.0.md) will provide a faster and more useful mechanism for validating the password or key.\n\n### What is an \"HMAC Error?\" (Error code 1)\n\nSee previous question. Either your data is corrupted or you have the wrong password.\n\nThe most common cause of this error (if your password is correct) is that you have misunderstood how [Base64 encoding](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FBase64) works while transferring data to or from the server. If you have a string like \"YXR0YWNrIGF0IGRhd24=\", this is not \"data.\" This is a string. It is probably Base64 encoded, which is a mechanism for converting data into strings. Some languages (JavaScript, PHP) have a habit of implicitly converting between data into Base64 strings, which is confusing and error-prone (and the source of many of these issues). Simple rule: if you can print it out without your terminal going crazy, it's not encrypted data.\n\nIf you convert a Base64-encoded string to data using `dataUsingEncoding()`, you will get gibberish as far as RNCryptor is concerned. You need to use `init?(base64EncodedData:options:)`. Depending on the options on the iOS side or the server side, spaces and newlines may matter. You need to verify that precisely the bytes that came out of the encryptor are the bytes that go into the decryptor.\n\n### Can I use RNCryptor to read and write my non-RNCryptor data format?\n\nNo. RNCryptor implements a specific data format. It is not a general-purpose encryption library. If you have created your own data format, you will need to write specific code to deal with whatever you created. Please make sure the data format you've invented is secure. (This is much harder than it sounds.)\n\nIf you're using the OpenSSL encryption format, see [RNOpenSSLCryptor](https:\u002F\u002Fgithub.com\u002Frnapier\u002FRNOpenSSLCryptor).\n\n### Can I change the parameters used (algorithm, iterations, etc)?\n\nNo. See previous question. The [v4 format](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor-Spec\u002Fblob\u002Fmaster\u002Fdraft-RNCryptor-Spec-v4.0.md) will permit some control over PBKDF2 iterations, but the only thing configurable in the v3 format is whether a password or key is used. This keeps RNCryptor implementations dramatically simpler and interoperable.\n\n### How do I manually set the IV?\n\nYou don't. See the last two questions.\n\nAlso note that if you ever reuse a key+IV combination, you risk attackers decrypting the beginning of your message. A static IV makes a key+IV reuse much more likely (guarenteed if you also have a static key). Wikipedia has a [quick overview of this problem](https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FBlock_cipher_mode_of_operation#Initialization_vector_.28IV.29).\n\n### How do I encrypt\u002Fdecrypt a string?\n\nAES encrypts bytes. It does not encrypt characters, letters, words, pictures, videos, cats, or ennui. It encrypts bytes. You need to convert other things (such as strings) to and from bytes in a consistent way. There are several ways to do that. Some of the most popular are UTF-8 encoding, Base-64 encoding, and Hex encoding. There are many other options. There is no good way for RNCryptor to guess which encoding you want, so it doesn't try. It accepts and returns bytes in the form of `NSData`.\n\nTo convert strings to data as UTF-8, use `dataUsingEncoding()` and `init(data:encoding:)`. To convert strings to data as Base-64, use `init(base64EncodedString:options:)` and `base64EncodedStringWithOptions()`.\n\n### Does RNCryptor support random access decryption?\n\nThe usual use case for this is encrypting media files like video. RNCryptor uses CBC encryption, which prevents easy random-access. While other modes are better for random-access (CTR for instance), they are more complicated to implement correctly and CommonCrypto doesn't support using them for random access anyway.\n\nIt would be fairly easy to build a wrapper around RNCryptor that allowed random-access to blocks of some fixed size (say 64k), and that might work well for video with modest overhead (see [inferno](http:\u002F\u002Fsecuritydriven.net\u002Finferno\u002F) for a similar idea in C#). Such a format would be fairly easy to port to other platforms that already support RNCryptor.\n\nIf there is interest, I may eventually build this as a separate framework.\n\nSee also [Issue #161](https:\u002F\u002Fgithub.com\u002FRNCryptor\u002FRNCryptor\u002Fissues\u002F161) for a much longer discussion of this topic.\n\n## Design Considerations\n\n`RNCryptor` has several design goals, in order of importance:\n\n### Easy to use correctly for most common use cases\n\nThe most critical concern is that it be easy for non-experts to use `RNCryptor` correctly. A framework that is more secure, but requires a steep learning curve on the developer will either be not used, or used incorrectly. Whenever possible, a single line of code should \"do the right thing\" for the most common cases.\n\nThis also requires that it fail correctly and provide good errors.\n\n### Reliance on CommonCryptor functionality\n\n`RNCryptor` has very little \"security\" code. It relies as much as possible on the OS-provided CommonCryptor. If a feature does not exist in CommonCryptor, then it generally will not be provided in `RNCryptor`.\n\n### Best practice security\n\nWherever possible within the above constraints, the best available algorithms\nare applied. This means AES-256, HMAC+SHA256, and PBKDF2. (Note that several of these decisions were reasonable for v3, but may change for v4.)\n\n* AES-256. While Bruce Schneier has made some interesting recommendations\nregarding moving to AES-128 due to certain attacks on AES-256, my current\nthinking is in line with [Colin\nPercival](http:\u002F\u002Fwww.daemonology.net\u002Fblog\u002F2009-07-31-thoughts-on-AES.html).\nPBKDF2 output is effectively random, which should negate related-keys attacks\nagainst the kinds of use cases we're interested in.\n\n* AES-CBC mode. This was a somewhat complex decision, but the ubiquity of CBC\noutweighs other considerations here. There are no major problems with CBC mode,\nand nonce-based modes like CTR have other trade-offs. See [\"Mode changes for\nRNCryptor\"](http:\u002F\u002Frobnapier.net\u002Fmode-rncryptor) for more details on this\ndecision.\n\n* Encrypt-then-MAC. If there were a good authenticated AES mode on iOS (GCM for\ninstance), I would probably use that for its simplicity. Colin Percival makes\n[good arguments for hand-coding an encrypt-then-MAC](http:\u002F\u002Fwww.daemonology.net\u002Fblog\u002F2009-06-24-encrypt-then-mac.html) rather\nthan using an authenticated AES mode, but in RNCryptor mananging the HMAC\nactually adds quite a bit of complexity. I'd rather the complexity at a more\nbroadly peer-reviewed layer like CommonCryptor than at the RNCryptor layer. But\nthis isn't an option, so I fall back to my own Encrypt-than-MAC.\n\n* HMAC+SHA256. No surprises here.\n\n* PBKDF2. While bcrypt and scrypt may be more secure than PBKDF2, CommonCryptor\nonly supports PBKDF2. [NIST also continues to recommend\nPBKDF2](http:\u002F\u002Fsecurity.stackexchange.com\u002Fquestions\u002F4781\u002Fdo-any-security-experts-recommend-bcrypt-for-password-storage). We use 10k rounds of PBKDF2\nwhich represents about 80ms on an iPhone 4.\n\n### Code simplicity\n\nRNCryptor endeavors to be implemented as simply as possible, avoiding tricky code. It is designed to be easy to read and code review.\n\n### Performance\n\nPerformance is a goal, but not the most important goal. The code must be secure\nand easy to use. Within that, it is as fast and memory-efficient as possible.\n\n### Portability\n\nWithout sacrificing other goals, it is preferable to read the output format of\n`RNCryptor` on other platforms.\n\n## License\n\nExcept where otherwise indicated in the source code, this code is licensed under\nthe MIT License:\n\n>Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the \"Software\"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and\u002For sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:\n\n>The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.\n\n>THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ```\n","RNCryptor 是一个为 iOS 和 Mac 平台提供的 AES 加密\u002F解密库，使用 Swift 语言编写。它实现了 AES-256 加密、CBC 模式、PBKDF2 密码拉伸、密码加盐、随机 IV 以及 Encrypt-then-hash HMAC 等安全特性，确保了数据的安全性。此外，RNCryptor 还支持跨平台的数据格式，允许在不同语言环境中进行加密和解密操作。该项目适用于需要在移动或桌面应用中实现安全数据存储与传输的场景，特别适合对安全性有较高要求的应用开发。",2,"2026-06-11 03:09:59","top_language"]