Kind of related is DiceKeys, with 192 bit security: https://www.crowdsupply.com/dicekeys/dicekeys
I must be missing something here, there are 25 unique dice that can be permuted, each can have six potential sides showing, and 4 potential orientations of the displayed face... So (25!)×(25×6×4) ? Isn't that more like only 93 bits?
Well obviously harder to scan from a phone, I think a deck of playing cards would be easier to acquire and store. Shuffling 27 would give you 93 bits, shuffling the full 52 would be ~226.
Still, I wonder if a similar thing could be done by shuffling a deck of cards, and then riffling the results past a good camera so that an app can recognize the sequence in order. Perhaps it would be vulnerable to common shuffling mistakes?
Just because a paper is published doesn't mean it wasn't done for fun/the hell of it.
There are multiple ways to solve the cube, if orientation of the center pieces is made visible and significant.
Couldn't you "just" use a webcam to scan any particular cube? Seems like you could "easily" detect when you've seen all 6 unique faces and there should be libraries around that will read cubes.
If you are the author could you link to a copy of the paper?
A admit I'm dumb and lazy - I didn't read the paper, maybe it's covered there - but this sounds quite vulnerable to dictionary attacks, like those phone unlock paass where everybody puts a Z, the cube-keys will mostly be "Solved with red/yellow middles swapped"
But, the way I see it, you have the traditionally "solved" state cube on your desk(all faces complete), and when you want to use it as a key you "solve" the cube to the state that represents your key.
With a rubiks cube this means you only need to remember the steps of the algorithm that leads you to your key state.