Character length to be expected in Laravel 5 Crypt function [duplicate] - laravel

This question already has answers here:
Laravel AES-256 Encryption & MySQL
(2 answers)
Closed 2 years ago.
Just a quick question if I'm using the Laravel 5 Crypt::encrypt() function and I would like to save it into a database, how many characters am i expecting? Does the character length depends on the length of my message or would it be at a fixed length?
Currently I am using varchar 255 in my database and from time to time there are missing characters here and there thus causing problems during decryption.
Thank You

From the official Laravel documentation:
Laravel provides facilities for strong AES encryption via the Mcrypt
PHP extension.
From official PHP documentation using mcrypt_generic.
If you want to store the encrypted data in a database make sure to
store the entire string as returned by mcrypt_generic, or the string
will not entirely decrypt properly. If your original string is 10
characters long and the block size is 8 (use
mcrypt_enc_get_block_size() to determine the blocksize), you would
need at least 16 characters in your database field. Note the string
returned by mdecrypt_generic() will be 16 characters as well...use
rtrim($str, "\0") to remove the padding.
More here
So I guess the correct answer, is that the size of characters generated by the encrypt function depends on the size of the text you are parsing through the encrypt function.
Assuming you are using MySQL,why don't you just use a TEXT if you are parsing a lot of information?
More info about MySQL field types here

The answer is difficult to define because it does depend on your input size. But even a fixed input size yields different size output.
I created a simple script to test real-world sizes for different string lengths.
Here is the GitHub gist
Here's sample output:
Testing Laravel Crypt::encrypt() result length
Number of passes: 1000000
Minimum input length: 1
Maximum input length: 32
Input length: 1 - Output length 188 - 200
Input length: 2 - Output length 188 - 200
Input length: 3 - Output length 188 - 200
Input length: 4 - Output length 188 - 200
Input length: 5 - Output length 188 - 200
Input length: 6 - Output length 188 - 200
Input length: 7 - Output length 188 - 200
Input length: 8 - Output length 188 - 200
Input length: 9 - Output length 216 - 228
Input length: 10 - Output length 216 - 228
Input length: 11 - Output length 216 - 228
Input length: 12 - Output length 216 - 228
Input length: 13 - Output length 216 - 228
Input length: 14 - Output length 216 - 228
Input length: 15 - Output length 216 - 228
Input length: 16 - Output length 216 - 228
Input length: 17 - Output length 216 - 228
Input length: 18 - Output length 216 - 228
Input length: 19 - Output length 216 - 228
Input length: 20 - Output length 216 - 228
Input length: 21 - Output length 216 - 228
Input length: 22 - Output length 216 - 228
Input length: 23 - Output length 216 - 228
Input length: 24 - Output length 244 - 256
Input length: 25 - Output length 244 - 256
Input length: 26 - Output length 244 - 256
Input length: 27 - Output length 244 - 256
Input length: 28 - Output length 244 - 256
Input length: 29 - Output length 244 - 256
Input length: 30 - Output length 244 - 256
Input length: 31 - Output length 244 - 256
Input length: 32 - Output length 244 - 256
Note - if you're running this yourself, you'll need to set it to around 1 million passes per string length to get the actual hard min and max limits. 500,000 wasn't enough in my testing. Also, the get_random_input function only outputs a maximum 32 character string, so it would have to be modified to test longer strings.

The output DOES depend on the size of the input so it is safer to use a TEXT datatype for your column instead of a VARCHAR.
To test it take the largest possible string in your db column and run it through the encrypt() function to see how large the resulting string is. Note that if you are enforcing a length limit on raw text (before encryption) then you may get away with using VARCHAR.

Related

trying to understand how checksum is calculated

