blocks|key|1053590|text|这个问题的标准答案是格式保护加密(FPE)。+FPE是一种允许您加密数据同时保留其某些格式(可以包括其长度)的技术。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1053591|在安全性方面，大多数FPE方案都是确定性的，这意味着它们没有达到标准的IND安全概念。然而，对于高熵消息分发，这可能不是一个问题(ymmv)。如果您的密文不能比输入明文长一点，您就没有空间可以包含随机IV或调整，因此，除非您的协议变得棘手，否则就不可能进行随机化。|1053592|FPE方案通常确实实现了一种称为“强不可分辨性与随机置换”(+SPRP+)的安全概念。|1053593|有关在网络协议中使用FPE的示例，请参阅关于网络协议混淆的本论文。|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Format-preserving_encryption|1|https://en.wiktionary.org/wiki/YMMV|2|https://eprint.iacr.org/2012/494.pdf^0|A|C|0|0|1T|4|1|0|0|T|3|2^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]|Q|$5|L|M|N|C|$O|R]]|S|$5|L|M|N|C|$O|T]]]]

The standard answer to this question is <a href="https://en.wikipedia.org/wiki/Format-preserving_encryption" rel="noreferrer">format-preserving encryption (FPE).</a> FPE is a class of techniques that allow you to encrypt data while preserving some of its format (which can include its length). 

In terms of security, most FPE schemes are deterministic, which means they do not achieve the standard IND-CPA notion of security. However, for high-entropy message distributions this is probably not an issue (<a href="https://en.wiktionary.org/wiki/YMMV" rel="noreferrer">ymmv</a>). If your ciphertext can't be even one bit longer than the input plaintext, you don't have space to include a random IV or tweak, so randomization is out of the question unless you get tricky with your protocol.

FPE schemes usually do achieve a security notion called "strong indistinguishability from a random permutation", or SPRP. 

For an example of FPE being used in a network protocol, see <a href="https://eprint.iacr.org/2012/494.pdf" rel="noreferrer">this paper</a> on network protocol obfuscation.

blocks|key|1053453|text|任何密码系统，如果密码文本的大小等于明文的大小，必然是确定性的，因此，只有当每个密钥只用于加密一条消息时，才能安全。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Any cryptosystem in which the size of the ciphertext equals that of the plaintext is necessarily deterministic, and thus can only be secure if each key is used to encrypt only one message.

blocks|key|1053657|text|我可以用哪种技术？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|1053658|您可以使用类似于信用卡号码加密的系统:+AES+(用于良好的加密)%2B+FPE+(用于保持长度)。|unstyled|1053659|看看菲利普·罗格威的“格式保护加密概要”+(PDF)|offset|length|entityMap|0|LINK|mutability|MUTABLE|url|http://web.cs.ucdavis.edu/~rogaway/papers/synopsis.pdf^0|0|0|2|I|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Q|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|R|8|@]|9|@$G|S|H|T|1|U]]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

<blockquote>
 Which techniques can I use?
</blockquote>

You can use a system like the ones used for the encryption of credit card numbers: AES (for a good grade of encryption) + FPE (for preserve length).

Have a look at <a href="http://web.cs.ucdavis.edu/~rogaway/papers/synopsis.pdf" rel="nofollow">“A Synopsis of Format-Preserving Encryption” by Phillip Rogaway</a> (PDF)

