Comments (6)
Maybe we can add in two functions. A get_attribute_info_map
that returns the map and a get_single_attribute
that does what you described.
And I can put in a comment to get_attribute_info
with that sample code as a helper and note that something returning Unavailable
could be sensitive or invalid.
from rust-cryptoki.
Maybe we can add in two functions. A get_attribute_info_map that returns the map
This is probably over-kill. I'll just make a comment similar to what you wrote out above.
Thanks for the input (and reminding me about zip()
!)
from rust-cryptoki.
Hey!
Back from holidays 🌴
Thanks for your contribution in the crate, that's really appreciated.
I thought that because the get_attribute_info
keeps the order, it would be ok to check which attribute type maps to which attribute info but maybe it would be better to do it in the function already.
Something like this could be possible, having keys
as the vector of AttributeType
and values
as the vector returned by get_attribute_info
. If needed we could do the same with your 2 option above. The only thing I see with that is that you would have to allocate more data but that might be fine as AttributeType
is Copy
and small in size.
Furthermore, get_attribute_info does not return whether or not C_GetAttributeValue returns CKR_ATTRIBUTE_SENSITIVE or CKR_ATTRIBUTE_INVALID.
Good point! In the current implementation we make no difference if the attribute is unavailable because sensitive/unextractable or because invalid. We could add one more variant to the AttributeInfo
enum with Sensitive
for example?
from rust-cryptoki.
Welcome back! Sorry for the delay in the response. Been busy with life and work and such, but I appreciate the response.
I thought that because the get_attribute_info keeps the order, it would be ok to check which attribute type maps to which attribute info but maybe it would be better to do it in the function already.
That is a fair point. My thinking behind this is if you have a long list of attributes you want the information of, it would feel a little "kludgy" to figure out the index into the vector of attributes and corresponding that to the index location of the AttributeInfo
vector that is returned.
The only thing I see with that is that you would have to allocate more data
Maybe we could pass in a mutable reference to a HashMap<AttributeType,AttributeInfo>
and populate that within the function?
We could add one more variant to the
AttributeInfo
enum withSensitive
for example?
Unfortunately, you don't know which attribute is "sensitive" from the return of C_GetAttributeValue
. All you're told is one of the requested attributes is either sensitive or invalid.
For example, if you attempt to get the value of CKA_PRIVATE_EXPONENT
and CKA_EC_POINT
from an RSA private key whose attribute CKA_SENSITIVE
is CK_TRUE
, the ulValueLen
field of both entries will be CK_UNAVAILABLE_INFORMATION
(as CKA_PRIVATE_EXPONENT
would be considered sensitive and CKA_EC_POINT
is not a valid attribute for an RSA private key) and the return from C_GetAttributeValue
would be either CKR_ATTRIBUTE_TYPE_INVALID
or CKR_ATTRIBUTE_SENSITIVE
. The spec doesn't specify which return code takes precedence.
However, in my experience, a lot of applications that use the spec tend to call C_GetAttributeValue
one attribute at a time due to this inability to know what attribute is sensitive/invalid or to get the size or an attribute if it is unknown.
I think it may make sense to return a tuple on the success end that contains the return code?
from rust-cryptoki.
I tried and one could use the following to create a HashMap
out of the current method:
let attribute_types = [
AttributeType::Token,
AttributeType::Private,
AttributeType::Modulus,
AttributeType::KeyType,
AttributeType::Verify,
];
let attribute_info = session.get_attribute_info(object, &attribute_types)?;
let hash = attribute_types
.iter()
.zip(attribute_info.iter())
.collect::<HashMap<_, _>>();
otherwise I am fine to just return the HashMap
from this function. The allocation should be very small.
Thanks for the explanation on the second problem, I see what you mean now.
So, if I'm correct, currently you get AttributeInfo::Unavailable
so you know if your attribute was either INVALID
or SENSITIVE
but you can't use this function with only one attribute type to know exactly which one of the two it was.
I think it may make sense to return a tuple on the success end that contains the return code?
Could work but does not seem ideal to add something that can only be useful in some particular cases (when calling the function with just one attribute type) 😕. What I can propose as well is to add one more method only taking one single attribute type and returning all possible error messages? That way people can use that to check attribute by attribute. We should also add the limitation in the original method.
from rust-cryptoki.
I don't mind about adding a wrapper which return the map
. As for the get_single_attribute
, it's probably a good idea in case someone needs to know :)
from rust-cryptoki.
Related Issues (20)
- Missing constants for x86_64-unknown-linux-gnu HOT 6
- Function name as part of errors HOT 3
- CKA_PUBLIC_KEY_INFO getting TypeInvalid HOT 8
- Wrapper for C_WaitForSlotEvent HOT 5
- finalize() without drop()? HOT 1
- `clone()` and `is_initialized()` HOT 13
- bug: `is_fn_supported()` always returns `true` HOT 1
- UserNotLoggedIn calling decrypt after login.... HOT 5
- Signing and Verifying HOT 2
- PKCS OAEP padding always returns: Pkcs11(ArgumentsBad) HOT 3
- test slot::token_info::test::debug_info fails on 32-bit architectures. HOT 1
- Add Wycheproof-based tests
- Wasm support HOT 2
- session.login fails on MacOS Sonoma HOT 8
- New release? HOT 6
- PkcsOaepParams HOT 3
- Build of cryptoki v0.6.1 failing on Fedora 39+ HOT 23
- Cannot init_token using an HSM with PED
- Do not call C_Finalize if not initialized
- Add support for C_GetInterfaceList
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust-cryptoki.