I am looking at this page and I am not sure how the author is calculating the checksum. I would contact the author directly, but don't have his email address (its not listed in github).
This is a simple example of a packet with no variables. The author calculates the checksum to be 120 (I assume this is hex as all his other values are in hex). The sum of all the bytes is 0xBA hex or 186 base(10). His notes say "Checksum Low Bit, This bit is checksum of 1-5 bits (MOD 256, if necessary)" but I am not getting what he is saying and I can't figure out how to get to his answer.
Get Version / Return Name
Byte 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Request 16 2 80 20 2 120 16 3
Byte Sample hex Definition
hex (B10)
==== ==== ===== =============================
1 0x16 (22) Preamble 1
2 0x02 (2) Preamble 2
3 0x80 (128) Destination = Chlorinator
4 0x20 (32) Command = Get Name
5 0x02 (2) Not sure. Intellitouch uses 2. Aquarite uses 0. Any of them seem to work.
6 120 Checksum Low Bit, This bit is checksum of 1-5 bits (MOD 256, if necessary)
7 0x16 (22) Post-amble 1
8 0x3 (3) Post-amble 2
Any suggestions would be most appreciated!
Turns out that the commentors were 100% correct: the numbers were express in decimal, not hex as I assumed.

How to calculate the EXTENDED_PAYLOAD_LENGTH if the PAYLOAD_LENGTH is 126 in a WebSocket frame data?

My goal is calculate the payload length of a message sent by a client to the server through the WebSocket protocol.
I am using RFC6455 as a reference.
The length of the "Payload data", in bytes: if 0-125, that is the
payload length. If 126, the following 2 bytes interpreted as a
16-bit unsigned integer are the payload length. If 127, the
following 8 bytes interpreted as a 64-bit unsigned integer (the
most significant bit MUST be 0) are the payload length.
Here is a sample of frame data of message abcdef from a client to the server.
129 134 167 225 225 210 198 131 130 182 194 135
What if, the second byte value is 254, in this case 254 - 128 equals to 126.
129 254 167 225 225 210 198 131 130 182 194 135
I am assuming the third and fourth byte are the EXTENDED_PAYLOAD_LENGTH. In this case, because the second byte - 128 equals to 126, the EXTENDED_PAYLOAD_LENGTH is the actual payload length.
However, in the RFC, it specifically says 16-bit instead of the next two bytes.
If 126, the following 2 bytes interpreted as a
16-bit unsigned integer are the payload length.
How do you combine the third and fourth byte to get the actual payload length? In this case, I wrote the code in Java, and currently I don't have access to read the frame data bit by bit, instead I read it byte by byte.
PS: I am thinking to use bitwise operators, am I going to the right direction?

Tag Size and Cache Bits Exercise

I am studying for my computer architecture exam that is due tomorrow and am stuck on a practice exercise regarding tag size and the total number of cache bits. Here is the question:
Question 8:
This question deals with main and cache memory only.
Address size: 32 bits
Block size: 128 items
Item size: 8 bits
Cache Layout: 6 way set associative
Cache Size: 192 KB (data only)
Write Policy: Write Back
Answer: The tag size is 17 bits. The total number of cache bits is 1602048.
I know that this a failry straight-forward exercise, but I seem to be lacking the proper formulas. I also know that the structure of a N set way associative is |TAG 25 bits|SET 2 bits|OFFSET 5 bits|. And that Tag size = AddrSize - Set - Offset (- item size if any) thus giving the answer of 17 bits tag size.
However, how do I calculate the total number of cache bits please?
cache size in bytes: 192*1024 = 196608
number of blocks: 196608 / 128 = 1536
number of sets: 1536 / 6 = 256
set number bits: log2(256) = 8
offset number bits: log2(128) = 7
tag size: 32-(8+7) = 17
metadata: valid+dirty = 2 bits
total tag + metadata: (17+2)*1536 = 29184 bits
total data: 1536*128*8 = 1572864 bits
total size: 29184 + 1572864 = 1,602,048
There could also be bits used for the replacement policy, but we can assume it's random to make the answer work.

Unpacking a payload using Ruby

