是否可以在ECB模式下使用带有IV的AES？
相关·内容
1回答
我需要为固件分发系统实现AES加密。我有一个引导加载程序，可以解密各种AES变体(ECB，CBC，CTR)。
当我处理这个问题时，我发现很少有不清楚的问题。
首先，是IV向量，这对我来说很奇怪。这个向量必须为加密者和解密者所知，这有意义吗？
在解密端(源代码)，我需要输入IV向量，但是在加密器端(软件加密器)，我不能选择IV向量。(NCrypt，AES隐秘岩，氪星)。我知道欧洲央行不需要它，但是没有它，软件加密器怎么能做CBC或CTR，它是随机生成的吗？如果是的话，解密者将如何知道呢？
另一个问题是关于加密文件的实际大小。它一定是可以除以块大小的，对吧？那么，如果我的块大小是128，为什么AE
浏览 0提问于2012-09-13得票数 5
回答已采纳
2回答
假设我有一个API，它接受明文和IV作为输入参数，并返回密文。我知道API正在使用AES 128加密，但现在我需要确定它使用的是哪种加密模式(ECB、CBC、OFB、CFB或CTR)。如何识别加密模式？任何建议、暗示或指导都将不胜感激。
示例：
curl "http://dev/api/v1.0/test?iv=00112233445566778899&text=01234567"
答复：7fcb5212d14de7ddcc334ec31acec6ae
浏览 0提问于2020-10-22得票数 4
回答已采纳
4回答
我想找出哪种AES密码最适合使用。我和OpenSSL红宝石一起工作。
在测试各种选项时，我注意到大多数密码会导致部分甚至完全解密，而不管IV值如何。
我只是想知道这是否是我应该关注的问题，或者即使这是创业板维护人员应该注意的一个bug。
例: CBC，CFB8，CFB1，CFB，cbc-hma-sHA256和cbc-hma-sHA1，只有前16个字节仍然是加密的.
欧洲央行允许完全解密而不考虑IV。
这是我用来测试的红宝石代码。
ciphers = [
'AES-256-CBC', 'AES-256-CTR', 'AES-256-XTS'
浏览 0提问于2018-03-26得票数 4
回答已采纳
1回答
如果AES的某些操作模式不安全(比如欧洲央行或CBC)，这些操作模式很容易发生翻转/操纵攻击，那么为什么NIST没有禁止或建议其他机构使用这些操作模式，并且仍然推荐它们？
我所知道的最后一个出版物是：分组密码操作模式的推荐。
从文件中：
“该建议规定了对称密钥分组密码算法的五种保密操作模式，例如FIPS Pub. 197中指定的算法、高级加密标准(AES) 2。这些模式可与联邦信息处理标准(FIPS)批准的任何对称密钥分组密码算法一起使用。这五种模式--电子码本(ECB)、密码块链接(CBC)、密码反馈(CFB)、输出反馈(OFB)和计数器(CTR)模式--可以提供数据机密性。”
浏览 0提问于2019-09-24得票数 3
openssl AES-128-CBC可以用不同于IV加密的新IV解密.
看来，只要他们共享相同的密钥，IV就不会改变密码的太多。
我有一个例子，使用K=k1和iv= iv1加密文件A到B，然后使用k=k1 iv=iv2将B解密成明文C。令人惊讶的是，A和C之间的差别不大。
k1 = 37424344454647483132333435363738
iv1 = 394832344b697d302524792138325e23
iv2 = 61626364242525262331323334374b4c
以下是命令
$openssl aes-128-cbc -K '3742434445
浏览 0提问于2023-05-24得票数 0
1回答
拟议的密码套件(使用aes-ecb)：
cipherText = aes-ctr(key, ++iv, (plainText)); & authTag= aes-ctr(key, iv, aes-ecb(key, sha-1(cipherText+authData+key+iv)));
安保目标：
plainText的加密。
cipherText & authData的完整性。
cipherText & authData的真实性。
已使用的组件及其使用原因：
沙-1:检查cipherText & authData的完整性。
aes-ctr:用于明文加密&
浏览 0提问于2018-12-13得票数 -3
2回答
我认为AES 128 CTR模式应该工作在16字节(128位)的块上，就像CBC模式一样。
实际上，如果我尝试使用openssl编码18个字节的明文：
max@jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nopad -nosalt -aes-128-cbc -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
bad decrypt
140670739715200:error:0607F08A:digital envelope r
浏览 0提问于2019-07-16得票数 0
回答已采纳
2回答
今晚我上了一堂基础密码学的速成课程，我想我不想清楚地发送一个IV，所以我用字符串对它进行了加密。
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$encrypt = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key1, $string, MCRYPT_MODE_CBC, $iv);
$string = $iv.$encrypt;
$encrypt = mcrypt_encryp
浏览 3提问于2012-11-09得票数 0
回答已采纳
我正在使用Node.js的密码模块和AES-256-CBC密码算法编写我自己的安全类。
但是，当我试图解密从超过15个字符的输入数据加密的加密字符串时，会出现以下错误：
crypto.js:153
var ret = this._handle.final();
Error: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
我认为问题在于加密或IV代，事实上，加密的十六进制字符串总是32个字符长。
让我们一起回顾一下代码：
var crypto = require("crypto")
浏览 0提问于2015-11-07得票数 4
回答已采纳
AES/ECB通常被认为是“弱”的，以至于一些静态分析软件认为它不安全，并建议使用AES/CBC。
问题是:如果加密输入的大小总是小于或等于16个字节，怎么办？
我怀疑在这种情况下AES/ECB会和AES/CBC一样好.
另一个问题是:对于<16字节的输入，AES/GCM是否比AES/ECB & bytes /CBC更安全？
谢谢
浏览 0提问于2020-07-20得票数 4
2回答
我目前正在使用AES-ECB加密一个android应用程序的用户密码，但我必须连接这个应用程序的数据库到一个网站，在那里用户可以注册和登录的方式与移动应用程序相同。
我读到ECB模式是不安全的，所以我想通过生成IV来使用CBC。
将IV作为常量存储在代码中是否安全(我也是这样存储密钥的)，在服务器端的php和应用程序中都是如此？
如果没有，有没有办法让网站和手机应用程序共享它的IV来加密/decrypt用户密码？
或者，我可能选择了错误的加密算法，也许有一种更适合我的需求
浏览 0提问于2012-12-11得票数 1
1回答
我计划使用带有md5的AES128与服务器进行短消息(16-64字节)。我知道MD5的使用，这不是个好主意，但我认为MD5是物联网嵌入式处理器的最佳散列解决方案。我的消息会很短。哈希将包含解密的数据加上来自固件的一些恒定的“指纹”。我有关于使用CBC模式+ MD5的问题。当我加密第一个16字节的消息时，我得到了一些来自AES和MD5的结果，然后用相同的输入数据给出了不同的AES和相同的MD5。这一事实如何降低AES加密可靠性？或者需要使用ECB模式？
浏览 0提问于2019-09-18得票数 0
2回答
我有一个主AES密钥，我需要用这个密钥加密其他AES密钥。欧洲央行加密高度随机数据(密钥)安全吗？如果我使用CBC，我会得到什么好处？
具体而言，以下方法是安全的，哪些方法更安全，以及为什么：
AES-ECB(random_data)
AES-CBC(random_data，iv =0)
AES-CBC(random_data，iv =随机)
浏览 0提问于2017-03-27得票数 4
我使用节点和密码模块来加密和解密一个大的二进制文件。我使用加密文件，并使用对其进行解密。
对于加密，我使用随机IV，如下所示：
const iv = crypto.randomBytes(16);
const encrypt = crypto.createCipheriv('aes-128-cbc', key, iv)
我不明白的是，我是否也需要为createDecipheriv传递一个随机的IV？SO 说：
在加密和解密方面，IV必须是相同的。
静脉可以是静态的吗？如果不能，这是否被认为是秘密？我把静脉输液放在哪里？在有效载荷里？
如果我使
浏览 1提问于2021-10-04得票数 0
回答已采纳
我所说的安全性是指编码的字符串与随机噪声是无法区分的，并且对同一文本的每次加密都是不同的，因此不可能猜测所使用的加密算法或对编码文本进行任何字典攻击。
第二:输出字符串长度与输入字符串长度不一致，无法对该账号进行猜测。
第三:可以验证所提供的密码是不正确的，因此解码函数可以返回false，而不是假设解码的随机字符串。
- edit:这是给定的算法和模式对编码的速度：
0.554 : cast-128 : ctr : 8
0.556 : gost : ncfb : 8
0.5562 : cast-128 : ecb : 8
0.5566 : cast-128 : ncfb : 8
0.5579
浏览 2提问于2011-01-01得票数 0
1回答
我对AES加密有问题。我需要使用随机IV加密明文，然后用相同的密钥加密IV。我知道它不需要加密IV，但我需要它作为我的用途。
为了解密消息，我首先解密IV，然后用解密的IV和密钥解密密码。
目前，我正在使用EBC加密IV，因为其他情况下，我需要另一个IV来加密以前的IV等等。
问题是，我能够用一个与加密完全不同的密钥来解密密码。
我做错了什么？
import java.security.SecureRandom;
import java.util.Arrays;
import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import
浏览 0提问于2018-06-28得票数 0
1回答
对于加密处理来说，选择粗粒度的api而不是细粒度的api有什么好的理由吗？
粗略：
AESDecrypt(pad_type,
mode_type,
mode_data, /* CTR or IV */
ciphertext,
plaintext)
很好：
AES128_ECB_Decrypt(ciphertext, plaintext)
AES128_CBC_PKCS5_Decrypt(iv, ciphertext, plaintext)
AES128_CBC_NOPAD_Decrypt(iv, ciph
浏览 0提问于2011-09-15得票数 0
1回答
从这个问题我了解到，对于分组密码来说，使用CBC比使用ECB要好。看来，如果一个人只有部分密码文本，那么解密是困难的，因为解密取决于先前的密码块。
但是，如果一个人有完整的密码文本呢？那么CBC更好吗？看起来，在这种情况下，我们可以先将每个密码块与前一个密码块进行异或，然后将密码文本转换为使用ECB的输出(我假设IV是已知的)。对吗？如果是这样的话，CBC与欧洲央行相比还有什么其他优势？
浏览 0提问于2013-12-22得票数 5
回答已采纳
在中，我看到了在ECB模式下使用AES和IV的代码。
<?php
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$key = "This is a very secret key";
$text = "Meet me at 11 o'clock behind the monument.";
echo strlen($text)
浏览 0提问于2009-11-24得票数 5
回答已采纳
2回答
不同AES加密模式的IV
、、、
我想知道我的理解是否正确！我一直在阅读aes加密和模式(特别是CTR和CBC)，我花了一段时间才理解了IV的概念。如果IV是随机生成的，那么：
在CBC模式中，通常IV是在加密之后加加或附加的，因此使用该第一数据块(即IV )对密码文本的第一块进行解密，并且从该第一数据块上的前一个密码块是用于下一个块的IV。
我不确定在CTR模式下的做法，但是有一个计数器(或现在)为每个块增加IV以进行解密和加密。
如果IV是产生的价值，那么双方都需要就如何产生它达成一致。对于任何模式，使用常数IV并不是真正的推荐使用固定IV。
我还想知道，在不同的AES模式下，在双方之间还使用了哪些其他的标准实践来传递IV
浏览 0提问于2015-02-18得票数 1
回答已采纳
扫码
添加站长 进交流群
领取专属 10元无门槛券
手把手带您无忧上云
相关资讯
热门标签
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM活动推荐
腾讯云开发者
