我会放弃直接同步选项，只允许用户以加密格式将他们的私钥导出到他们选择的位置，例如 iCloud、DropBox、内部存储等。

在出口我会做这样的事情：

• 向用户询问要使用的密码。不要对他们施加任何限制 - 使用好的密码是他们的工作！
• 使用强密钥派生算法（例如 PBKDF2）生成存储密钥。使用相当数量的回合。
• 在内存中使用四个已知字节（一个幻数）作为私钥 blob 的前缀，例如“NATG”，以形成您的明文。
• 在 CBC 模式下，使用存储密钥和随机生成的 IV 使用 AES-128 或类似的分组密码加密明文。
• 将密文和 IV 导出到文件中。

导入时：

• 从文件中提取密文和 IV。
• 询问用户密码并使用 PBKDF2 生成相同的密钥。
• 使用 IV 和密钥解密密文。
• 检查明文的前四个字节是否与已知字节匹配。如果不是，那就是密码错误。如果是这样，我们就有钱了！
• 删除前四个字节，你就得到了私钥！

这允许用户通过他们想要的通信服务快速轻松地同步私钥，无论是 iCloud、DropBox 还是电子邮件，并且具有合理的安全级别。如果他们的帐户被入侵，攻击者仍然必须破解他们的密码。如果他们使用了一个像样的，PBKDF2 应该做一个像样的工作，使他们的破解尝试不可行。

私钥本质上与密码相同。为了成为有效的安全设备，它们需要保密。所以不，如果它的文档说它不应该用于密码，那么有理由认为它也不够安全，不能用于私钥。

与多项式的建议相反，我不喜欢导出到 DropBox 或电子邮件，因为大多数最终用户使用可以使用链接应用程序访问整个数据存储的 3rd 方应用程序。

特别是 DropBox 使应用程序很容易获得对整个存储（密钥和所有内容）的完全访问权限。

我目前倾向于iCloud，没有其他应用程序能够读取我保存在私人存储中的数据。我花了一分钟时间来理解这项技术，每个 iOS 应用程序都有自己的容器。

每个应用程序的容器包括

• 他们可以读/写的一个公共数据库
• 每个 iCloud 用户一个私人数据库

一般来说，每个应用程序只有一个容器，这意味着每个 iOS 应用程序都是相互隔离的。

此外，开发者无法直接读取用户 iCloud 数据库的内容。这是 DropBox OAuth 和其他商品存储所没有的功能。

（更不用说，它几乎是免费的）

话虽如此，我仍然会按照多项式的建议进行加密，无论它去哪里。