shadowsocks-crypto
shadowsocks-crypto copied to clipboard
shadowsocks
Is there a way to make the size of Cipher consistent between 32 and 64 bit machine?
I've noticed that there are quite some usize typed variables being used(which will be in size 4bytes in a 32bit machine, and 8bytes in a 64bit machine), and I was trying to change some of them myself, but I realized that there are too many layers, and the size of the constructed object just cannot be aligned between 32bit and 64bit machine. Is there a faster way to force one into another?
When creating an instance of Cipher, there are so many layers of objects(depending on the features chosen), which hide some usizes. But I guess is quite hard to change all of them, but if it's possible in the future maybe use more explicit types like u32 or u64 will be super helpful than usize I guess.
Like these?
https://github.com/shadowsocks/shadowsocks-crypto/blob/092840c53df22658610da77871be2d6aed2a9f15/src/v1/aeadcipher/mod.rs#L139C29-L139C29
Why do they become a problem?
Yeah, like the nlen inside struct AeadCipher. I'm currently trying to make the critical parts(how to pack the package) of the protocol with WASM, but they only have wasm32 which will use 4 bytes for every usize and leads to a hard time when communicating between the host(64 bit) and WASM(32 bit).
Why are these nlen affect the communication protocol between host and WASM?
I first designed it to construct the Cipher object in the host and then pass the bytes to WASM to reconstruct it, since it was passed by bytes, the size will influence the reconstruction.
Hmm... That is a very strange design. Maybe you should just create a Cipher* and then pass the pointer directly to WASM?
That's actually the secure part of WASM where it is not allowed to visit arbitrary memory in the host, and the memory it can visit is a chunk of linear memory that the host has allocated for it (size in page). The current solution I have is to let the WASM construct the Cipher object and then return the pointer to the host to store it (the same thing still, the host is not able to use it since the align is different in 32 & 64 bit).
I just take a look at those const variables in these cipher structs, they all have relatively small value, such as key's kength, iv's length, block's length, ... so it shouldn't be a problem if usize become 32 bits or 64 bits.
In most cases, you could just ignore those const values, because they are not actually used in the internal implementation.