In Chapter 5.1.1. of the RFC 8422 ECC Cipher Suites for TLS the NamedCurveList is described as:
struct {
NamedCurve named_curve_list<2..2^16-1>
} NamedCurveList;
And NamedCurve:
enum {
deprecated(1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25),
x25519(29), x448(30),
reserved (0xFE00..0xFEFF),
deprecated(0xFF01..0xFF02),
(0xFFFF)
} NamedCurve;
From Chapter 4.3 in RFC 5246 it says;
... the length declares the number of bytes, not the number of elements, in the vector.
and also:
The length of an encoded vector must be an even multiple of the length of a single element
And in Chapter 4.5:
An enumerated occupies as much space in the byte stream as would its
maximal defined ordinal value.
My understanding is that the NamedCurve occupies two bytes and a list of NamedCurve would always occupy a multiple of two bytes. So why is the upper limit of the named_curve_list written as 2^16-1 which is an odd number?
Related
I am reading up on AES, but most say it takes a Plain text of 128bits so it can be used in a 44 matrix each of 1 byte where the basic operations like sub byte, shift row, mix column, would be performed on them. Must the plain text be 128bits? according to this website which allows one to run AES online. I used a plain text "big" and it still got encrypted. the text big cannot fill the 44 matrix, so what happens to the remaining space in the matrix ?.
If you use a 'block' mode (ECB or CBC) then the plaintext needs to be padded out to a multiple of the block size (128 bits), generally with 0 bits (though other schemes can be used)
If you use a 'stream' mode (CFB, OFB, or CTR), there's no need to pad out the input -- it can be any length (in bits) and the resulting ciphertext will be the same length.
I checked the storage size but I'm confused when it comes to storing numbers.
In case of Bytes, what does "Byte length" mean? If I store -128 what's the length? And in case of 12?
In case of Floating-point number and Integer, it doesn't matter if I store 325 or 9.9999999999999 it will always be 8 bytes?
In case of Array? Let' say we have ["ab", "bcd"], what's the size, (2+3=5) or (2+1)+(3+1)=7
If you store an array of bytes, the size will simply be the length of that array. An array with a single byte value of -128 is still just one byte.
Yes, all numbers occupy the same 8-byte size, even if you don't see a fractional part.
The documentation says it's the sum of the array element sizes, so I would expect 7, the sum of the two individual string sizes, each encoded in UTF-8 + 1
I have a data that needs to be stored in a database as encrypted, the maximum length of the data before encryption is 50 chars (English or Arabic), I need to encrypt the data using AES-128 bit, and store the output in the database (base64string).
How to know the length of the data after encryption?
Try it with your specified algorithm, block size, IV size, and see what size output you get :-)
First it depends on the encoding of the input text. Is it UTF8? UTF16?
Lets assume UTF8 so 1 Byte per character means 50 Bytes of input data to your encryption algorithm. (100 Bytes if UTF16)
Then you will pad to the Block Size for the algorithm. AES, regardless of key size is a block of 16 Bytes. So we will be padded out to 64 Bytes (Or 112 for UTF 16)
Then we need to store the IV and header information. So that is (usually, with default settings/IV sizes) another 16Bytes so we are at 80 Bytes (Or 128 for UTF16)
Finally we are encoding to Base64. I assume you want string length, since otherwise it is wasteful to make it into a string. So Base 64 bloats the string using the following formula: Ceil(bytes/3) * 4. So for us that is Ceil(80/3) = 27 * 4 = 108 characters (Or 172 for UTF 16)
Again this is all highly dependent on your choices of how you encrypt, what the text is encoded as, etc.
I would try it with your scenario before relying on these numbers for anything useful.
When using the openssl_encrypt() function in PHP to encrypt a string with AES-256-CBC as the encryption method:
$encrypted = openssl_encrypt($data, "AES-256-CBC", $key, 0, $iv);
I tried different string lengths for $data, and the resulting length of $encrypted will increase when $data reaches a multiple of 16 bytes. But it seems the growth is not steady.
Is there a general formula that relates the length of $data and $encrypted?
Let me quote from https://stackoverflow.com/a/3717552/2393787
With CBC mode, the input data must have a length multiple of the block length, so it is customary to add PKCS#5 padding: if the block length is n, then at least 1 byte is added, at most n, such that the total size is a multiple of n, and the last added bytes (possibly all of them) have numerical value k where k is the number of added bytes. Upon decryption, it suffices to look at the last decrypted byte to recover k and thus know how many padding bytes must be ultimately removed.
Hence, with CBC mode and AES, assuming PKCS#5 padding, if the input data has length d then the encrypted length is (d + 16) & ~15. I am using C-like notation here; in plain words, the length is between d+1 and d+16, and multiple of 16.
This states, that the length of your encrypted data can't be predicted with CBC. You should consired moving to another mode.
What does RFC 4880 sec 5.1 mean by "this"?
The value "m" in the above formulas is derived from the session key as
follows. First, the session key is prefixed with a one-octet algorithm
identifier that specifies the symmetric encryption algorithm used to
encrypt the following Symmetrically Encrypted Data Packet. Then a
two-octet checksum is appended, which is equal to the sum of the
preceding session key octets, not including the algorithm identifier,
modulo 65536. This value is then encoded as described in PKCS#1 block
encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to form the "m"
value used in the formulas above. See Section 13.1 of this document
for notes on OpenPGP’s use of PKCS#1.
Is it the 2 octet checksum? is it the entire "one octet prefix + session key + checksum"?