例如，MD5和SHA算法
例如，RSA算法，非对称加密加解密比较耗时，实际使用中，往往与对称加密和摘要算法结合使用
数字签名的作用是我对某一份数据打了个标记，表示我认可了这份数据(签了个名)，然后我发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过。
哪怎么做呢？
对一份数据，算出摘要之后，用私钥加密这个摘要，得到一份加密后的数据，称为原始数据的签名。把它跟原始数据一起发送给用户。
用户收到数据和签名后，用公钥解密得到摘要，同时用户用同样的算法计算原始数据的摘要，比对这里计算出来的摘要和公钥解密签名得到的摘要是否相等，若相等则表示这份数据中途没有被篡改过，因为如果有篡改，摘要会变化。
安装包不需要传到苹果服务器，经过苹果认证后，可以直接安装到手机上。
这里就间接验证了这个 APP 安装行为是否经过苹果官方允许。
描述文件是在AppleDevelop网站创建，描述文件里面就是 可以安装的设备有哪些，APP的ID是什么，权限是些什么!
第 3 步证书下载到本地.这时本地有两个证书.一个是第 1 步生成的私钥,一个是这里下载回来的证书,keychain 会把这两个证书关联起来,因为他们公私钥是对应的,在XCode选择下载回来的证书时,实际上会找到 keychain 里对应的私钥去签名.这里私钥只有生成它的这台 Mac 有,如果别的 Mac 也要编译签名这个 App 怎么办?答案是把私钥导出给其他 Mac 用,在 keychain 里导出私钥,就会存成 .p12 文件,其他 Mac 打开后就导入了这个私钥.
AppStore的签名验证方式有些不一样，前面我们说到最简单的签名方式，苹果在后台直接用私钥签名App就可以了，实际上苹果确实是这样做的，如果去下载一个AppStore的安装包，会发现它里面是没有embedded.mobileprovision文件的，也就是它安装和启动的流程是不依赖这个文件，验证流程也就跟上述几种类型不一样了。
据猜测，因为上传到AppStore的包苹果会重新对内容加密，原来的本地私钥签名就没有用了，需要重新签名，从AppStore下载的包苹果也并不打算控制它的有效期，不需要内置一个embedded.mobileprovision去做校验，直接在苹果用后台的私钥重新签名，iOS安装时用本地公钥验证App签名就可以了。
那为什么发布AppStore的包还是要跟开发版一样搞各种证书和Provisioning Profile？猜测因为苹果想做统一管理，Provisioning Profile里包含一些权限控制，AppID 的检验等，苹果不想在上传AppStore 包时重新用另一种协议做一遍这些验证，就不如统一把这部分放在 Provisioning Profile里，上传AppStore时只要用同样的流程验证这个 Provisioning Profile是否合法就可以了。
所以 App 上传到AppStore后，就跟你的 证书 / Provisioning Profile 都没有关系了，无论他们是否过期或被废除，都不会影响AppStore 上的安装包。
原文：https://www.cnblogs.com/Lanht/p/11152199.html