20,038 reputation
32371
bio website
location
age
visits member for 3 years
seen 11 hours ago

Jun
21
comment Pseudo Random Generator with fixed Hamming Weight
Use the output of a crypto-quality PRG as your seed. Done. Yes, it'll be secure if the PRG is secure.
Jun
21
comment Pseudo Random Generator with fixed Hamming Weight
As it stands this question does not meet my quality expectations for this site. In the future please explain in greater detail what you want (e.g., what your specific requirements are), explain the context/motivation, do some research on your own, and show us what research you have done and what you have tried and where you got stuck. And pick just one question: a block cipher is very different from a PRG. P.S. What you want is obviously impossible if the length of the output is equal to the length of the input, as in your example.
Jun
20
comment Public and private key lengths
Thanks, BENZ.404! No need to acknowledge me or worry about my comment; I'll be happy to delete it once it no longer makes sense. For padding, normally we'd expect the library to do whatever is needed to make key generation secure. (For what it's worth, no padding is needed during RSA key generation, and depending upon how the private key is represented, it will often be of different length than the public key.)
Jun
20
comment Could scrypt salts contribute to entropy if passwords & salts are only stored in human memory?
@Gracchus, I'm going to give you some advice that might sound nasty, but I mean it in the best possible way: I don't think you should be designing cryptocurrency wallet software at this stage. This crypto stuff is subtle, and if you get it wrong, people could lose money. This kind of approach to design of cryptocurrency software is the sort of thing that causes people to lose money. It's exactly this sort of "let's just throw together some code and hope it works" that has caused multiple Bitcoin exchanges to lose lots of money. (For instance, there's a reason why we use a salt.)
Jun
20
comment Public and private key lengths
I still don't understand what you are trying to achieve. Why are you contemplating adding padding? What problem are you trying to solve? Why is the standard output problematic or unacceptable? What are your requirements? Also, when editing, please make sure the edited question stands on its own (don't add "edit: never mind this part", just delete the part that isn't relevant, and make it a good question on its own). We have a revision history, so you don't need to preserve prior versions. Make it something that'll be a great question for someone who encounters this for the first time.
Jun
20
comment Could scrypt salts contribute to entropy if passwords & salts are only stored in human memory?
Sorry, @Gracchus, I'm totally lost at what you are trying to do. How does login work? Are we talking about a system where the server stores a scrypt hash of the user's passphrase, or not? If not, what is the situation? The question is not very clear on how you plan to use scrypt. Are you talking about a system where a scrypt hash of the user's passphrase is used to seed a crypto-PRNG which is then used to generate their private/public keypair? If so, that has is about key generation, not login. I suggest you edit the question to make the application a lot clearer.
Jun
20
comment Ballot box with multiple parties. All can read it, or none can read it
@RickyDemer, yes, that's another possible problem if you do it wrong, but that one is easy to solve with standard methods (there are many standard schemes for non-malleable commitments). The issue I described is the harder one and the core of challenge, as far as I can see.
Jun
20
comment Could scrypt salts contribute to entropy if passwords & salts are only stored in human memory?
@Gracchus, why can't it be retrieved later? What prevents you from storing a salt together with the password hash? If you can store a password hash, why can't you store a random salt, too, in the same place (e.g., in the same database)? If you're not storing a password hash, what are you doing with the output of scrypt and what do you mean by a cryptocurrency login?
Jun
20
comment Could scrypt salts contribute to entropy if passwords & salts are only stored in human memory?
Why do you want to do this, as opposed to the standard approach of generating a random salt and storing it with the password hash? Is there an application where you think this will be preferable? There might be a better solution, but we'd need to know the context in which this question arises to determine that.
Jun
20
comment key-exchange with websockets in node.js
I find it hard to understand what you are asking. Are you asking about how to do key exchange? If so, have you read standard textbook and other descriptions of key exchange protocols, public key cryptography, PKI, and key management? I suggest you do a little more reading on crypto, then see if you can ask a clearer question.
Jun
20
comment Public and private key lengths
What are you trying to achieve? What problem are you trying to solve? What's wrong with leaving that there? It is part of the standard format: see PGP and OpenPGP.
Jun
18
comment LFSR and Markov chain question
I don't understand in what sense the Berlekamp-Massey algorithm is an algorithm for "this problem" - what problem? Please try to be more precise. Berlekamp-Massey has nothing to do with Markov chains; it has to do with recovering the LFSR initial fill and feedback polynomial, given observations of its output. As far as your last question in your comment: for what task? what Markov chain formulation? It's impossible to say what resources are needed, if we don't know what the task is. Again, LFSRs are a deterministic process, so modelling it as a Markov chain is not very helpful.
Jun
18
comment LFSR and Markov chain question
I find this question unclear. What do you have in mind as the statespace of the Markov chain? If the state is the entire state of the LFSR, then of course there is a trivial Markov chain, since it is a deterministic process, but this does not seem likely to be useful. So what did you have in mind? Let me put it another way. Why do you ask this question? What's the motivation or context where you plan to use this? How will you evaluate or use answers? As it stands the question seems a bit on the open-ended/ill-defined end.
Jun
18
comment Length-preserving all-or-nothing transform
@fgrieu, actually, I think you have it backwards. For large size, it is straightforward (in the random oracle), as explained in the section "Theoretical perspective": use a cryptographic hash function as the F-function of a 6-round Feistel network. I actually think the more challenging case is to do it for small block size, not large block size.
Jun
18
comment Authenticated encryption without padding
@RickyDemer, I've updated my answer to provide a construction that you might like better. If provable security is a goal, a better construction is likely to be $E_{k_2} \circ P \circ E_{k_1}$ where $P$ is a public random permutation and $E$ is a length-preserving encryption scheme. (Then even in the case where $E$ is merely xor with a constant, i.e., $E_k(x)=k \oplus x$, then it can still be proven to provide reasonable security, as this devolves to the Even-Mansour construction, which offers provable security guarantees.)
Jun
18
comment Can the premaster secret generated by SRP be used as a secure private key?
I recommend that you state the question you want answered in the body of the question.
Jun
18
comment SHA1 collision event probability after n iterations
Did you look at crypto.stackexchange.com/q/15068/351 ? (Did you remember to use search before asking?)
Jun
18
comment SHA1 collision event probability after n iterations
What do you think? What have you tried? Where did you get stuck? Where did you run into this question? What is the context/motivation for your question? This is not a site where you copy-paste your exercise and we do your exercise for you.
Jun
18
comment What are good combinations of public key algorithms or primitives for long term security?
I wouldn't recommend lattice-based methods at this point in time, for long-term security; they haven't been studied in as much detail as others. It wouldn't be shocking if someone discovered a new attack 10 years from now that breaks them significantly faster than we currently know how to.
Jun
11
comment Does this protocol provide Perfect Forward Secrecy / are there potential security flaws?
Please make sure to provide a specific technical question in the body of the question. The title is for, well, a title -- and does not replace to need to ask a specific question in the body of the question.