Chris' Blog.

Sometimes you need to compress data between your backend and frontend, and simply using HTTP gzip compression isn't an option for whatever reason. Or maybe you want to compress data for storage locally on your device, and decompress it when loading. Or whatever you reason may be: I hope I can help here.

Apple's been shipping Compression.framework with iOS since iOS9. This has been mostly ignored, because they also ship zlib which most people use instead. But zlib is trickier to use, so most people import some kind of Cocoapod/Carthage framework to wrap it. However, Apple recommends keeping your framework count as low as possible to not impact launch times, which should give you pause every time you consider adding one. Instead, I'd like to show how instead you can easily use Compression.framework with pure Swift.

Swift compression / decompression

import Foundation
import Compression

extension Data {
    func compression(isEncode: Bool, algorithm: compression_algorithm) -> Data? {
        return withUnsafeBytes { (urbp: UnsafeRawBufferPointer) in
            let ubp: UnsafeBufferPointer<UInt8> = urbp.bindMemory(to: UInt8.self)
            let up: UnsafePointer<UInt8> = ubp.baseAddress!
            let destCapacity = 1_000_000 // Note: Increase/decrease as you require.
            let destBuffer = UnsafeMutablePointer<UInt8>.allocate(capacity:
                destCapacity)
            defer { destBuffer.deallocate() }
            let destBytes = isEncode ?
                compression_encode_buffer(destBuffer, destCapacity, up, count, nil,
                    algorithm) :
                compression_decode_buffer(destBuffer, destCapacity, up, count, nil,
                    algorithm)
            guard destBytes != 0 else { return nil } // Error, or not enough size.
            return Data(bytes: destBuffer, count: destBytes)
        }
    }
    var deflated: Data? {
        // ZLIB has no headers, so it is effectively DEFLATE.
        return compression(isEncode: true, algorithm: COMPRESSION_ZLIB)
    }
    var inflated: Data? {
        return compression(isEncode: false, algorithm: COMPRESSION_ZLIB)
    }
}

Note that my wrappers here only support the one-shot [de]compression methods which require you to know upfront a maximum size the destination will be. This might not suit you, if so there are methods for 'stream de/compression' in Compression.framework which you'll have to modify my code to use, however my code should at least serve as a starting point for you.

Algorithm options

• LZ4 - Fast, not as compressed.
• ZLIB aka DEFLATE - Good balance of speed/compression. NOTE!!! This isn't like typical zlib compression, this is a raw DEFLATE stream, keep that in mind when implementing it on your backend!
• LZFSE - Compresses a bit better and a bit faster than ZLIB, but it's Apple-proprietary so might be tricky to find a library for in your backend's language.
• LZMA - Best compression, slowest.

Go compression / decompression

If your backend uses Go (as mine typically do), here's a snippet to [de]compress interoperably with the above Swift code:

import "bytes"
import "compress/flate"

func deflate(source []byte) ([]byte, error) {
    var buffer bytes.Buffer
    w, err := flate.NewWriter(&buffer, 5)
    if err != nil {
        return nil, err
    }
    _, err = w.Write(source)
    w.Close()
    return buffer.Bytes(), err
}

func inflate(source []byte) ([]byte, error) {
    reader := flate.NewReader(bytes.NewBuffer(source))
    var buffer bytes.Buffer
    _, err := io.Copy(&buffer, reader)
    reader.Close()
    return buffer.Bytes(), err
}

Thanks for reading, I hope this helps someone, and have a great week!

MIT license applies. No warranties.

Photo by Clark Young on Unsplash

The iOS keychain is a great place for storing sensitive information that you don't feel safe storing in UserDefaults or in a file on disk. Things like login details, passwords, auth tokens are perfectly suited for storing in the Keychain.

In this article, I'm going to show how to use the Keychain directly from Swift without dropping down to Objective-C or using a cocoapod/carthage library. Keep in mind that Apple recommends having less than 10 framework libraries with your app, or you'll suffer performance issues. With my example, simply create a KeychainWrapper.swift file in your project, paste in my sample code, modify as you see fit, and you're off to the races.

To be honest, iOS devices have a high level of security nowadays (as of writing) and I'm hard-pressed to give great reasons why information in the Keychain is any more secure than a file saved in your app's Library folder. Nevertheless, it seems to be best practice to use the Keychain. Perhaps people who know why the keychain is better can let me know and I'll update this article. Update: I'm told that there are exploits that can dump the filesystem, but not the keychain, but I've also heard that the filesystem has been fully encrypted for years now too, so I'm really on the fence about this one.

Things to know

