Improvement - Create more Password Slots with dynamic structure to store them

[Peacekeeper2000]

You currently use a fixed size for each password slot you store on NK Storage. This will only give you 16 passwords and also a fixed size for each field inside the slot ( which could limit some usage case and also waste space ).

Proposal : Instead of using a fixed slot size (64 byte) for each password slot, a dynamic password slot size would be preferable.

Maybe the following:

{
u8 SlotStatusAndNextSlot_u8; // AND 0x11000000 ==> Status AND 0x0011 1111 ==> start of next slot
u8 SlotNameLength_u8; // No of bytes used after this byte for slot name
u8 SlotNameStartPtr_u8; // Placeholder : Pointer to the first byte of the slot name
u8 SlotPasswordLength_u8; // No of bytes used for password length
u8 SlotPasswordStartPtr_u8; //Placeholder : Pointer to the first byte of the password of that slot
u8 SlotLoginNameLength_u8: // No of Bytes used for User/Login Name
u8 SlotLoginNameStartPtr_u8; // Placeholder : Pointer to the first 
}

of course this is not the complete structure , but maybe give you an idea how I would structure the slots to squeeze the maximum out of the men space - maybe the read & write routines are a bit more complex. The 1st byte would not even need the start of the next slot coded as this would again limit the slot spaces down from 256 to 64 like your slots today ( but with a more flexible internal structure within the 64 bytes).

With 28 chrs for Slot name , password and login name + overhead of 4 bytes you would get 32 slots. I am sure there are different password requirements ( e.g. for a forum vs an bank account ) that would benefit from such a flexible slot handling.

[szszszsz]

To support more general structure, CBOR could be used.

[Peacekeeper2000]

Is the German saying not " Shoot with canons on sparrow" ? I think a generic aproach like CBOR has some advantages if you store a LOT of data, but in this case ? you try to squeeze more passwords into a given small space. So IMHO you want to reduce over-head. CORB would need at least 3 digits/bits for type + .... All data that you would not need if not an automatic read-out through an api with no clue what to receive would ask for data - that should not be the style of app. Just an opinion ....

[szszszsz]

@Peacekeeper2000 and from the other side, we would have immediately a standardized, tested solution, capable of dynamic storage, and a quick release. Not to mention, that data format could be possibly dynamically changed between the firmware versions. If this would not meet the storage requirements, we could make then a suited solution. I mean in this case it's usage only for the storage, not communication (as in FIDO2). Just an idea anyway though. At the implementation stage it will be verified.

[sebastian-de]

I currently store my passwords in a KeePassXC database on the encrypted partition, but it would be really nice to have support for longer passwords on the Storage 2 directly.