grempe
Joined 12 years ago
Karma
4
Submissions
6
Member since
Nov 6
[ my public key: https://keybase.io/grempe; my proof: https://keybase.io/grempe/sigs/JOOCuZy2VSmPxEsL1WNacocfedZfnqCIhJHp5ad0KYA ]
View on Hacker NewsRecent submissions
Comment · 1 year ago
Isn't the authentication unidirectional? Alice can confirm its Bob, or Bob can confirm its Alice, but they can't both be sure they are talking to the real person.
"Malice" could ask Bob for his code, and lie about it matching (or maybe Malice has no code at all and is pretending to match), lulling Bob into thinking that authentication was successful based on taking Malice's word for it.
Seems like you would need two codes for mutual authentication. One for Alice to Bob, and one for Bob to Alice.
Comment · 9 years ago
At Tierion, we think the inclusion of the NIST Beacon in every Chainpoint 3.0 proof we generate is a powerful feature.
We announced that we had started including the Beacon in our new proofs at Consensus in May. The first of its kind.
https://tierion.com/blog/chainpoint-innovations-in-blockchai...
Its also featured in our white paper if you'd like to read more about how we're using it.
https://tokensale.tierion.com/whitepaper
Tierion has been collaborating with the leader of the Random Beacon project at NIST and we've been providing feedback on their new release, expected this summer.
Every Chainpoint 3.0 proof has the most current available NIST timestamp and its associated random value merged into the proof directly, allowing easy manual audit and cross-check. This is in addition to server NTP time in the form of a v1 UUID, which contains both a timestamp and randomness.
We also include the NIST Beacon in a new Calendar block every time it is updated so our Calendar blocks can have enhanced temporal anchoring, even in the absence of aggregated Merkle roots being anchored to the Calendar.
We've thought for a while that the NIST Beacon it pretty cool and we're glad to see others coming around to the idea as well.
Comment · 11 years ago
As a follow up. Today I have removed zxcvbn in favor of what I believe to be a much more accurate custom entropy calculator (which also calculates out crack time based on a trillion key/second crack attempt, which is what Snowden estimates NSA is capable of at a minimum). Since this is working directly off of the known entropy of every Diceware word it gives a much more realistic estimate. At this point the extra download weight of zxcvbn was no longer worth it and the results are more interesting now as well. Cheers.
Comment · 11 years ago
@Tomte, thanks for the comment. I agree with your points and I updated the code today to more prominently reflect the actual entropy in a Diceware password (accounting also for standard diceware word and special chars that are manually added and add less entropy). I am calculating out the full Math.log2() value as well, not using the shorter estimate (e.g. 12.9/word). I also modified the zxcvbn and FAQ text to reflect that zxcvbn is likely overestimating entropy since it is expecting more traditional passwords and is not aware that it is calculating a diceware password. I think it is still helpful to show the zxcvbn output since it, or something like it, is likely to be used to estimate password strength on websites. Thanks for the feedback. Let me know if you have any other comments.
Cheers,
Glenn
Comment · 11 years ago
I am the author. The source code for this is available at:
https://github.com/grempe/diceware
Any bug reports are welcome.
This was a weekend project that was forked from a project that I thought was nicely done but needed some improvements (https://github.com/yesiamben/diceware). Notably that project:
- uses the JavaScript Math.random() API which is known to not be cryptographically secure. - is not served over an HTTPS connection. - requires re-download of all files to change language. - tracks all page views with Google Analytics - leaked information about the users preferred language via a URL query string parameter. - used inline script tags which make it incompatible with lockdown via a Content Security Policy.
So I remedied all of these issues and re-factored and modernized the code. The source of randomness is now the well supported window.crypto.getRandomValues() API which is cryptographically secure. It now also uses a fully Bootstrap based UI and provides password strength feedback using the excellent zxcvbn library from Dropbox (https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-pass...). The application will now also fully work offline (including language switches). All of the code is signed (keybase.io GPG SIGNED.md) and can be verified and run locally by cloning the repository.
I hope you enjoy this. I submitted a pull request to the upstream repository as well but I have not heard back anything to date.