I see. Implementing this kind of lazy encryption myself would exponentially increase complexity, and I'm not sure it's worth it. I'm using the Network framework for two-device peer-to-peer connectivity since I've been advised to stay away from Multipeer Connectivity. However, it seems like Multipeer Connectivity implements its own encryption and all I need to do is specify .required in the argument. My needs are quite simple – only two devices need to share a peer-to-peer connection, and only an image and some text being is sent over that connection. But encryption is a must. Do you think Multipeer Connectivity may be a better fit for my needs?

No. Could you expand on this a little bit? I’ve seen mixed thoughts online about Multipeer Connectivity, and would love to hear yours. Unfortunately, I won’t have physical access to the other device - this is going to be a proximity-based data transfer, kind of like NFC (which I can’t use for various reasons). That’s why I’m using CLBeacon - each phone acts as an iBeacon advertiser and an iBeacon detector, and when it finds a beacon in its immediate proximity, tries to initiate a peer-to-peer connection with them using Network.framework. Maybe the key negotiation could happen during that iBeacon detection phase, where if it detects an iBeacon, it sends it a UInt64 over Bluetooth and receives another UInt64, and then both peers combine them to create the key. Problem is, anyone could just eavesdrop eavesdrop on the Bluetooth connection and gain access to the key. Is there some other form of key negotiation I could do during the iBeacon phase?