shadowsocks-crypto icon indicating copy to clipboard operation
shadowsocks-crypto copied to clipboard

Is there a way to make the size of Cipher consistent between 32 and 64 bit machine?

Open erikchi opened this issue 2 years ago • 9 comments

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?

erikchi avatar Jul 29 '23 17:07 erikchi

Which usizes you want to make changes?

zonyitoo avatar Jul 30 '23 13:07 zonyitoo

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.

erikchi avatar Jul 31 '23 22:07 erikchi

Like these?

https://github.com/shadowsocks/shadowsocks-crypto/blob/092840c53df22658610da77871be2d6aed2a9f15/src/v1/aeadcipher/mod.rs#L139C29-L139C29

Why do they become a problem?

zonyitoo avatar Aug 01 '23 01:08 zonyitoo

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).

erikchi avatar Aug 01 '23 01:08 erikchi

Why are these nlen affect the communication protocol between host and WASM?

zonyitoo avatar Aug 01 '23 04:08 zonyitoo

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.

erikchi avatar Aug 01 '23 14:08 erikchi

Hmm... That is a very strange design. Maybe you should just create a Cipher* and then pass the pointer directly to WASM?

zonyitoo avatar Aug 02 '23 06:08 zonyitoo

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).

erikchi avatar Aug 02 '23 15:08 erikchi

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.

zonyitoo avatar Aug 02 '23 16:08 zonyitoo