How about a compression algorithm that optimizes for the tag’s read/write specificities in addition to data size? How cool would that be!
I don’t know exactly what the memory specs are but there might be better ways to format data than what’s done for usual file formats 
That could definitely be implemented by the external app, but because it’s such a small amount of space, block storage in this case will be byte by byte… no sectors or multi-byte blocks.
Any kind of data compression or encryption or whatever transforms you want to apply to the data just get done by the external application. The applet’s only job is to 1) wait for authentication, 2) on authentication, enable store and read data commands.
1 Like
My thoughts on this topic:
- Even though encrypting your data and storing only the key on your chip while keeping the data in e.g. a cloud storage would be preferrable in terms of avalability, size, and economics, I can kind of see the psychological factor and need for independance when storing data on the chip. From a cryptographic standpoint, just storing the key is sufficient.
- The proposed applet could do either authorization via a PIN, or full content encryption using that PIN (and a key derivation function). Currently, we are thinking of using authorization only for ease of implementation, key handling and performance. The stored data would still be protected by the chip security. This point is open to suggestion.
- Similar to the NDEF applet (and applet installs, btw), each write operation to the chip strains its EEPROM storage. This kind of persistent memory is limited in how often it can be re-written - usually a few ten or hundred thousand times per cell. This might sound a lot, but frequent re-writing of storage is still discouraged.
I believe the p71 has a 500,000 write cycle count (called endurance) per cell… that includes a full cycle of erase and program… so it’s quite resilient. If you wrote to those cells once a day, every day of the year, you’d be able to comfortably fit in well over 1300 years of updates.
Even writing 10 times a day, every day of the year, you’d still get well over 100 years of safe updates. I think it’ll be fine 
3 Likes
I understand you you mean by benefits of cloud, but let’s say you’re a crypto expert and you want to store your private key somewhere you wouldn’t use any cloud to store it because you want to keep your key as near as possible.
Correct, the private key should still be stored on your chip. However, Id argue that the encrypted data can be stored whereever, e.g. in the cloud.
I agree if it has good encryption it can be stored everywhere but if you’re that paranoid like me or my friends you don’t want to use cloud.
1 Like
Solution: two apexes one to store the key one to store the encrypted file
3 Likes
4 Likes
In theory, yes. This is why I considered my encrypted contact card thing “privacy friendly”.
But from a pentest view, this is not really true. You still want to limit who gets the encrypted data.
At least because the crypto might be broken.
But even if the crypto can’t be broken in the next X years, using “the cloud” leaks some info to the provider.
When & how much data is saved for example, what IP did that write etc.
Some forms of encryption also allow to modify the plaintext by modifying the encrypted data.
So it’s not that simple.
2 Likes
Is there any update about the applet?
I’m just curious.
It’s on our agenda, it’s just at the bottom at the moment
1 Like