meta user
network profile
| bio | website | people.scs.carleton.ca/~clark |
|---|---|---|
| location | Ottawa, Canada | |
| age | 32 | |
| visits | member for | 1 year, 11 months |
| seen | 21 hours ago | |
| stats | profile views | 106 |
Postdoctoral fellow interested in authentication and cryptographic voting.
|
Jul 17 |
answered | Reduction from signatures to encryption? |
|
Jul 14 |
comment |
Are there any tools for expressing the cipher operations as a system of equations? Part of the "art" of algebraic attacks is finding the appropriate field to embed the operations into. I would suspect if an automated tool were to be implemented (none to my knowledge), it wouldn't be very useful at finding "nice" representations. For example with AES, some operations are cleanly representable in GF(2) while others in GF(2^8). You can embed everything into GF(2^8) (e.g, big encryption scheme BES) but the representation gets messy. |
|
Jul 14 |
revised |
Current mathematics theory used in cryptography/coding theory added 4 characters in body |
|
Jul 13 |
comment |
How to provide secure “vanity” bitcoin address service? I see now that it is addr = (ver||RIPEMD-160(SHA-256(key)))||(SHA-256(SHA-256((ver||RIPEMD-160(SHA-256(key)))))) where ver is version and key is the public key and the second component is only the first 4 bytes. |
|
Jul 13 |
comment |
How to provide secure “vanity” bitcoin address service? I see now the link to the spec, although not a spec of the exact formatting of the ECDSA key. Addresses contain a "version" field. If this is not checked or used by the clients, you could iterate on it (maybe in addition to the share of the secret key since version is only a byte) with only the cost of the hash (instead of a point multiplication, addition, and hash) per iteration. |
|
Jul 13 |
comment |
How to provide secure “vanity” bitcoin address service? It would be possible to greatly improve the efficiency if you can find something in the preimage to tweak that does not require additional mathematical operations to be performed on it before hashing. However without an exact specification of the address generation, it is hard to say if there are any other fields or formatting that can be tweaked. |
|
Jul 13 |
comment |
How to provide secure “vanity” bitcoin address service? The article first says that addresses are simply the output of a hash, but then later says that they include some error correction which means they are not merely the output of a hash? |
|
Jul 13 |
revised |
Current mathematics theory used in cryptography/coding theory added 97 characters in body |
|
Jul 13 |
answered | Current mathematics theory used in cryptography/coding theory |
|
Jul 13 |
revised |
Replacing the Rijndael S-Box? added 205 characters in body |
|
Jul 13 |
answered | Replacing the Rijndael S-Box? |
|
Jul 13 |
awarded | Organizer |
|
Jul 13 |
revised |
Why use a 1-2 Oblivious Transfer instead of a 1 out of n Oblivious Transfer? edited tags |
|
Jul 13 |
awarded | Supporter |
|
Jul 13 |
revised |
Why use a 1-2 Oblivious Transfer instead of a 1 out of n Oblivious Transfer? added 118 characters in body |
|
Jul 13 |
revised |
Why use a 1-2 Oblivious Transfer instead of a 1 out of n Oblivious Transfer? added 478 characters in body |
|
Jul 13 |
answered | Why use a 1-2 Oblivious Transfer instead of a 1 out of n Oblivious Transfer? |
|
Jul 13 |
awarded | Editor |
|
Jul 13 |
revised |
advances in usability for cryptography/authentication edited body |
|
Jul 13 |
awarded | Teacher |