I have a hex payload 1703cd0650000aff79fc2802 which I would like to unpack to values. I have been given a definition:
Byte 1:
0bxx01, order: MS nibble
0byyxx, order: LS nibble
Byte 2 0bxxxxxxxx MSB
Byte 3 0bxxxxxxxx LSB
and so on for 12 bytes in total
And I concat byte 2+3 to get a distance in mm. Could anyone help me with an unpack that could achieve this?
I have tried to unpack using 'B8B8B8':
Byte 1, part 1: I get 0001 which I calc to be 1
Byte 1, part 2: I get 1110, which I have reversed (as LSB) which gives me 14
Byte 2: I get 00000011, which I think is 3
Byte 3: I get 11001101, which I reversed to 10110011 (as LSB), which I think is 179
So is the value 3 + 179 concat 3179 or ('00000011' + '10110011').to_i(2) which is 973
I have also tried to unpack with 'B8S>', and byte2 also gives me 973.
Thanks

Is Binary Opcode encoding and decoding implementation specific in websockets?

Suppose I am creating a websocket client. And a specific websocket url returns frame as 'Binary Frame (Opcode 2)' .The questions are 1. Why would the developer want to wrap the original message inside a binary opcode frame?
2. Is retrieving the message implementation centric? In another way, does the the client has to know the same logic that was used to encode at the server? 3. If the above is false then is there a global way to decode/parse the binary opcode to see the actual data that is being sent?
Handling Websocket frames
A Websocket Frames basically look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
Explanation
FIN
The FIN bit tells you if this is all the Data you will receive. Large Websocket messages can be fragmented (Send via multiple frames)
RSV1-3
This are reserved bits, they may be used later
opcode
This can be used to determine what type of frame you received
Possible options are
0 (Continue)
If this frame is a part, not the first part of a fragmented message
1 (Text)
Normal UTF-8 Encoded Text data
2 (Binary)
Binary data
8 (Close)
This closes the Websocket
9 (Ping)
Server pings client to check if client is still reachable
10 (Pong)
Client responds with a Pong and the Ping Data to validate its reachability
MASK
Most significant bit of the 2nd byte, tells you if the payload has been masked. A Server must not mask any frame!
Payload Length (This is where things can get complicated)
Take the 2nd byte and read every bit except the Most significant bit
Byte is 125 or fewer that's your length
Byte is 126
Your length is an uint16 of byte 3 and 4
Byte is 127
Your length is a uint64 of byte 3 to 8
Masking key
Only exists if the MASK bit is set
The next 4 bytes is the masking key, this key is used to decode the payload
Payload
This is not the whole payload if the FIN bit is set
Payload can be decoded either as Text (UTF-8) or Binary (Can be any data)
The payload needs to be masked if the MASK bit is set
Steps to decode a Websocket Frame
Get the FIN bit
Get the first byte and & it with 127, the result is your FIN bit
Get the OpCode (The OpCode tells you what type of frame you have)
Get the first byte and & it with 15, the result is your opcode
Get the MASK Bit
Get the second byte and & it with 127, if it is 127 you have a masking key
Get the payload length
Take the 2nd byte and read every bit except the Most significant bit
Byte is 125 or less thats your length
Byte is 126
Your length is an uint16 of byte 3 and 4
Byte is 127
Your length is a uint64 of byte 3 to 8
Get the masking key
The next 4 bytes is the masking key, this key is used to decode the payload
Payload
The payload is length big and is starting from the masking key
If the MASK bit is set the payload needs to be masked
To demask the payload you just need to xor operation on every byte with the masking key on index count modulo 4
int count = 0;
for (int i = dataIndex; i < totalLength; i++)
{
frameData[i] = (byte)(frameData[i] ^ key[count % 4]);
count++;
}
Interpret the data
Text
Data needs to be interpreted as UTF-8 Text
Binary
This data needs to be interpreted depending on what data you await, this can be achieved by adding a byte to the start of the payload and then interpret it accordingly.

Resources