blocks|key|2195794|text|有许多分组密码模式。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2195795|例如，CBC只对完整的明文块工作，并以块大小的倍数生成密文，因此它不适用于您的情况。|2195796|CTR将块密码转换为流密码，从而生成与明文长度相同的密文。这种模式需要使用一个nonce作为IV。如果没有使用这样的nonce，并且密钥没有改变，攻击者只能通过观察多个密文(因为多时间垫+)才能推断明文的内容。|2195797|2195798|现在不一定是秘密，但它必须只使用一次每密钥。通常，这个时间和密文一起发送，但是这会增加加密数据，这在你的情况下是不适用的。|2195799|2195800|另一种方法是使用有状态加密器来管理计数器。对于每一种加密，它都会增加计数器，将其写回磁盘，并将值用作下一条消息的值。如果双方使用相同的密钥进行通信，一方只能使用奇数非key，而另一方只能使用偶数非key。这是安全和适用的，但需要在加密器的状态。|2195801|虽然保持格式的加密(FPE)是实现这种加密的一个通用原语，在这种加密中，密文的大小(和字符集)与明文相同，但它并没有得到广泛的实现或使用。|2195802|密文窃取(CS)是另一种基于块密码的方法来产生同样大小的密文，但比FPE更容易实现。这些通常被定义为对块密码的非流模式的扩展。维基百科页面展示了欧洲央行和CBC模式与密文窃取的例子。它们可以像FPE那样进行确定性的操作，并且在CTR模式下的多次衬垫攻击是不适用的。唯一的问题是，只有当IV是静态的时候，只有大于单个块的明文才有可能窃取密文。|2195803|欧洲央行政务司司长例子：|2195804|📷|atomic|2195805|结论|header-two|2195806|与FPE和(ECB/CBC)-CS一样，确定性加密使您能够保持与明文大小相同的密文大小，其中FPE还使您能够保持相同的字符集。由于这些都不是随机的，攻击者可能能够比较多个明文的密文，以确定是否先前发送了相同的明文。|2195807|如果状态是可能的，那么CTR或另一种流模式可能是更好的选择，因为它提供了随机化。|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation|1|https://crypto.stackexchange.com/a/108/13022|2|https://en.wikipedia.org/wiki/Ciphertext_stealing|3|IMAGE|IMMUTABLE|imageUrl|https://i.stack.imgur.com/3HhWI.png|imageAlt^0|3|6|0|0|0|2H|4|1|0|0|0|0|0|0|1R|6|2|0|0|0|1|3|0|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|D|3|E|5|6|7|1O|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1P|8|@]|9|@$A|1Q|B|1R|1|1S]]|C|$]]|$1|H|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|1U|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|1V|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1W|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1X|8|@]|9|@]|C|$]]|$1|P|3|Q|5|6|7|1Y|8|@]|9|@$A|1Z|B|20|1|21]]|C|$]]|$1|R|3|S|5|6|7|22|8|@]|9|@]|C|$]]|$1|T|3|U|5|V|7|23|8|@]|9|@$A|24|B|25|1|26]]|C|$]]|$1|W|3|X|5|Y|7|27|8|@]|9|@]|C|$]]|$1|Z|3|10|5|6|7|28|8|@]|9|@]|C|$]]|$1|11|3|12|5|6|7|29|8|@]|9|@]|C|$]]]|13|$14|$5|15|16|17|C|$18|19]]|1A|$5|15|16|17|C|$18|1B]]|1C|$5|15|16|17|C|$18|1D]]|1E|$5|1F|16|1G|C|$1H|1I|1J|-4]]]]

There are many <a href="https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation" rel="nofollow noreferrer">block-cipher modes</a>. 

CBC for example works only on full blocks of plaintext and produces ciphertext as a multiple of the block size, it is therefore not applicable to your case. 

CTR transforms a block-cipher into a stream-cipher, which produces a ciphertext that has the same length as the plaintext. This mode requires the use of a nonce as an IV. If no such nonce is used and the key doesn't change, an attacker may deduce the contents of the plaintexts only by observing multiple ciphertexts because of the <a href="https://crypto.stackexchange.com/a/108/13022">many-time pad</a>. 
The nonce doesn't have to be secret, but it has to be used only once per key. Usually, this nonce is sent along with the ciphertext, but this would increase the encrypted data, which is not applicable in your situation. 
Another way is to have a stateful encryptor, which manages a counter. For every encryption, it would increment the counter, write it back to disk and use the value as a nonce for the next message. If two parties are communicating with the same key, one party may use only odd nonces and the other only even nonces. This is secure and applicable, but requires state at the encryptor.

While Format-Preserving Encryption (FPE) is a general primitive of achieving this sort of encryption where the ciphertext has the same size (and character set) as the plaintext, it is not widely implemented or used.

