# Tag Info

2

AES-256 with $b$ bits of its key known is still secure against key recovery attacks with security level $(256-b)$ bits. Otherwise a shortcut key recovery attack on the regular AES-256 would exist, and the only known attack of this kind -- biclique attack -- does not scale to such subsets of the key space.

3

In this scenario, it is better to use AES-128 than AES-256 if you are to 0-pad a 128-bit key to 256 bits. If you 0-pad, the round key for round 1 is all 0s, and round 3 is effectively worthless as well. So now you are down to 12 effective rounds vs 10 for AES-128. Then you need to look at the effectiveness of the remaining keys. Here are some example key ...

1

I don't know if it has a name, but I can tell you that it is a bad idea. A very bad one. The only thing I have to do to break the encryption is to try all the possible combinations of 4 bytes in the total 24 byte string. Intuition may tell some people that there are many combinations, but really? How many combinations are possible? The answer is 255024. This ...

0

I have a lead about the origin and meaning of $h$, based on the abstract of an ITNG 2008 paper (which is reference [6] of the JACN paper): In this paper, we propose an efficient RSA public key encryption scheme, which is improved version of original RSA scheme. The proposed RSA encryption scheme is based on linear group over the ring of integer mod ...

1

My previous answer was about the IOSR-JECE paper, since you posted the link to JACN paper, I went through that one as well. That paper is considerably better written; it doesn't have any obvious meaningless sentences. Unfortunately, the increased clarity makes it more obvious that their system is insecure as specified. I'll abstract out the bits of the ...

5

As stated in the comments, dev/random already produces cryptographically secure random bytes which are perfectly adequate for use in encryption keys. Running these bytes through another CSPRNG is completely redundant. As far as I've understood, one of the options to create cryptographically secure keys would be to gather entropy from /dev/urandom/ and ...

4

The authors of the paper might be able to tell you; I suspect no one else will. You are having problems understanding the paper; a large part of the reason is that the paper isn't very well written; it introduces terminology (such as "ph") without ever defining it, and includes things that don't make any sense, such as the first line of their "Encryption ...

2

First of all, I suggest you to try use as IV first 16 bytes of encrypted file. Because in general IV is the first block of ciphertext. But if that doesn't work, then – of course – you can decrypt all message except first block. Just use first block as IV, and start to decrypt from second block. That will work because CBC does not provide integrity, and ...

2

I'll start with the last point and use the notation for ECDSA from the wikipedia article. Does it make any more difference if there is data that is known to have been signed by the private key and the signature(s) are known and the raw data is known? When using a digital signature scheme, the parameters (used group, e.g., elliptic curve group) as well ...

1

From my recent experience, it's not always compatible. Using the latest version of GnuPG and Symantec PGP, I was able to confirm at least the fact that a 16384-bit RSA key pair (with 4096-bit subkeys) generated in GnuPG will not be usable in Symantec PGP. All of the cipher, hash algorithm, and compression preferences will be displayed as none, the expiry ...

4

The short answer is NO. Generally, it is not true that for RSA with no padding, the length of data must be equal to the key length. When and if that applies, that's a restriction of a particular cryptographic library, and either that's not the only restriction about the data, or the library does not allow reliable decryption of what's encrypted. RSA ...

Top 50 recent answers are included