Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
erikziyunchi opened this issue Jul 29, 2023 · 9 comments

Comments

@erikziyunchi
Copy link

erikziyunchi commented Jul 29, 2023

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?

@zonyitoo
Copy link
Collaborator

Which usizes you want to make changes?

@erikziyunchi
Copy link
Author

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.

@zonyitoo
Copy link
Collaborator

zonyitoo commented Aug 1, 2023

@erikziyunchi
Copy link
Author

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

@zonyitoo
Copy link
Collaborator

zonyitoo commented Aug 1, 2023

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

@erikziyunchi
Copy link
Author

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.

@zonyitoo
Copy link
Collaborator

zonyitoo commented Aug 2, 2023

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

@erikziyunchi
Copy link
Author

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

@zonyitoo
Copy link
Collaborator

zonyitoo commented Aug 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants