不要编写自己的密码函数！甚至不是现有功能的直接端口

如果您的语言有任何成熟度，那么它将有一个您可以使用的开源实现。如果没有，请不要移植一个在另一种语言中找到一个，并为它编写一个可以调用的包装器（比如您想要移植的C#实现）。

任何现有的开源实现都将由比我、你和全球99%以上的开发人员更了解密码学的人来测试和验证其正确性。

如果您真的找不到开源实现，请使用C#编写一个简单的.exe，它调用C#实现并返回结果。不包括设置和样板，这基本上是一行代码。

同样，如果你编写自己的实现，你将不可避免地无法解释某些边缘情况，或者对算法不够了解，从而导致一段具有可利用缺陷的危险代码。除非你是3DES的原始开发者之一，或者有多年开发当前使用的加密标准的经验，否则你根本不具备移植实现的技术技能。

同样，如果你编写了自己的实现，出现了问题，你的数据被泄露，你可以也将承担个人责任。Linkedin最近被起诉，要求赔偿500万美元，因为他们没有实施适当的安全措施。这可能会毁掉你的事业。

不要犯与LINKEDIN相同的错误

显然，MACTripleDES类使用TripleDES作为底层分组密码来实现CBC-MAC。如果您可以访问实现CBC-MAC和Triple DES的加密库（并且可以像任何通用CBC-MAC实现一样，将后者用作前者中的块密码），那么您应该能够将它们组合以获得等效的MAC。

或者，如果您的加密库没有直接实现CBC-MAC，而是实现了CBC模式加密，那么您确实可以通过在CBC模式下加密消息，使用全零IV，并将生成的密文的最后一块作为MAC值来实现CBC-MAC。（这只是CBC-MAC的定义。）只使用原始分组密码自己实现CBC模式（或CBC-MAC）也不是特别困难或棘手。但实际上，任何像样的加密库都应该已经内置CBC-MAC，或者至少CBC模式加密。

您应该而不是尝试的是自己实现Triple DES或任何其他分组密码！很难安全地实现像Triple DES这样的低级别加密算法，因为你必须注意侧通道攻击之类的事情，任何这样的实现都应该经过专业密码学家的彻底测试和审查，然后才能用于任何严重的事情。

（这里的一个特殊例外是，如果您只有可以访问纯DES分组密码，则您可能会在此基础上合理安全地实现Triple DES。这是因为Triple DES实际上不是一个单独的低级密码，而只是一种扩展DES密钥空间的方法，通过使用独立密钥对每个块进行多次加密，以牺牲性能为代价。但是同样，在过去20年中编写的任何像样的加密库都应该支持Triple DES，如果它支持DES的话。）

当然，即使只实现CBC-MAC等高级加密算法，也有可能出错，而且这种错误可能会带来安全后果。但在这个级别上，难度和风险并不明显大于最初简单地使用加密（因此，隐含地说，使用加密密钥等安全关键数据）所固有的难度和风险。即便如此，在部署代码之前，让有加密经验的人（或者最好是几个人）审查你的代码总是一个好主意。即使你自己也是加密货币专家，这一点也适用；任何人都可能犯错误，你对代码的关注越多，就越有可能在有人利用错误之前发现错误。

---

最后，请注意，如果您不特别需要与Microsoft的MACTripleDES类兼容，那么MAC算法的选择比CBC-MAC（如CMAC）更好，密码的选择也比TripleDES（如AES）更好。AES和CMAC的具体组合甚至在RFC 4493中进行了标准化，它提供了详细的实现指令和测试向量来验证正确性。

特别是，如果消息长度未经过身份验证，那么纯CBC-MAC对于可变长度消息来说是不安全的。虽然有一些方法可以修复这个漏洞，例如通过在计算MAC之前预先设置消息的长度，但通常最好使用安全的算法；"开箱即用"；，如CMAC。

（此外，由于你在问题中提到了一个"密钥短语"，我希望你在将其用作三重DES（或任何其他分组密码）的密钥之前，实际上是通过一个适当的密钥推导函数来提供它。）。特别是，如果密钥短语是用户提供的，因此可能具有低熵，那么您确实应该使用像PBKDF2、scrypt或Argon2这样的密钥扩展KDF。）