• The keychain stores data, not strings, so you're responsible for calling myString.data(using: .utf8) and String(data: keychainData, encoding: .utf8) when calling it with string data.
• When an item is added, you have the chance to specify when you want to be able to read the item. If your app ever runs in the background, eg to handle push notifications, you'll need to set kSecAttrAccessibleAfterFirstUnlock.
• In a WWDC video, Apple confirmed once that your app will never be run in the background before the first unlock, so the above option is recommended.
• If you want your item to not sync via iCloud to the user's other devices, you can specify kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly instead.
• I only use the 'kSecClassGenericPassword' class of keychain item for simplicity. This 'class' has, as its primary key, a composite of the two 'service' and 'account' fields. Thus, in my code below, wherever you see 'account' think 'key', because I'm using a constant value for service.
• Other classes have primary keys made up of (multiple) different fields.
• iOS keeps your keychain items even when you delete and reinstall your app, in my testing.

The code

import Foundation
import Security

// You might want to update this to be something descriptive for your app.
private let service: String = "MyService"

enum Keychain {

    /// Does a certain item exist?
    static func exists(account: String) throws -> Bool {
        let status = SecItemCopyMatching([
            kSecClass: kSecClassGenericPassword,
            kSecAttrAccount: account,
            kSecAttrService: service,
            kSecReturnData: false,
            ] as NSDictionary, nil)
        if status == errSecSuccess {
            return true
        } else if status == errSecItemNotFound {
            return false
        } else {
            throw Errors.keychainError
        }
    }

    /// Adds an item to the keychain.
    private static func add(value: Data, account: String) throws {
        let status = SecItemAdd([
            kSecClass: kSecClassGenericPassword,
            kSecAttrAccount: account,
            kSecAttrService: service,
            // Allow background access:
            kSecAttrAccessible: kSecAttrAccessibleAfterFirstUnlock,
            kSecValueData: value,
            ] as NSDictionary, nil)
        guard status == errSecSuccess else { throw Errors.keychainError }
    }

    /// Updates a keychain item.
    private static func update(value: Data, account: String) throws {
        let status = SecItemUpdate([
            kSecClass: kSecClassGenericPassword,
            kSecAttrAccount: account,
            kSecAttrService: service,
            ] as NSDictionary, [
            kSecValueData: value,
            ] as NSDictionary)
        guard status == errSecSuccess else { throw Errors.keychainError }
    }

    /// Stores a keychain item.
    static func set(value: Data, account: String) throws {
        if try exists(account: account) {
            try update(value: value, account: account)
        } else {
            try add(value: value, account: account)
        }
    }

    // If not present, returns nil. Only throws on error.
    static func get(account: String) throws -> Data? {
        var result: AnyObject?
        let status = SecItemCopyMatching([
            kSecClass: kSecClassGenericPassword,
            kSecAttrAccount: account,
            kSecAttrService: service,
            kSecReturnData: true,
            ] as NSDictionary, &result)
        if status == errSecSuccess {
            return result as? Data
        } else if status == errSecItemNotFound {
            return nil
        } else {
            throw Errors.keychainError
        }
    }

    /// Delete a single item.
    static func delete(account: String) throws {
        let status = SecItemDelete([
            kSecClass: kSecClassGenericPassword,
            kSecAttrAccount: account,
            kSecAttrService: service,
            ] as NSDictionary)
        guard status == errSecSuccess else { throw Errors.keychainError }
    }

    /// Delete all items for my app. Useful on eg logout.
    static func deleteAll() throws {
        let status = SecItemDelete([
            kSecClass: kSecClassGenericPassword,
            ] as NSDictionary)
        guard status == errSecSuccess else { throw Errors.keychainError }
    }

    enum Errors: Error {
        case keychainError
    }
}

Example

And here's how you'd use it, although you shouldn't be force-unwrapping things in practice!

try Keychain.set(value: "FooBar".data(using: .utf8)!, account: "username")
try Keychain.set(value: "YadaYada".data(using: .utf8)!, account: "password")
let user = try Keychain.get(account: "username")
let pass = try Keychain.get(account: "password")
try Keychain.delete(account: "username")
try Keychain.deleteAll()

Alternatives

If you want something a bit more thorough and feature-rich, please consider these alternatives which look reasonably good: matthewpalmer/Locksmith and jrendel/SwiftKeychainWrapper

Having said that, I hope this post is still a good example of how to handle C libraries that require UnsafeRawPointers.

MIT license applies. No warranties. You should get a security team to review all code in your project, such as this.

Thanks for reading, I hope this helps someone, and have a great week!

Photo by Chunlea Ju on Unsplash

I tried recently to find a pure-Swift CommonCrypto wrapper, but all I could find were Obj-C wrapper libraries that were overkill. So, here I'd like to demonstrate how to bridge from Swift (version 5) to all those awkward UnsafeRawPointer and UnsafeMutableRawPointer types that face you when using libraries like CommonCrypto.

I'll also share some best-practices when using encryption, to wit:

• Use CBC mode, not ECB.
• Use PKCS7 for padding so that your input size doesn't have to be a multiple of 128 bits.
• Generate a fresh Initialisation Vector each encryption. It doesn't need to be hidden, just random.

CommonCrypto wrapper

