讨论一个私密文件传输的方案
就是尽量不使用普通网络进行私密文件传输，最好是单独两个电路，不使用成品手机或者计算机。比如两个手机号4G点对点，或者固话线路MODEM模块互拨，或者其他的方法？先感谢！ 这似乎是一个需要移动到VIP++区域的帖子感觉方法主要得看距离和希望的速度吧
估计楼主想实现的距离，或者比较实用的距离，用电台可能比较合适，或者普通对讲机，加密传输，这种东西好像差不多2400bps？没听说用9600或更高的。。
虽然我不是HAM，但听说这好像并不是合规的操作（无证操电台+加密传输）。（其实饭店和保安随便对讲机应该也是不对的）
用手机或固话网络的话，似乎与使用普通网络没有什么区别，走这样普通路线的话，对内容做足够的加密应该就可以了吧。
因为内容可以加密，我认为对传输来讲，是否利用现有公共线路的区别主要在于是否能接受暴露发送方和接收方。
如果暴露无所谓，那就只加密内容就好了。
如果这是不能接受的，那只能修自己的路了。 4G 模块用NDIS拨号获取IPv6然后点对点传输，嗯那个给我点酒我还能吹 想加密内容只要在公网上用SSL就可以，跟4G什么的无关。单片机也可以跑SSL，安全性是完全保证的 本帖最后由 dukelec 于 2021-1-1 02:43 编辑
485 傳輸 明文
485 傳輸 加密後的數據
收發一體的軟件無線電
或者在任意不安全的媒介上傳輸加密數據：
開源跨平台的 AES 加解密小工具 CDEncrypt https://www.amobbs.com/forum.php?mod=viewthread&tid=5721440
資源少的 MCU 上加密：
推荐 Linux 源码中的 speck 加密，极简，可用于 stm8 和 51 https://www.amobbs.com/forum.php?mod=viewthread&tid=5715264 2L 已经说得很明白了。其实这个需求大致和战地通信要求差不多。
无线 vs 有线，广播 vs 专线，加密 vs 非密。搞清楚定位和取舍，再说用什么方案。 只要是通过第三方的网络或基站，理论上都有被第三方侦听和拦截的可能性。比如：搭建自己的通信系统（类似VX那样的私用通信服务）也是不可避免。目前最好的应该是量子加密的通信。 数据量大就快递硬盘{:lol:} 加密就好了。普通人那点小秘密根本就不值得别人动脑筋去破解的，放心好了 只是传文件的话，RAR加变态密码就可以了，文件给你也没辙。 随便用个什么对称加密方式, 密钥么,双方事先约好, 比如:
找某本大家都容易找到的书, 然后把发送年月日按一定关系对应到这本书的页/行/第几个字, 加解密时照着查就行.这个密钥的约定是纯口头的, 不留任何网上的或纸面的记录.
福尔摩斯某个案子就是类似的方式, 不过被福尔摩斯猜到了是某年鉴, 然后被解密了, 其实侥幸成分很大. 现在要猜到是哪本书哪有那么容易. vtte 发表于 2021-1-1 12:06
只是传文件的话，RAR加变态密码就可以了，文件给你也没辙。
RAR加变态密码没毛病
都是AES加密，目前基本无解 LZ是需要一个自定义的私有协议吗 类似传真机的功能，点到点，直接输出成A4纸张，但是最好是纯数字化过去的word文件。 tomzbj 发表于 2021-1-1 14:57
随便用个什么对称加密方式, 密钥么,双方事先约好, 比如:
找某本大家都容易找到的书, 然后把发送年月日按 ...
难道你不知道SSL就是解决了密码传输机制的对称加密吗？
用SSL就一劳永逸了。如果不相信公共的根证书服务商，就自己签一个根证书。
完美达到所有的保密需求 castiello 发表于 2021-1-1 15:19
RAR加变态密码没毛病
都是AES加密，目前基本无解
唯一的毛病是别人要知道你的那个密码。如果你要传给别人的话。
给自己备份确实没问题。
SSL消除了需要双方已知密码这个前提。编程也方便，把任何你想用的传输协议装在SSL里面即可。 ANHOME 发表于 2021-1-1 09:58
只要是通过第三方的网络或基站，理论上都有被第三方侦听和拦截的可能性。比如：搭建自己的通信系统（类似VX ...
SSL不怕侦听，不怕造假。
恶意的网络运营商也只有两个选择:或者让你正常使用，或者拦截不让用(你会知道被拦截了)
本帖最后由 canspider 于 2021-1-2 12:30 编辑
ANHOME 发表于 2021-1-1 09:58
只要是通过第三方的网络或基站，理论上都有被第三方侦听和拦截的可能性。比如：搭建自己的通信系统（类似VX ...
瞎扯吧，还理论上能侦听，还把量子计算都搞出来
最简单，弄个复杂密码的rar文件，你去看看谁能破解，能侦听到啥
如果你能想明白为什么复杂密码的rar文件破解不了，你就知道为啥我说你在瞎扯了。 弄个TF卡，夹在手机里，快递过去，本人签收 redroof 发表于 2021-1-2 11:17
难道你不知道SSL就是解决了密码传输机制的对称加密吗？
用SSL就一劳永逸了。如果不相信公共的根证书服务 ...
好啊, 你倒是把openssl往stm32上移植一个试试? 本帖最后由 canspider 于 2021-1-2 20:57 编辑
tomzbj 发表于 2021-1-2 20:29
好啊, 你倒是把openssl往stm32上移植一个试试?
stm32上面能用的ssl叫mbedtls，原来叫polarssl，被arm收编了改名叫mbedtls
用st的cubemx或者是rtthread，都支持
电工最好不要折腾加解密，因为加解密偏向纯软件，需要更加抽象的思维能力，和更扎实的数学基础。如果这两者都具备，何必搞嵌入式，搞纯软工资更高。 本帖最后由 redroof 于 2021-1-2 23:11 编辑
canspider 发表于 2021-1-2 20:55
stm32上面能用的ssl叫mbedtls，原来叫polarssl，被arm收编了改名叫mbedtls
用st的cubemx或者是rtthread， ...
使用不需要什么数学能力啊，这些库都做好了，直接调用就行。
老老实实用正规的完整的SSL，而不是自己编一套加解密流程，这可以在最大限度上减少你的流程中的逻辑漏洞。
要相信完整SSL握手的那一套东西全是有用的，哪一样也不能少。。。
只要严格执行SSL，可以保证完全的安全，别偷懒去精简或者"优化"就行。 2楼说的 有成熟产品叫数传电台，相当于透明串口 zl326498096 发表于 2021-1-4 14:15
2楼说的 有成熟产品叫数传电台，相当于透明串口
你可以用透明串口，也可以用底层的数据帧。那些电台通常都很慢的，如果想多压榨一点性能，你应该自己发送底层数据帧。
因为别人内置的透传打包逻辑肯定不如你自己更清楚自己的数据包有多长。 发送内容加密，接收内容解密。 无关使用什么途径传输数据。
页:
[1]