I think entropy from mouse is needed for javascript (like wesley client) -- not for Java's SecureRandom
As for words, as I said, don't use cryptic words from diceware. 1626 simple words dictionary will just work fine for 128-bit entropy.
Actually, newest browsers have crypto.getRandomValues - so no mouse movement needed in those cases. Of course still necessary for older browsers. Well, even if it is not technically necessary for most of the browsers, we should use the mouse movement because 1. With this, we make sure every user (no matter which browser) has a secure account (using mouse movement only on older browsers gives no common picture of the client on every computer. looks insecure) 2. It gives a secure feeling because the user is part of the process Hmm, anyone else's input on this? I believe relying on system cryptography is always better than having the user doing something (mouse movement). It will be available though, for older browsers. Its not really needed if cryptographically secure number generator is available, but it won't really hurt. It will just add more entropy if you start with crypto gen and the user adds more entropy with mouse movements. |
|
|
|
What does your implementation of words.getDiceWd look like?
It picks directly from an array of words. Why? How do you map the integer type parameter down to the range of items in the dictionary? int & 0X1fff returns a value between 0 (inclusive) and 8191 (inclusive) This is like a modulo operation right? Like "(int mod 8192)". If so, it puts a (very) slight preference on the first entries in the dictionary. I don't have a cryptographic background, but it seems like one of these tiny things cryptographic people look for. Or it's just me being paranoid.. I think the simplest way to do it is to just generate a 128-bit random number, then represent ('convert") it to to base 1626 (1626 word dictionary). |
|
|
|
I imagine a passphrase generator integrated in Nxt clients, similar to the one used in Electrum client for Bitcoin, with state of the art random generator and possibly a larger dictionary (Electrum uses 1600 words).
Hi, I really like your idea and wan't to implement that in Offspring (actually already did that with the Eglish list). It seems there are lists of words for most languages http://world.std.com/~reinhold/diceware.html available. I would like some input on the algorithm to combine the words and if and how to generate entropy with the mouse. It does for sure look really interesting to the average user (moving your mouse around to generate a password) but does it make a difference in the case of Curve25519 between doing that and using SecureRandom? Also great care is put into correctly providing a seed to the PRNG in SecureRandom and you are warned against providing your own seed (which is basically what you do when you move your mouse around and call SecureRendom.setSeed([MOUSE MOVEMENT ENTROPY]) ), so what is more secure? Default (and optimized) SecureRandom or SecureRandom with mouse movement as seed? DiceWords words = new DiceWords();
SecureRandom rand = SecureRandom.getInstance("SHA1PRNG", "SUN");
byte[] bytes = new byte[8];
rand.nextBytes(bytes); // initialize seed
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 12; i++) {
String word = words.getDiceWd(rand.nextInt());
sb.append(word).append(' ');
}
sb.deleteCharAt(sb.length() - 1);
String passphrase = sb.toString();
Edit: changed the algorithm to explicitly use SHA1PRNG instead of the platform default, call to nextBytes is to force PRNG to seed itself securely If you are using Java's SecureRandom, you don't need entropy from mouse. SecureRandom uses /dev/random on Linux and probably CryptGenRandom on Windows. The entropy comes from hardware, things like http://en.wikipedia.org/wiki/CryptGenRandomThe current process ID (GetCurrentProcessID).
The current thread ID (GetCurrentThreadID).
The tick count since boot time (GetTickCount).
The current time (GetLocalTime).
Various high-precision performance counters (QueryPerformanceCounter).
An MD4 hash of the user's environment block, which includes username, computer name, and search path. [...]
High-precision internal CPU counters, such as RDTSC, RDMSR, RDPMC
[omitted: long lists of low-level system information fields and performance counters] Source: Writing Secure Code, Second Edition. ISBN 0-7356-1722-8.
I think entropy from mouse is needed for javascript (like wesleyh client) -- not for Java's SecureRandom As for words, as I said, don't use cryptic words from diceware. 1626 simple words dictionary will just work fine for 128-bit entropy. |
|
|
|
Will do (diceware first).
Why bother with diceware? Pick easy word dictionary so it's easy to remember and type. Use Electrum dictionary https://raw.github.com/spesmilo/electrum/master/lib/mnemonic.pyBy the way, you don't need more than 1626 words to get 128-bit entropy with 12 words, so words should be short and easy to type and remember |
|
|
|
|
Did mintpal refund people the money?
Demand your money back if you paid them for listing Nxt
|
|
|
|
If your password is halfway decent maybe it takes them a couple of years to break it
If your password is random 128-bit (around 22 characters with A-Z, a-z and --0-9 characters), it can't be brute forced, not in 2 years, not in 2 billion years what about a 30 character memorizable brain wallet with some randomness and weirdness thrown in? Example: this sentence i am using for an example of a kickass passwordthiSsentenceIaMusingforAnexampleOfaKickAsspAsswordthiSsent44enceIaMusingforAnexa-))mpleOfaKickAsspAssword!How secure is something like the above? That's fine. If the phrase is not "googlable" (i.e not a quote from a book /song etc) and it has 128-bit entropy, it can't be brute forced -- even if you don't misspell the words or do anything weird to it. If you have a dictionary with only 1626 words, and you randomly pick 12 words from the dictionary, it should be fine even if the words are correctly spelled with no caps or special characters. like this: "study build beard problem praise keep horrible mark nice month day student" If these 12 words were randomly picked from 1626 word dictionary, that is 128-bit entropy. 1626^12 = 3.4154387002817342781797097590636e+38 2^128 = 3.4028236692093846346337460743177e+38 By the way, Curve25519 only offers 128-bit security, so choosing a password stronger than 128-bit doesn't really do anything. If the attacker can break 128-bit password, he might just as well break Curve25519 |
|
|
|
If your password is halfway decent maybe it takes them a couple of years to break it
If your password is random 128-bit (around 22 characters with A-Z, a-z and --0-9 characters), it can't be brute forced, not in 2 years, not in 2 billion years |
|
|
|
This is misleading. Ripple evolved since 2004. It's dishonest to claim Ripple of today has anything to do with Ripple of 2004. Ripple as we know it today is NOT older than Bitcoin. The real date is 2012 when Open Coin was founded. |
|
|
|
There is no evidence Nxt is ever going to implement zerocoin. It's incompatible with 1000 TF Zerocoin has a number of serious limitations: - It uses cutting-edge cryptography which may turn out to be insecure, and which is understood by relatively few people (compared to ECDSA, for example). - It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage). - It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto.) - Validation is very slow (can process about 2tx per second on a fast CPU), which is a major barrier to deployment in Bitcoin as each full node must validate every transaction. - The large transactions and slow validation also means costly transactions, which will reduce the anonymity set size and potentially make ZC usage unavailable to random members of the public who are merely casually concerned about their privacy. - Uses an accumulator which grows forever and has no pruning. In practice this means we'd need to switch accumulators periodically to reduce the working set size, reducing the anonymity set size. And potentially creating big UTXO bloat problems if the horizon on an accumulator isn't set in advance. parallel blockchains would make it possible In other words, it's complete fiction right now with no evidence that anyone is even working on it to implement on Nxt and how it's going to be implemented. Not only there is no code, but how it will be implemented is unclear speculation. Plus there is no evidence it will work. We should stop making Youtube videos about Nxt having zerocoin "feature" as if it's implemented working feature. . salsacz delete your youtube video immediatly. |
|
|
|
If zerocoin/mixing is only an option for those who want to use it and do not become the standard of nxt core, then i see no problem. It would be the best of the two world. I just hope that zerocoin/mixing will simply be a layer on top of nxt for which user will have the choice to use it or not. Legal business will then simply not use the zerocoin/mixing functions.
I would like to see Zerocoin on its own chain, but doing so likely does have the drawback of making it easier to correlate users with transactions. Still, I'd rather it be optional. Once again, where is the evidence Zerocoin is being implemented with Nxt? Where is the code? Who is the Nxt developer writing the code? How do you resolve the problems mentioned in this post? https://bitcointalk.org/index.php?topic=279249Zerocoin has a number of serious limitations:
- It uses cutting-edge cryptography which may turn out to be insecure, and which is understood by relatively few people (compared to ECDSA, for example).
- It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage).
- It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto.)
- Validation is very slow (can process about 2tx per second on a fast CPU), which is a major barrier to deployment in Bitcoin as each full node must validate every transaction.
- The large transactions and slow validation also means costly transactions, which will reduce the anonymity set size and potentially make ZC usage unavailable to random members of the public who are merely casually concerned about their privacy.
- Uses an accumulator which grows forever and has no pruning. In practice this means we'd need to switch accumulators periodically to reduce the working set size, reducing the anonymity set size. And potentially creating big UTXO bloat problems if the horizon on an accumulator isn't set in advance. |
|
|
|
There is no evidence Nxt is ever going to implement zerocoin. It's incompatible with 1000 TF Zerocoin has a number of serious limitations: - It uses cutting-edge cryptography which may turn out to be insecure, and which is understood by relatively few people (compared to ECDSA, for example). - It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage). - It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto.) - Validation is very slow (can process about 2tx per second on a fast CPU), which is a major barrier to deployment in Bitcoin as each full node must validate every transaction. - The large transactions and slow validation also means costly transactions, which will reduce the anonymity set size and potentially make ZC usage unavailable to random members of the public who are merely casually concerned about their privacy. - Uses an accumulator which grows forever and has no pruning. In practice this means we'd need to switch accumulators periodically to reduce the working set size, reducing the anonymity set size. And potentially creating big UTXO bloat problems if the horizon on an accumulator isn't set in advance. |
|
|
|
Weren't you supposed to sell your 100 million NXT a couple weeks ago? busy with that. you retards do not seem to understand it take alot of work and time to sell 100M specialy when noone is interested to buy. market is so thin i would kill nxt over and over and scare every one away (that would make me the bagholder) it will take months to sell all unless i dump 50 to 60 times but than price will go to zero every time I don't see any NXT moving out of the large accounts. What's your account number? Why the fuck do you keep responding to him? It's well known the guy doesn't own more than few thousand Nxt Move on |
|
|
|
It depends on how much currency they control. NXT is currently susceptible to 51% currency attacks because TF isn't fully implemented yet. If someone is able to control 51% of the currency currently forging, they can attack NXT.
The probability that someone is going to buy that many Nxt (51%) then attack the network destroying his own wealth is close to zero. And what happens to Nxt prices if someone starts buying that many Nxt? It will cost much more than the current 0.05 cents to get to 51% It's just theoretical possibility but really irrelevant concern. |
|
|
|
Usability is KING! A visitor of Nextcoin.org tells about his experience and why Nxt is difficult to use for newbees. I totally agree with him, usability is more important than futuristic features. How can we solve this problem? https://nextcoin.org/index.php/topic,4339.new.html It can be resolved by integrating wesleyh client with NRS and distributing it as simple executable application. Or just use Marcus3 client that works without local copy of NRS I have got some questions again from users at twitter how they can install the client. And how to install it on Mac. If I got instructions etc. That is problem number 1. But we are working on it with Wesleyhs client. Integrating with the NRS client. But we have also a big second problem like the other forum describes. Passwords. Are we working on that either? The usability of the client is the third problem. But we can fix that over time with instruction videos etc. The first two problems we have to think and fix ASAP! All clients should have password management system. The client should generate cryptographically secure passwords and save them on hard disk in wallet.dat encrypted with AES. The user provides the password for encryption and that password doesn't need to be that strong. I have said that many times before. Nxt is insecure for general public without password management implemented within client. |
|
|
|
NXT as far as I understand it needs a larger percentage of it's userbase to be forging than bitcoin does or the network will be insecure.
Why? That doesn't even make sense. I have been told by others here that this is the case. Think about it. If small holders don't need to be forging, why even ask them to? Don't even make forging a selling point and just let the whales forge and protect their own network. I'm pretty sure that won't work, therefore it is a big problem that no one is taking seriously. Where is that "big" problem? I still don't gt it. Why 100 to 500 forging accounts shouldn't be enough to secure the network? |
|
|
|
NXT as far as I understand it needs a larger percentage of it's userbase to be forging than bitcoin does or the network will be insecure.
Why? That doesn't even make sense. |
|
|
|
Usability is KING! A visitor of Nextcoin.org tells about his experience and why Nxt is difficult to use for newbees. I totally agree with him, usability is more important than futuristic features. How can we solve this problem? https://nextcoin.org/index.php/topic,4339.new.html It can be resolved by integrating wesleyh client with NRS and distributing it as simple executable application. Or just use Marcus3 client that works without local copy of NRS |
|
|
|
Girls 'n boys,
I don't know why until now there exists no Wikipedia-Article about NXT in the main Wikipedias (English, German, Netherlands, Swedish, etc.)?
Wikipedia deleted the article as they considered Nxt insignificant. Don't repost the article again or it will be just deleted again. We first need to promote Nxt outside Wikipedia in mainstream media, and implement major announced features. looool - WikiStupopedia also tries to tell you that there were nookuular WMD in Iraq  Whatever. Wikipedia is the greatest thing since slice bread -- and no that's isn't sarcasm. I really mean it. |
|
|
|
The name is Nxt, not Nxtcoin and as I said please don't repost it on Wikipedia. This is absolutely against Wikipedia policy. Wikipedia should not be used to promote yourself. I hope the article gets deleted soon. Nxt should be promoted in mainstream media. It needs to become notable. Once that is done, it will show up in Wikipedia -- without you doing anything. I hate when Wikipedia is abused for self promotion |
|
|
|
Girls 'n boys,
I don't know why until now there exists no Wikipedia-Article about NXT in the main Wikipedias (English, German, Netherlands, Swedish, etc.)?
Wikipedia deleted the article as they considered Nxt insignificant. Don't repost the article again or it will be just deleted again. We first need to promote Nxt outside Wikipedia in mainstream media, and implement major announced features. |
|
|
|
|
Show Posts
