I understand the Arduino model is different than other projects but we proudly use Arduino as it's open source and has lots of great features. As we use the Arduino model you can find that our source consists of the .ino you mentioned here https://github.com/trustcrypto/OnlyKey-Firmware as well as libraries here https://github.com/trustcrypto/libraries . Our code is reviewed by Codacy and yes, it does receive a grade…
And I am going to have to give Codacy a grade of F but if this is what they consider grade A.
As a Codacy user for $DAYJOB I can guarantee you that Codacy deserves worst than grade F.
Even if that analog pin provides a reasonable amount of entropy (which I'm skeptical of), you have a major bug: you're casting the ADC reading to a pointer, and then dereferencing it inside RNG.stir. Let me say it again: you're taking an ADC reading (in the range of 0-1023) and accessing it as if it's a memory address. To make things worse, addresses 0 through 1023 on the Kinetis you're using are the vector table. Ta…
You're right. I tried to give this code a charitable read, but it's horrifically wrong, and not just the ADC, but seemingly all inputs here. At least we now have a better sense of what an A grade from Codacy actually counts for.
To be fair to Codacy, it's not even checking the file that people are pulling all these examples of bad code from.
There are many, many keyboard layouts out there. Maybe it's time for an input standard that acknowledges this fact, instead of endlessly putting the onus on OS developers and users. Maybe keyboards should output UTF8 instead of messy keycodes.
This would require new hardware. If one is already going to be purchasing new hardware, one may as well get a QMK keyboard. This way you can program it with any keyboard layout you would like, and it will work on any computer without having to change the system defaults. Clearly this doesn't help with built-in keyboards such as found on laptops; the clear workaround for this specific product is to allow it to import…
Sadly it doesn't seem to work that way. BE/AZERTY keyboards, for instance, have a physical key that US/QWERTY keyboards do not (\). The OS will ignore that key unless it's set up to use a layout that includes the key. There is no way to program a QMK keyboard to fix that (unless you change the OS to run the BE layout), because QMK does not map keypresses to characters. It maps keypresses to keycodes, which depend on OS keyboard layouts, specifically US/QWERTY and sometes DVORAK. At least that's how I see it.
>OnlyKey has been in use for about 4 years. It has thousands of active users and is in use in over 40 countries world wide. This is not a new product, and it has a great user community which is not afraid to test, hack, and prove the security of devices. Like literally the first issue was already linked above. Using the psuedo RNG with some analog pin seed isn't really acceptable. It should have a true rng IC that ca…
Like literally the first post issue is completely incorrect, thats one of the issues in reading a post like this in an online thread, literally that user copied part of but not all of the function that is used for RNG. The part they copied uses analog input as one of the sources of entropy, they failed to also include the 6 capacitive touch inputs that are also inputs to the RNG. Those touch inputs literally change e…
Your "delay 0-6 ms" only delays 0-4 ms.
Not to mention the fact that the only obvious effect of that delay is to expose entropy information to timing analysis.
Setting aside problems with this particular device, the whole "trust the open-source hardware" model is inherently flawed. Every useful security hardware will be commoditized, then faked and/or trojaned. We can't take the open-source software approach and rely on many volunteer eyes catching vulnerabilities and backdoors. First, there just aren't enough skilled professionals capable of proper hardware review. And sec…
If someone sells you a quantum computer, there exists protocols that allow you to check if the QC is working as intended without inspecting the internals [1]. You merely have to pass some special (randomized) inputs and check the outputs.
Does anybody know what sort of verification protocols exist for classical security devices, where you can verify that the device is working as intended without inspecting the hardware?
I would like to learn more about practical cryptographic issues, and I need some help: what are the tests that can prove or disprove stronger guarantees for cryptographic security of a PRG than diehard? A wikipedia page doesn't give me much info about which one provides stronger guarantee and in which criteria: https://en.wikipedia.org/wiki/Randomness_tests Also, which level of security of a PRG is sufficient for key…
There are no automated tests for this, since cryptographic randomness requires unpredictability. A statistical test can only tell you when a random number generator is broken, but no statistical test can tell you whether a random number generator is cryptographically sound.
And so the only test is to analyse all known knowledge for any method that is capable of predicting some portion of the random numbers. If none exists, the process is "random".
I honestly don't understand how a YubiKey is supposed to help me secure my accounts if I get locked out of my accounts when I lose it. I an trivially copy a keepass database anywhere and have dozens of backups. If I want to do the same with a YubiKey I first have to buy multiple YubiKeys and then I have to register each one on each site. This means they cannot be used as a primary authentication method because they a…
how many keys to your home have you got? if you rent, how many keys does your landlord have?
home keys and yubikeys are both hardware keys and same rules apply - you absolutely should have more than one.
It is open source, not to be confused with open hardware which it is not. The hardware is transparent, literally, it has a clear protective coating on the hardware which allows visually verifying everything. For security things check out https://docs.crp.to/security.html - TL;DR Before you enter the PIN its not doing any crypto which means lots of side-channel attacks don't apply, you would have to know the PIN to ev…
> The hardware is transparent, literally, it has a clear protective coating on the hardware which allows visually verifying everything Right and that's bullshit. How do I know you aren't embedding a advanced joule thiefing silicon die disguised as a pull-up resistor to manipulate usb communication or even interface with the micro in a backdoor?
How do I know
Fair question. But it makes me wonder: what would be the accepted way to provide schematics/PCBs and prove the provided ones are also what gets used to create the actually sold hardware? Same question for the source code actually.