Note that operation/algorithm/options are ints, because that's the type of the constants (kCCEncrypt, kCCDecrypt, kCCOptionPKCS7Padding, etc), whereas the param types are Int32. This is intended to make life more convenient for the caller.

CCrypt wants inputs (eg: key, iv, dataIn) like so: iv: UnsafeRawPointer!. To bridge from Swift to C, these steps are use for input data:

• Convert Data to UnsafeRawBufferPointer by calling withUnsafeBytes
• Then convert UnsafeRawBufferPointer to UnsafeRawPointer by calling baseAddress

Output data is a param of type UnsafeMutableRawPointer. To handle these, first allocate a buffer with: UnsafeMutableRawPointer.allocate(byteCount:alignment:). You're responsible to deallocate that, so defer it immediately: defer { dataOut.deallocate() }. Finally, copy its contents back to a Swift Data with Data(bytes:count:).

func crypt(operation: Int, algorithm: Int, options: Int, key: Data,
        initializationVector: Data, dataIn: Data) -> Data? {
    return key.withUnsafeBytes { keyUnsafeRawBufferPointer in
        return dataIn.withUnsafeBytes { dataInUnsafeRawBufferPointer in
            return initializationVector.withUnsafeBytes { ivUnsafeRawBufferPointer in
                // Give the data out some breathing room for PKCS7's padding.
                let dataOutSize: Int = dataIn.count + kCCBlockSizeAES128*2
                let dataOut = UnsafeMutableRawPointer.allocate(byteCount: dataOutSize,
                    alignment: 1)
                defer { dataOut.deallocate() }
                var dataOutMoved: Int = 0
                let status = CCCrypt(CCOperation(operation), CCAlgorithm(algorithm),
                    CCOptions(options),
                    keyUnsafeRawBufferPointer.baseAddress, key.count,
                    ivUnsafeRawBufferPointer.baseAddress,
                    dataInUnsafeRawBufferPointer.baseAddress, dataIn.count,
                    dataOut, dataOutSize, &dataOutMoved)
                guard status == kCCSuccess else { return nil }
                return Data(bytes: dataOut, count: dataOutMoved)
            }
        }
    }
}

Random bytes generation

Here's my pure-Swift wrapper for generating random bytes:

func randomGenerateBytes(count: Int) -> Data? {
    let bytes = UnsafeMutableRawPointer.allocate(byteCount: count, alignment: 1)
    defer { bytes.deallocate() }
    let status = CCRandomGenerateBytes(bytes, count)
    guard status == kCCSuccess else { return nil }
    return Data(bytes: bytes, count: count)
}

Simple encryption and decryption

Here's my using-the-good-options version of encryption/decryption:

extension Data {
    /// Encrypts for you with all the good options turned on: CBC, an IV, PKCS7
    /// padding (so your input data doesn't have to be any particular length).
    /// Key can be 128, 192, or 256 bits.
    /// Generates a fresh IV for you each time, and prefixes it to the
    /// returned ciphertext.
    func encryptAES256_CBC_PKCS7_IV(key: Data) -> Data? {
        guard let iv = randomGenerateBytes(count: kCCBlockSizeAES128) else { return nil }
        // No option is needed for CBC, it is on by default.
        guard let ciphertext = crypt(operation: kCCEncrypt,
                                    algorithm: kCCAlgorithmAES,
                                    options: kCCOptionPKCS7Padding,
                                    key: key,
                                    initializationVector: iv,
                                    dataIn: self) else { return nil }
        return iv + ciphertext
    }

    /// Decrypts self, where self is the IV then the ciphertext.
    /// Key can be 128/192/256 bits.
    func decryptAES256_CBC_PKCS7_IV(key: Data) -> Data? {
        guard count > kCCBlockSizeAES128 else { return nil }
        let iv = prefix(kCCBlockSizeAES128)
        let ciphertext = suffix(from: kCCBlockSizeAES128)
        return crypt(operation: kCCDecrypt, algorithm: kCCAlgorithmAES,
            options: kCCOptionPKCS7Padding, key: key, initializationVector: iv,
            dataIn: ciphertext)
    }
}

Example

And here's how you'd use it, although you shouldn't be force-unwrapping things in practice!

let key = randomGenerateBytes(count: 256/8)!
let superDuperSecret = "The quick brown fox jumps over the lazy dog".data(using: .utf8)!
let encrypted = superDuperSecret.encryptAES256_CBC_PKCS7_IV(key: key)!
let decrypted = encrypted.decryptAES256_CBC_PKCS7_IV(key: key)!
print(String(data: decrypted, encoding: .utf8)!)

CryptoKit

Once you're happy to only support iOS13+, you should consider using CryptoKit over CommonCrypto: https://developer.apple.com/documentation/cryptokit/

Having said that, I hope this post is still a good example of how to handle C libraries that require UnsafeRawPointers.

MIT license applies. No warranties. You should get a security team to review all code in your project, such as this.

Thanks for reading, and have a great week!

Photo by Gabriel Wasylko on Unsplash