3 ms·

I'm aware of JavaCard (and those BASIC cards, which are even more absurd - why would anyone want to implement cryptography in BASIC?). But JavaCard (or BASIC) i

I'm aware of JavaCard (and those BASIC cards, which are even more absurd - why would anyone want to implement cryptography in BASIC?). But JavaCard (or BASIC) isn't the real CPU but a VM. So I guess I should have said, "I want a smartcard where I can program the actual CPU, not in some VM." May as well add some random smartcard history... I believe historically one of the reasons for this is that most smartcard chips for the longest times were basically an 8051, a made-to-order mask ROM, and a very small amount of flash (too small for much code). So there was a real need to minimise the size of code which needed to be put in nonvolatile storage. I assume JavaCard implementations have their own implementations of standard cryptographic algorithms in mask ROM to avoid the need to put them in the undersized quantity of flash. But this isn't the case anymore, where you have smartcards with 32-bit ARM cores and which are all flash-based. If there's a way to obtain and program one of these, I'd like to know about it.

lxgr 4y ago
> why would anyone want to implement cryptography in BASIC? The cryptography for these cards is usually provided by the OS or even in custom hardware, mostly for performance reasons: The underpowered 8-bit MCUs that were commonly used for them can't run e.g. RSA in a reasonable timeframe, so they have custom coprocessors for that. > "I want a smartcard where I can program the actual CPU, not in some VM." [...] smartcards with 32-bit ARM cores and which are all flash-based. If there's a way to obtain and program one of these, I'd like to know about it. I'm unfortunately not aware of such a thing in the smartcard world, but if you think about it, this just pushes the problem of trust down one layer. At some point, you'll have to trust the hardware RNG to supply actual randomness (and not just the output of a known-seed PRNG). I suppose it could be useful in some scenarios to get rid of the proprietary OS/VM implementation if you are concerned about bugs there, but in the end, you are still ultimately trusting your hardware vendor. Or are you mainly interested in being able to use a stack other than Java Card?

lxgr 4y ago

> why would anyone want to implement cryptography in BASIC? The cryptography for these cards is usually provided by the OS or even in custom hardware, mostly for performance reasons: The underpowered 8-bit MCUs that were commonly used for them can't run e.g. RSA in a reasonable timeframe, so they have custom coprocessors for that. > "I want a smartcard where I can program the actual CPU, not in some VM." [...] smartcards with 32-bit ARM cores and which are all flash-based. If there's a way to obtain and program one of these, I'd like to know about it. I'm unfortunately not aware of such a thing in the smartcard world, but if you think about it, this just pushes the problem of trust down one layer. At some point, you'll have to trust the hardware RNG to supply actual randomness (and not just the output of a known-seed PRNG). I suppose it could be useful in some scenarios to get rid of the proprietary OS/VM implementation if you are concerned about bugs there, but in the end, you are still ultimately trusting your hardware vendor. Or are you mainly interested in being able to use a stack other than Java Card?