1.5w+
社区成员
- 主页
- VC综合技术
- 互联网技术
- MFC AppLauncher
- .NET 技术
- 界面
- 进程
- 算法
- 硬件/系统
- 数据库
- VC++技术资源
向大家请教关于vc下文件加密的事情
大家好 我是mobile平台下的开发者 mobile平台和Win32 api基本统一 不同的是只支持Unicode接口
最近在做的程序里面，有比较敏感的资料，所以要进行aes加密，在网上找了些实现，可是基本上都是ansi的，感觉也不是可靠，不知道大家有没有做过的经验呢？ 有没有比较好的库推荐下？ 或者其他好的方式？
昨天我使用CComBSTR和CT2CA在两种字符集之间转化再使用ansi的加解密库 可是就成功了一次 然后后面每次都不行了 >_<
接口的参数是char*的 所以每次我都是在char和wchar_t之间转换 目前是用字符串做实验的 因为以后肯定会有用输入的字符串的情况 查看的时候 加密完的char字节块是16字节 加密后看到的char里全是乱码 可是转换成wchar_t之后就不是16个字符了 这样解密貌似当然出错 目前对于这个理解有困难 恳请大家帮助 >_<
文件倒无所谓 文件可以用c的ansi接口
对于字符串和文件的加密 我之前的理解是 反正都是char串 文件也可以读成char串再加解密 所以都一样 可是现在看理解貌似是不对的 请帮帮俺吧 >_<
最近在做的程序里面，有比较敏感的资料，所以要进行aes加密，在网上找了些实现，可是基本上都是ansi的，感觉也不是可靠，不知道大家有没有做过的经验呢？ 有没有比较好的库推荐下？ 或者其他好的方式？
昨天我使用CComBSTR和CT2CA在两种字符集之间转化再使用ansi的加解密库 可是就成功了一次 然后后面每次都不行了 >_<
接口的参数是char*的 所以每次我都是在char和wchar_t之间转换 目前是用字符串做实验的 因为以后肯定会有用输入的字符串的情况 查看的时候 加密完的char字节块是16字节 加密后看到的char里全是乱码 可是转换成wchar_t之后就不是16个字符了 这样解密貌似当然出错 目前对于这个理解有困难 恳请大家帮助 >_<
文件倒无所谓 文件可以用c的ansi接口
对于字符串和文件的加密 我之前的理解是 反正都是char串 文件也可以读成char串再加解密 所以都一样 可是现在看理解貌似是不对的 请帮帮俺吧 >_<
...全文
请发表友善的回复…
发表回复
minvt 2010-07-02
[Quote=引用 3 楼 xiang_yun 的回复:]
如果是用微软的平台，建议去看下微软的CryptoAPI。给给链接：
http://www.vckbase.com/document/viewdoc/?id=974
[/Quote]
我已经下了 这个库好大啊 - - 我目前也就试试 不过貌似不适合 太庞大了
如果是用微软的平台，建议去看下微软的CryptoAPI。给给链接：
http://www.vckbase.com/document/viewdoc/?id=974
[/Quote]
我已经下了 这个库好大啊 - - 我目前也就试试 不过貌似不适合 太庞大了
minvt 2010-07-02
[Quote=引用 5 楼 jennyvenus 的回复:]
ansi、unicode不都是ansi嘛，对于加密函数来讲，不关注输入格式。
[/Quote]
貌似加密函数是对bit进行操作 可是函数的接口是char*的呢
ansi、unicode不都是ansi嘛，对于加密函数来讲，不关注输入格式。
[/Quote]
貌似加密函数是对bit进行操作 可是函数的接口是char*的呢
智能卡_Snooper 2010-07-02
ansi、unicode不都是ansi嘛，对于加密函数来讲，不关注输入格式。
hzy694358 2010-07-02
[Quote=引用 2 楼 minvt 的回复:]
>_< 看见作者的demo用于文件加解密时候没问题呢 为何加密后的乱码char转换成wchar_t那一步长度会减少呢？
[/Quote]
首先
加密后，解密为char，char是不是和之前的未加密的char一样
如果一样，是你自己转换出问题了
如果不一样，是加密这个程序有问题
>_< 看见作者的demo用于文件加解密时候没问题呢 为何加密后的乱码char转换成wchar_t那一步长度会减少呢？
[/Quote]
首先
加密后，解密为char，char是不是和之前的未加密的char一样
如果一样，是你自己转换出问题了
如果不一样，是加密这个程序有问题
xiang_yun 2010-07-02
如果是用微软的平台，建议去看下微软的CryptoAPI。给给链接：
http://www.vckbase.com/document/viewdoc/?id=974
http://www.vckbase.com/document/viewdoc/?id=974
minvt 2010-07-02
>_< 看见作者的demo用于文件加解密时候没问题呢 为何加密后的乱码char转换成wchar_t那一步长度会减少呢？
hzy694358 2010-07-02
wchar_t转换成char再加密
解密也是解成char再转换为char
如果说加密再解密的char 内容不是之前加密的char内容
那肯定是加密的这个程序有问题了
可以换一个……
解密也是解成char再转换为char
如果说加密再解密的char 内容不是之前加密的char内容
那肯定是加密的这个程序有问题了
可以换一个……
minvt 2010-07-02
奇怪了 将加密后的乱码显示在屏幕的edit ctrl中 再取回来的时候 位数就不对了 这咋办？ 标准做法是把二进制显示出来？
minvt 2010-07-02
[Quote=引用 4 楼 hzy694358 的回复:]
引用 2 楼 minvt 的回复:
>_< 看见作者的demo用于文件加解密时候没问题呢 为何加密后的乱码char转换成wchar_t那一步长度会减少呢？
首先
加密后，解密为char，char是不是和之前的未加密的char一样
如果一样，是你自己转换出问题了
如果不一样，是加密这个程序有问题
[/Quote]
报告 检查了一下 是正确的
我现在猜测可能问题在wchar_t和char之间的转换 我用来转换的缓冲区并没有包括\0的位置！ 现在在测试 然后再反馈 现在char和wchar_t之间的转换长度貌似正常了 肯定是疏忽的地方不少 》_《
引用 2 楼 minvt 的回复:
>_< 看见作者的demo用于文件加解密时候没问题呢 为何加密后的乱码char转换成wchar_t那一步长度会减少呢？
首先
加密后，解密为char，char是不是和之前的未加密的char一样
如果一样，是你自己转换出问题了
如果不一样，是加密这个程序有问题
[/Quote]
报告 检查了一下 是正确的
我现在猜测可能问题在wchar_t和char之间的转换 我用来转换的缓冲区并没有包括\0的位置！ 现在在测试 然后再反馈 现在char和wchar_t之间的转换长度貌似正常了 肯定是疏忽的地方不少 》_《
minvt 2010-07-02
[Quote=引用 8 楼 jackson35296 的回复:]
晕，加解密都是直接对byte类型进行加密，二进制数据，哪有专门针对字符串的。不管你的数据是字符串也好，还是其他什么数据，每个字节的值都是0-255。通常16字节一组进行加密，不用管字符编码。
[/Quote]
不好意思 俺是新手 >_<
晕，加解密都是直接对byte类型进行加密，二进制数据，哪有专门针对字符串的。不管你的数据是字符串也好，还是其他什么数据，每个字节的值都是0-255。通常16字节一组进行加密，不用管字符编码。
[/Quote]
不好意思 俺是新手 >_<
jackson35296 2010-07-02
晕，加解密都是直接对byte类型进行加密，二进制数据，哪有专门针对字符串的。不管你的数据是字符串也好，还是其他什么数据，每个字节的值都是0-255。通常16字节一组进行加密，不用管字符编码。