Skip to content

Releases: leif-ibsen/SwiftECC

3.5.3

17 Jan 15:13
Compare
Choose a tag to compare

Changes in release 3.5.3:

Fixed a number of typos in the documentation discovered by rex4539/Dimitris Apostolou

3.5.2

17 Jan 10:55
Compare
Choose a tag to compare

Changes in release 3.5.2:

The line

platforms: [.macOS(.v10_15), .iOS(.v13)], // Due to the use of the CryptoKit framework

in the Package.swift file has been changed to

platforms: [.macOS(.v10_15), .iOS(.v13), .watchOS(.v8)], // Due to the use of the CryptoKit framework

to support watchOS

Release 3.5.1

22 Dec 10:19
Compare
Choose a tag to compare

Changes in release 3.5.1:

SwiftECC uses Apple's CryptoKit framework
which is available in macOS from version 10.15 and in iOS from version 13.0.

Therefore, the line

platforms: [.macOS(.v10_15), .iOS(.v13)], // Due to the use of the CryptoKit framework

is added to the Package.swift file.

3.5.0

08 Dec 13:25
Compare
Choose a tag to compare

New in release 3.5.0:

A new public key method:

public func encryptAESGCM(msg: Bytes, cipher: AESCipher, aad: Bytes = []) -> Bytes

and a new private key method:

public func decryptAESGCM(msg: Bytes, cipher: AESCipher, aad: Bytes = []) throws -> Bytes

These methods implement AEAD encryption/decryption. They use Apple's CryptoKit framework to achieve
an encryption speed of 2000 MB/Sec and a decryption speed of 1200 MB/Sec measured on an iMac Apple M1 chip.

The CryptoKit framework is available on macOS from version 10.15 and on iOS from version 13.0.

The implementation of the encryptChaCha / decryptChaCha methods now also uses CryptoKit to achieve
encryption/decryption speeds of about 500 MB/Sec.

The old encrypt/decrypt methods with GCM block mode still exist, but they are much slower than the new ones.

The new methods use 12 byte Nonces, whereas the old methods use 16 byte Nonces.
This means that it is not possible to mix encryption and decryption among the two sets of methods.

Release 3.4.1

01 Jun 13:12
Compare
Choose a tag to compare

Changed the dependencies on ASN1 and BigInt to ASN1 2.0.2 and BigInt 1.4.0

3.4.0

02 May 12:46
Compare
Choose a tag to compare

In release 3.4.0 the ECPrivateKey class has a new method 'getKeyAndMac'
that - given an encrypted message - returns the AES blockcipher key and the HMAC key
that were originally used in the encryption of the message.

3.3.0

05 Apr 15:11
Compare
Choose a tag to compare

In release 3.3.0, the ECIES encryption/decryption part of SwiftECC supports
the ChaCha20-Poly1305 cipher and message authentication algorithm.
ChaCha20-Poly1305 is an alternative to the AES-GCM scheme. It runs five times faster than AES-GCM,
and it has the option of including additional authenticated data.

3.2.0

27 Mar 15:23
Compare
Choose a tag to compare

SwiftECC release 3.2.0 supports encrypted private keys.

A private key can be stored in encrypted PEM format 'ENCRYPTED PRIVATE KEY'
according to the PKCS#5 specification using the PBES2 scheme.
The cipher used is one of AES-128, AES-192 and AES-256 in CBC mode.
The iteration count is 2048 and the salt is 8 random bytes.

SwiftECC can read existing 'ENCRYPTED PRIVATE KEY' PEM files, provided they were encrypted with one
of the ciphers AES-128, AES-192 or AES-256 in CBC mode.

Release 3.1.0

22 Mar 08:12
Compare
Choose a tag to compare

In release 3.1.0 the public key constructor

ECPublicKey(domain:w:)

is made public. It was mistakenly made non-public in release 3.0.0

Release 3.0.0

16 Mar 08:43
Compare
Choose a tag to compare

SwiftECC release 3.0.0 supports the PKCS#8 format for private keys:

Private key:

  • Besides generating private keys from their PEM encoding - PEM type 'EC PRIVATE KEY' - it is now also
    possible to generate them from their PEM encoding in PKCS#8 format - PEM type 'PRIVATE KEY'

  • There is a new private key computed property 'pemPkcs8' that returns the PEM string in PKCS#8 format

Public key:

  • There is a new public key constructor that generates a public key from the corresponding private key

  • The public key constructor that generates a public key from its domain and curve point is no longer available
    because it doesn't make sense to generate a new public key independently from its private key