Ciphertext stealing (CS) is another alternative based on block-ciphers to produce ciphertext of the same size, but is easier to implement than FPE. Those are usually defined as extensions to non-streaming modes for block-ciphers. The <a href="https://en.wikipedia.org/wiki/Ciphertext_stealing" rel="nofollow noreferrer">Wikipedia page</a> shows examples for ECB and CBC modes with ciphertext stealing. They can operate deterministically like FPE and the many-time pad attack as in CTR mode is not applicable. The only problem is that ciphertext stealing is only possible for plaintexts larger than a single block when the IV is static.

CS example for ECB:

<a href="https://i.stack.imgur.com/3HhWI.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/3HhWI.png" alt="enter image description here"></a>

<h3>Conclusion</h3>

Deterministic encryption as with FPE and (ECB/CBC)-CS enables you keep the same ciphertext size as plaintext size, where FPE additionally enables you to keep the same character set. Since those are not randomized, an attacker might be able to compare the ciphertexts of multiple plaintexts to determine whether the same plaintext was previously sent.

If a state is possible, then CTR or another streaming-mode is likely the better option as it provides randomization.

blocks|key|2195613|text|我可以用哪种技术？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|2195614|最理想的选择是使用同步流密码.它们不仅速度快，而且还让你保留明文长度。我知道最好的伪随机数发生器是AES-CTR。|unstyled|2195615|与那些增加数据大小的技术相比，这些技术有多安全。|2195616|这完全取决于算法。增加密文长度的唯一好处是它隐藏了明文长度，这在像你这样的情况下没有多大区别。|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|K|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|L|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|M|8|@]|9|@]|A|$]]]|I|$]]

<blockquote>
 Which techniques can I use?
</blockquote>

The most ideal option is to use synchronous-stream ciphers. They are not only fast, but also let you retain the plaintexts length. The best pseudorandom number generator I know is AES-CTR. 

<blockquote>
 How secure are these techniques as compared to the ones which increase the size of the data.
</blockquote>

It completely depends on the algorithm. The only advantage of the ones that increase the ciphertexts lenghth is that it hides the plaintext length, which doesn't make much difference in cases like yours.

blocks|key|2195849|text|您可以在CTR模式下使用AES。它通常是安全的，但实际上并不适用于大型数据，因为计数器重复每个2%5E{128}块，因此您需要更改每个2%5E{128}块的密钥。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2195850|有关更多信息，请参见这里的此链接。|entityMap|0|INLINETEX|mutability|IMMUTABLE|teX|2%5E{128}|1|2%5E{128}|2|LINK|MUTABLE|url|https://tls.mbed.org/api/aes_8h.html#a375c98cba4c5806d3a39c7d1e1e226da^0|1B|7|1T|7|1B|7|0|1T|7|1|0|D|3|2^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@$9|10|A|11|1|12]|$9|13|A|14|1|15]]|E|$]]|$1|F|3|G|5|6|7|16|8|@]|D|@$9|17|A|18|1|19]]|E|$]]]|H|$I|$5|J|K|L|E|$M|N]]|O|$5|J|K|L|E|$M|P]]|Q|$5|R|K|S|E|$T|U]]]]

You can use AES in CTR mode.
Well it is generally secure, but not really for large data, since a counter repeats every $2^{128}$ blocks, so you need change keys every $2^{128}$ blocks.

See <a href="https://tls.mbed.org/api/aes_8h.html#a375c98cba4c5806d3a39c7d1e1e226da" rel="nofollow noreferrer">this link</a> here for some more information.

I want to encrypt some data(text/voice/video) but it is essential that the size of the cipher data remains the same as the plain data.

Which techniques can I use, and how secure are these techniques as compared to the ones which increase the size of the data?

Which cryptography technique does not increase the size of the plain data?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我想加密一些数据(文本/语音/视频)，但加密数据的大小必须与普通数据相同。我可以使用哪些技术，与那些增加数据大小的技术相比，这些技术有多安全？

问哪种加密技术不会增加普通数据的大小？
EN

回答 6

Cryptography用户

Cryptography用户

Cryptography用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪种加密技术不会增加普通数据的大小？EN

回答 6

Cryptography用户

Cryptography用户

Cryptography用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪种加密技术不会增加普通数据的大小？
EN