Jump to content

nikb

Ripple Employee
  • Content Count

    916
  • Joined

  • Last visited

  • Days Won

    23

nikb last won the day on November 27 2017

nikb had the most liked content!

About nikb

  • Rank
    Advanced

Contact Methods

  • Website URL
    https://ripple.com

Profile Information

  • Gender
    Male
  • Location
    Las Vegas, NV
  • Occupation
    Software Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The new site is editable on GitHub! Why not get the “About” page started?
  2. Uhm... what? Assuming a brute force attack is the most efficient way, then if you had a trillion computers, each capable of testing 1 trillion keys per second, it would (on average) take them almost 6 million years to find the key. Don’t hold your breath.
  3. I believe you. Why not implement that and show us all just how easy?
  4. Are you sure that’s practical/possible? Are you offering to write a patch to enable this?
  5. Your whole post is just a thinly veiled attempt to insinuate (though I’m not sure to what end) and it sickens me. What does Tiffany’s or my personal life have any bearing or relevance? Why should my employment status have any kind of impact on Tiffany and her ability to operate a server or limit the things she can experiment with, like and/or support? And as for David’s comments, I share his point of view and I see nothing strange about them.
  6. I’m going to check the testnet API service; thanks.
  7. 🙄 A PR for this issue has already been merged. When the 1.3.0 release is ready and ships, it will be up to the validator operators to decide how to handle this issue by voting for or against the amendment that is gating the changes in that PR. The message for the commit says: Disallow using the master key as the regular key: The XRP Ledger allows an account to authorize a secondary key pair, called a regular key pair, to sign future transactions, while keeping the master key pair offline. The regular key pair can be changed as often as desired, without requiring other changes on the account. If merged, this commit corrects a minor technical flaw which would allow an account holder to specify the master key as the account's new regular key. The change is controlled by the `fixMasterKeyAsRegularKey` amendment which, if enabled, will: 1. Prevent specifying an account's master key as the account's regular key. 2. Prevent the "Disable Master Key" flag from incorrectly affecting regular keys.
  8. Does this help? https://developers.ripple.com/ledger-data-formats.html
  9. Ah, thanks. I haven’t been keeping up with BIP151, so good to know it was withdrawn before I coded up an implementation! I remember this issue, and we may tackle it going forward; it would certainly make it easier to connect. If someone external gets to it first, all the better. As for versioning, my goal is to start using the “Protocol” header in the HTTP upgrade to negotiate that better.
  10. I’d like to migrate away from that and use TLS 1.3 functionality. Alternatively, perhaps we can eschew TLS altogether for peer to peer use, opting to adopt BIP-151 instead. Although, we’d still need TLS for user endpoints, so it’s not like we’d remove a dependency.
  11. Several times I've struggled to explain XRP Ledger concepts to others, only to have @TiffanyHayden come up with a brilliant explanation in 140 or 280 characters. Her ability to communicate effectively is second to none.
  12. Honestly, I think that the existing generation scheme is a pain, and the way we conflate the 'seed' with a 'secret' (as Wietse points out) is a problem. My preference would be to define a new mechanism encode the key generation parameters. I came up with a new way of representing a seed, which encoded both the type (Ed25519 or secp256k1) and was more "user friendly". Here's an example 128-bit secp256k1 seed in my new encoding: 002992-186054-564520-197527-479336-662101-018205-239030-454003 Here's an example 256-bit Ed25519 seed in my new encoding: 005984-207295-416900-415811-559911-544368-575157-236995-404965-416339-352957-496848-476597-518793-247610-248468 Advantages of this format: It's only numbers! More universal than English, easier to write and less prone to mess up! Each 6 digit group has a check digit. If you make a typo in a group, you know which group the typo was in. The obvious disadvantage: WTF IS THIS?! IT DOESN'T LOOK WHAT I'VE USING UNTIL NOW!
  13. I want to start with a cryptography comment on your implementation: I'd strongly caution you against deriving a key directly from a seed using a single SHA-256 operation. Doing that leaves your users vulnerable to attacks; notice how rippled doesn't just blindly hash the seed and use it as a secret key. There are ways to strengthen derivations of a key from a passphrase/password and you should use them (e.g. PBKDF2). More broadly, as @Sukrim pointed out, your key derivation isn't "standard" in that you don't derive the key from a seed in the same way as rippled does. Strictly speaking, that's fine, but it may confuse some users who expect to have the "familiar" sWhatever secret; more importantly, it makes keys generated using your script not portable which can result in lock-in. For details on how rippled derives a keypair from a 128-bit seed, check out Generator. With that said, I personally find the derivation we use to be somewhat obscure and wouldn't mind simplifying it going forward. Perhaps a "new" standard, a-la BIP-39 which would also encode the key type (secp256k1 or Ed25519 for now, but maybe more in the future) would be a good idea. Lastly, I'd be very wary of calls like SecureRandom.random_bytes(32). Maybe Ruby has a great PRNG that is cryptographically secure and does the right thing in all cases—the docs suggests it does. But you probably don't want to depend on just that. Consider additional randomness sources.
  14. What a thread to read on a Saturday night…
×
×
  • Create New...