PSA: don't use TI-nspire calculators for encryption
-
A reddit thread has uncovered evidence of a serious lack of entropy in their random number generator
https://i.imgur.com/JW7MsHq.jpg
https://i.imgur.com/11anYdz.jpg
https://i.imgur.com/6AT1jWk.jpgThe company has refused to comment on the allegations of it being an NSA backdoor.
-
This was done after a reboot each time?
-
@anonymous234 If you're using any calculator to generate crypto keys, you're already beyond help, except maybe by
-
@anonymous234 my guess is that the seed is fixed--the sequence of random numbers produced for all models running the same software is the same, including the first set. Bad practice, but for calculators it's kinda meh.
-
@benjamin-hall Do those calculators even have a clock? What else would you seed with?
-
@blakeyrat said in PSA: don't use TI-nspire calculators for encryption:
@benjamin-hall Do those calculators even have a clock? What else would you seed with?
The Nspire should have one--they're pretty advanced. I know they have a timing circuit. Can't bother to check beyond that, though. I know the earlier TI's (TI-85 is what I have) don't. Dunno how much work a simple circuit to get shot noise from the circuits is.
-
@blakeyrat You could seed it with the timing between user keypresses.
All microprocessors already have a bunch of timers inside counting up or down, so you'd just have to put a hook in any user-triggered function that reads that value and uses it to seed the random number generator.
The more sophisticated way would be a circuit that amplified electronic noise, but you obviously can't do that in software.
-
@benjamin-hall said in PSA: don't use TI-nspire calculators for encryption:
@anonymous234 my guess is that the seed is fixed--the sequence of random numbers produced for all models running the same software is the same, including the first set. Bad practice, but for calculators it's kinda meh.
Funnily enough, my 30-year-old Casio FX-82B generates a different random number¹ every time after I pull out a battery, re-insert it, and hit the RAN# function.
¹ Admittedly, just three digits, between 0.000 and 0.999 inclusive.
-
@anonymous234 said in PSA: don't use TI-nspire calculators for encryption:
@blakeyrat You could seed it with the timing between user keypresses.
All microprocessors already have a bunch of timers inside counting up or down, so you'd just have to put a hook in any user-triggered function that reads that value and uses it to seed the random number generator.
The more sophisticated way would be a circuit that amplified electronic noise, but you obviously can't do that in software.
Generally the way you do PRNGs in embedded things with a little bit of grunt is with a Mersenne Twister. If it can't handle that then a Linear feedback shift register is the next best option. It's probably an LFSR in there is my WAG.
The more sophisticated way would be a circuit that amplified electronic noise, but you obviously can't do that in software.
What I've done before is use an uncommitted analogue input, if you route a trace by the power supply you can get a 4 bits or so of noise, enough for a seed that's good enough :)
Edit: Another great source is how long the button bounces for, switches are never binary they always dither back and forth for 10s of milliseconds when actuated. It's also really random how many times it happens, so your debounce routine can count the transitions (and/or total bounce time) and use that.
-
@anonymous234 said in PSA: don't use TI-nspire calculators for encryption:
You could seed it with the timing between user keypresses.
And without a clock, you time it... how?
-
@blakeyrat said in PSA: don't use TI-nspire calculators for encryption:
@anonymous234 said in PSA: don't use TI-nspire calculators for encryption:
You could seed it with the timing between user keypresses.
And without a clock, you time it... how?
As mentioned, they actually have good timers built into the CPU for all but the barest boned microprocessors.
-
Well there goes my latest startup idea: It's like Uber for calculators!
-
@blakeyrat "Clock" has different meanings. Not having a clock just means that it doesn't continuously keep track of the time over long periods while it's off.
However, all microcontrollers have one (or more) internal clock signals, that oscillate at a stable speed to drive the processor cycles. Usually there's also a counter that increments on every cycle (or every N cycles). So you read that counter, and you have the elapsed time.
-
@anonymous234 said in PSA: don't use TI-nspire calculators for encryption:
@blakeyrat "Clock" has different meanings. Not having a clock just means that it doesn't continuously keep track of the time over long periods while it's off.
However, all microcontrollers have one (or more) internal clock signals, that oscillate at a stable speed to drive the processor cycles. Usually there's also a counter that increments on every cycle (or every N cycles). So you read that counter, and you have the elapsed time.
TL;DR - Real-Time Clock ⊆ Clock
Filed Under: or perhaps I should say it as, RTC extends Clock implements ExternalTime, Persistent
-
@boomzilla "It's like Uber for" is the new "it's like Facebook for"!
Filed under: it's like Uber for Facebooks
-
status: OMG it works on 89s too!
(realized there was no
randInt()
function so I expanded it to an expression, and lo and behold...)
-
@tsaukpaetra are you sure the
int()
is necessary? As I remember it,rand(8)
already produces an integer...
Edit: I just tested, in fact not only doesrand(8)
already produce an integer, it's an actual integer rather than a float with an integral value (which is whatint()
returns, hence the dot in the output)
-
@medinoc said in PSA: don't use TI-nspire calculators for encryption:
@tsaukpaetra are you sure the
int()
is necessary? As I remember it,rand(8)
already produces an integer...
Edit: I just tested, in fact not only doesrand(8)
already produce an integer, it's an actual integer rather than a float with an integral value (which is whatint()
returns, hence the dot in the output)It's been years since I legitimately used my calculator for anything more complex than fuel efficiency calculations.
-
@boomzilla said in PSA: don't use TI-nspire calculators for encryption:
Well there goes my latest startup idea: It's like Uber for calculators!
It blatantly flouts every applicable law regarding proper use of calculators, leading to widespread illegal price gouging, calculator theft, and assaults on users?
-
@masonwheeler said in PSA: don't use TI-nspire calculators for encryption:
@boomzilla said in PSA: don't use TI-nspire calculators for encryption:
Well there goes my latest startup idea: It's like Uber for calculators!
It blatantly flours every applicable law regarding proper use of calculators, leading to widespread illegal price gouging, calculator theft, and assaults on users?
Ugh, no. It's gluten free, of course.
-
@boomzilla argh, stupid Autocorrect...
-
I remember that some version of SPSS (is it v11) has this problem too when you use it on a computer freshly flushed with reborn card in the computing lab. I overheard the conversation between students and tutor that the student was accursed to be copying each other's homework because the "random" sample they used are exactly the same, and they have to bring their tutor there to prove they're innocent.
Apparently those "random" value are dumped from the "random number table" with some kind of rule to mock randomness, but these "random factors" are erased by the use of a reborn card.
-
@cheong said in PSA: don't use TI-nspire calculators for encryption:
the student was accursed to be copying each other's homework because the "random" sample they used are exactly the same
Man, I would be accursed to of my random wasn't so...
-
@tsaukpaetra said in PSA: don't use TI-nspire calculators for encryption:
status: OMG it works on 89s too!
And the TI-89 certainly has a clock.
-
@masonwheeler said in PSA: don't use TI-nspire calculators for encryption:
@boomzilla said in PSA: don't use TI-nspire calculators for encryption:
Well there goes my latest startup idea: It's like Uber for calculators!
It blatantly flouts every applicable law regarding proper use of calculators, leading to widespread illegal price gouging, calculator theft, and assaults on users?
Can't argue with the price gouging one. TI has a goddamn monopoly due to being one of the very few 'approved' calculators for standardized testing.
-
@pie_flavor said in PSA: don't use TI-nspire calculators for encryption:
TI has a goddamn monopoly due to being one of the very few 'approved' calculators for standardized testing.
Which they got by going back on the TI-89/TI-92+/V200 advantage of embracing assembly programming, instead locking their calculators as tightly as possible and fighting tooth and nail against jailbreakers.
And apparently we've got the same law here in France (that calculators need to have a "standardized testing" mode that turns them into simple scientific calculators, and the need to enforce this mode leads to locking everywhere), which means the days of I-can-do-anything-with-my-calculator are truly a lost golden age... Thank god for the jailbreaking community.
-
@anonymous234 said in PSA: don't use TI-nspire calculators for encryption:
Usually there's also a counter that increments on every cycle (or every N cycles). So you read that counter, and you have the elapsed time.
I've never come across one, what micro are you thinking of? You can implement one yourself and most RTOSs have something to get elapsed ticks but that's user implementation not a core feature.
Generally timers are in short supply so you don't just have them free-running, they'll be gated or committed to supporting other peripherals.
-
@cursorkeys if you're measuring the elapsed time using a busy loop on an embedded processor that's solely dedicated to running your loop, the number of times your loop executes will be directly proportional to the elapsed time. Just increment a counter inside the loop.
-
@anotherusername said in PSA: don't use TI-nspire calculators for encryption:
@cursorkeys if you're measuring the elapsed time using a busy loop on an embedded processor that's solely dedicated to running your loop, the number of times your loop executes will be directly proportional to the elapsed time. Just increment a counter inside the loop.
Absolutely, although that can be inaccurate on some µPs. On the PIC32, for instance, DMA to FLASH will cause a core stall when it writes, so if you're doing lots of DMA the core 'speed' seen by that loop will be variable even if the execution time for the instructions in that loop is static. That was to see, I had a bog standard super-loop program and was toggling a pin at the start of the loop, the period varied when the I2C bus received.
On an old Holtek micro I had to have single-cycle accuracy for some radio stuff, every single execution path had to charted and then padded with NOPs to get all branches the same length.
I love embedded stuff, never boring if you have to fight both hardware and software to the death on a project.