OAEP (i.e. Optimal Asymmetric Encryption Padding) as defined in RFC 2437 is
parameterized by the choice of hash function and mask generation function.
The hash function is usually either SHA-1 or SHA-2 while the only mask generation function defined is MGF1 which itself is
based on a hash function.
In the Security.framework this padding scheme is available as OAEP (deprecated as of iOS 15) and as properties of the SecKeyAlgorithm structure, e.g. rsaEncryptionOAEPSHA1. The documentation for both only reads
No overview available
but from the comments in SecKey.h can be gleaned that at least for rsaEncryptionOAEPSHA1
data is padded using OAEP padding scheme internally using SHA1.
So it seems that while using SecKeyAlgorithm the choice of hash function corresponds to selecting a property of the structure; the question that remains is whether this hash function is used for both the encoding scheme and the mask generation function. I suppose that this is in fact the case, but I am unable to find anything corroborating this.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
The documentation states:
iOS, iPadOS, macOS, and tvOS apps can share a single target. watchOS apps remain in a separate target.
Why is that?
I am trying to use SecItemUpdate in order to change the kSecAttrAccessControl value on a private key protected by the Secure Enclave as well as an .applicationPassword - which I want to change. I have been unsuccessful getting the query and attributesToUpdate dictionaries right though, with SecItemUpdate returning either errSecParam, errSecNoSuchAttr or errSecAuthFailed. Am I on the right track here or am I trying to do something that is not possible?
Our app creates ECDSA signatures by calling SecKeyCreateSignature() using a private key that is protected by the secure enclave. On iOS 17 beta our backend rejects some of those signatures as invalid while on previous iOS versions everything is fine. Did anything change in the security framework in iOS 17 that I missed in the release notes or the API diffs?
I am trying to use the NFCTagReaderSession to SELECT the master file of a ISO 7816 smartcard by sending a corresponding NFCISO7816APDU after connecting to the card, but I am running into errors:
Error Domain=NFCError Code=2 "Missing required entitlement" UserInfo={NSLocalizedDescription=Missing required entitlement}
Error Domain=NFCError Code=103 "Session invalidated" UserInfo={NSLocalizedDescription=Session invalidated}
I know that in order to communicate with a NFCISO7816Tag I need to declare the supported AIDs in the Info.plist, but what am I supposed to declare here?
We have found that on iOS 26 beta some of our app icons built from an Xcode 16 asset catalog containing a single 1024x1024 .png file have a Liquid Glass effect applied to them while others have not.
The documentation states that
If you choose not to use Icon Composer, you can still use an AppIcon asset catalog in your project containing individual app icon images and let the system apply the Liquid Glass material.
and
If you prefer, you can take advantage of the system’s automatically generated treatment that is applied to all app icons.
Is there any insight into how the system treats app icons that have not yet been updated with Icon Composer?
Hi everyone, I'm lost here.
Our CI builds on Jenkins nodes every now and then get into a state where Check Dependencies fails with exit status 65 since allegedly the file pointed to by the CODE_SIGN_ENTITLEMENTS build setting cannot be opened. The file is present however, since it is checked out from version control and its permissions seem to be fine as well. We do run a pre-action script before the build action that modifies this file to enable us to build with different sets of entitlements, though. This happens with both the old and the new build system by the way. Is it possible that pre-action scripts somehow run asynchronously or that .entitlements files are handled differently during Check Dependencies?
Is there a way for an app to interact with the new iOS 18 feature "Locked/Hidden Apps"? In our apps we prompt our users for biometric authentication ourselves and found that locking an app seems to interfere with that.
After the XPC Updates from last year I am trying to understand what is possible with XPC on iOS. The documentation for XPCSession states it is available, but none of its initializers is. So how is one supposed to use it?
I have been bitten by this repeatedly so I am finally going to ask: Is there a way to infer an error from its localizedDescription only?
It sometimes happens that a user reaches out for support with just a localized error message, but no error code or error domain and it is really hard to correctly guess what the non-localized description may have been in order to search for it.
For example I know from experience that "Der eingegebene Benutzername oder das Passwort ist ungültig." is the German localization of "The user name or passphrase you entered is not correct." which in turn is errSecAuthFailed (aka. -25293). It would be really helpful to be able to just look this up somewhere...
Suppose there is a key in the keychain that is protected by an ACL which specifies .userPresence as its access control - is it possible to prevent the user from being prompted to authenticate with biometrics and to force authentication via the device passcode instead?
The CA/Browser Forum has voted (cf. https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/9768xgUUfhQ?pli=1) to eventually reduce the maximum validity period for a SSL certificate from 398 days to 47 days by March 2029.
This makes statically pinning a leaf certificate rather challenging.
What are the consequences for App Transport Security Identity Pinning as it exists today?
For testing purposes we have code that calls SecTrustEvaluateAsyncWithError() with a trust object containing a hardcoded leaf certificate and the corresponding intermediate certificate required to form a valid chain. Because the leaf certificate has since expired we pass a date in the past via SecTrustSetVerifyDate() at wich the certificate was still valid, but trust evaluation fails:
Error Domain=NSOSStatusErrorDomain Code=-67825 "“<redacted>” certificate is not standards compliant" UserInfo={NSLocalizedDescription=“<redacted>” certificate is not standards compliant, NSUnderlyingError=0x600000c282a0 {Error Domain=NSOSStatusErrorDomain Code=-67825 "Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;" UserInfo={NSLocalizedDescription=Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;}}}
I know that App Transport Security enforces Certificate Transparency by default, but is there a way around that here?
The header documentation for the (deprecated) LAContext.evaluatedPolicyDomainState property contains the following:
@warning Please note that the value returned by this property can change exceptionally between major OS versions even if the state of biometry has not changed.
I noticed that the documentation for the new LAContext.domainState property does not contain a similar warning. I also found this related thread from 2016/17.
Is the domainState property not susceptible to changes between major OS versions? Or is this generally not an issue anymore?
From man arc4random - x-man-page://arc4random (on macOS 10.15):
The original version of this random number generator used the RC4 (also known as ARC4) algorithm. In OS X 10.12 it was replaced with the NIST-approved AES cipher
Does this hold true for iOS as well and if so from which version on?