完全没问题，PBKDF2 完全支持从SHA-256的输出中派生出128位的AES密钥，这在移动端加密场景中是非常常规且安全的做法。

核心原理说明 #

PBKDF2的设计本身就允许派生任意长度的密钥（只要不超过 哈希函数输出长度 × (2^32 - 1)，对于SHA-256来说就是256位×4294967295，128位远低于这个上限）。当你指定的派生密钥长度小于哈希函数的输出长度时，PBKDF2会直接截取哈希输出的前N位（N是你需要的密钥长度）；如果更长，则会通过多次哈希拼接的方式生成，但这里128位只需要截取前16字节即可。

实践中的关键注意事项 #

• 明确指定密钥长度：在调用PBKDF2时，直接设置派生密钥的长度为16字节（对应128位AES密钥）。比如伪代码示例：

  derived_key = PBKDF2(
      password=用户输入密码,
      salt=随机生成的16字节盐,
      iterations=合适的迭代次数,
      hash_function=SHA256,
      key_length=16  # 128位 = 16字节
  )
  

• 选择合适的迭代次数：考虑到移动端算力限制，你需要在安全性和性能之间找平衡。建议从10000次开始测试，根据目标设备的响应时间调整——确保用户体验不受太大影响的同时，尽可能提高暴力破解的成本。
• 必须使用随机盐：每次派生密钥都要生成一个随机的、至少16字节的盐，并且将盐和加密后的数据一起存储（盐不需要加密，公开存储即可）。随机盐可以防止彩虹表攻击，确保即使两个用户使用相同密码，派生的密钥也完全不同。
• 避免硬编码参数：迭代次数、哈希函数等参数不要硬编码在代码中，最好预留配置调整的空间，以便随着硬件性能提升增加迭代次数，长期保持安全性。

额外补充 #

虽然SHA-256生成256位输出，但截取前128位作为AES密钥并不会降低安全性——AES-128的安全性本身已经足够应对绝大多数场景，只要你的PBKDF2参数配置合理（足够的迭代次数、随机盐），整个密钥派生流程是安全可靠的。

内容的提问来源于stack exchange，提问作者Ahmet Eroğlu