GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Notices by varx/tech (varx@infosec.exchange), page 2

  1. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Sunday, 21-Jan-2024 08:14:18 JST varx/tech varx/tech
    in reply to
    • Very Human Robot

    @StompyRobot ...pretty sure they just needed someone to look at the logs.

    In conversation Sunday, 21-Jan-2024 08:14:18 JST from infosec.exchange permalink
  2. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Monday, 15-Jan-2024 09:47:44 JST varx/tech varx/tech
    in reply to
    • feld

    @feld Nope, just stuck into the README next to the "This project is licensed under the GPL". (Editing the GPL would be a different kettle of fish, yeah...)

    In conversation Monday, 15-Jan-2024 09:47:44 JST from infosec.exchange permalink
  3. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Monday, 15-Jan-2024 09:37:10 JST varx/tech varx/tech

    Software licensing question, semi-hypothetical:

    I encountered a repo available under the GPL, *but* there's also a note about "you can't sell this". This... isn't actually compatible with the GPL, and reveals the author's poor understanding of the license they chose. It doesn't matter for me, because I'm not planning on selling it, but it does raise an interesting question: What is the most likely *effect* of this statement?

    - License grant is invalid?
    - GPL prevails entirely?
    - No-sale applies to original work, but not to derivatives?

    I'm leaning towards the first one, myself. Curious to hear what others think.

    In conversation Monday, 15-Jan-2024 09:37:10 JST from infosec.exchange permalink
  4. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Wednesday, 05-Jul-2023 12:40:55 JST varx/tech varx/tech
    in reply to
    • Jeff Martin

    @cuchaz Cavern has a problem that's very similar; my solution is for the friends to have to brute-force the list until they find something they can decrypt, but not have to do this *often*.

    Not sure if this is appropriate in your use-case, but consider whether there's a way to "stabilize" the numbers you're sending your friends; if they can act optimistically on the presumption of the number not having changed since last time (if that's even a meaningful concept) then they get to skip the expensive step whenever they're right.

    Barring that, it feels like this might require some fancy math involving combining multiple people's public keys. :-/

    In conversation Wednesday, 05-Jul-2023 12:40:55 JST from infosec.exchange permalink
  5. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Wednesday, 05-Jul-2023 12:40:51 JST varx/tech varx/tech
    in reply to
    • Jeff Martin

    @cuchaz It's also pretty fast. The marginal cost on my 10+ year old laptop of performing an encryption or decryption is less than 80 µs. "Brute forcing" a list of 1000 small items until I find the one that's for me would take under 100 ms, which seems fine.

    40k items would take about 3 seconds to process. At that scale I'd want to start using k-anonymity for sure; including just an 8-bit public key prefix would bring that down to 12 ms.

    In conversation Wednesday, 05-Jul-2023 12:40:51 JST from infosec.exchange permalink
  6. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Wednesday, 05-Jul-2023 12:40:49 JST varx/tech varx/tech
    in reply to
    • Jeff Martin

    @cuchaz Another benefit is that keys are small and unstructured. Any 32 byte string can be converted to a key via some bit-masking—you create them from random data (or a hash output). So the keys are fast and simple to generate, they're small, and they can be readily derived deterministically from a passphrase if you're into that sort of thing. (And if you have both X25519 and Ed25519 keys, they can both come from the same shared seed, with a bit of context separation for safety.)

    In conversation Wednesday, 05-Jul-2023 12:40:49 JST from infosec.exchange permalink
  7. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Wednesday, 05-Jul-2023 12:40:46 JST varx/tech varx/tech
    in reply to
    • Jeff Martin

    @cuchaz There's some truth to that. For instance, the top post-quantum schemes seem to have pretty large keys, which might violate some protocol assumptions.

    But they also might just work really differently in ways that don't match either RSA *or* ECC. Think of how ECC relies on key exchange rather than RSA's traditional asymmetric encryption, and doesn't have a notion of unifying encryption and signing. It seems to me there's a not-inconsiderable chance of further fundamental changes in the available primitives. Without being a serious cryptographer (let alone one who is up-to-date and has an eye for trends) it's impossible for me to make that kind of prognostication, though! I think keeping an eye on later versions of the protocol being able to swap out cryptosystems at a lower level makes sense, but I feel like it would be easy to unduly constrain the overall protocol.

    (That said, all of the round-4 NIST PQ submissions appear to describe KEMs, making them more similar in shape to public-key ECC than to RSA, if I'm not totally misunderstanding things.)

    In conversation Wednesday, 05-Jul-2023 12:40:46 JST from infosec.exchange permalink
  8. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Tuesday, 27-Jun-2023 00:05:40 JST varx/tech varx/tech
    in reply to

    OK, here we go: A way to inject a string value inside a #YAML string in #Helm chart templates!

    You won't like this.

    "... {{ $someValue | quote | substr 1 (int (sub ($someValue | quote | len) 1)) }} ..."

    I promise you that this is one of *less* terrible ways of performing this extremely fundamental operation.

    EDIT: Good news! I've golfed it down to just two function calls:

    "... {{ regexReplaceAll "^\"|\"$" (quote $someValue) "" }} ..."

    This quotes and escapes the value, then uses a regex to remove just the beginning and ending quote, and finally interpolates it into the larger double-quoted flow scalar.

    In conversation Tuesday, 27-Jun-2023 00:05:40 JST from infosec.exchange permalink
  9. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Tuesday, 27-Jun-2023 00:05:39 JST varx/tech varx/tech
    in reply to

    #YAML is endless fun.

    In conversation Tuesday, 27-Jun-2023 00:05:39 JST from infosec.exchange permalink

    Attachments


    1. https://media.infosec.exchange/infosecmediaeu/media_attachments/files/110/610/867/349/174/778/original/339ba6a992e688cf.png
  10. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Friday, 23-Jun-2023 01:41:05 JST varx/tech varx/tech
    in reply to
    • feld

    @feld Yeah, but the templating language also doesn't give you a way to interpolate into a JSON string. :-/

    In conversation Friday, 23-Jun-2023 01:41:05 JST from infosec.exchange permalink
  11. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Friday, 23-Jun-2023 01:38:35 JST varx/tech varx/tech

    Today I have experienced the horror that is #Helm.

    Helm chart templates make #Kubernetes manifests by string-templating #YAML.

    YAML has one of the most unfriendly syntaxes of any textual data structure language I've ever seen. There's a whole website just dedicated to the nine different ways you can write a multiline string.

    And Helm just... string-interpolates values into it. The most fragile syntax in the world, and you're just going to inject raw bytes straight into it. The only tool provided to alleviate this is the `quote` function, which... doesn't actually do what you want.

    Currently at work I'm trying to figure out how to insert an arbitrary string value into another string, which is a pretty normal thing to do. And four attempts later, nothing works. The most common "solution" on the web appears to be to use `{{ ... | indent 12 }}` where 12 has to match the template's current indentation level. Good luck if you ever want to reindent anything!

    In conversation Friday, 23-Jun-2023 01:38:35 JST from infosec.exchange permalink
  12. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Wednesday, 26-Apr-2023 20:53:19 JST varx/tech varx/tech
    in reply to
    • lopta

    @lopta I reset my password using the "compromised account" feature, since it just took a moment. Little to lose. However... I'm not convinced yet that there's a legitimate threat, so I haven't done anything beyond that.

    (I don't use 2FA with Amazon because their 2FA support kind of sucks, and I don't have any "devices".)

    It's easy for people to think they've found something serious and be dead wrong about it. I know this from the perspective both of someone who has raised a false alarm, and of someone who has to field security disclosures. So I'm holding this with some uncertainty, and I figure we'll know soon enough.

    In conversation Wednesday, 26-Apr-2023 20:53:19 JST from infosec.exchange permalink
  13. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Wednesday, 26-Apr-2023 20:35:55 JST varx/tech varx/tech
    in reply to
    • feld
    • Dick Morrell ✔️.

    @Cloudguy @feld This is quite a rude response to a reasonable inquiry.

    You're making some grand claims, and leveraging limited social capital to do so. (I've never heard of you, and you haven't made it easy to verify you.) Posting insults is not making it any easier to take your word on faith.

    In conversation Wednesday, 26-Apr-2023 20:35:55 JST from infosec.exchange permalink
  14. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Tuesday, 25-Apr-2023 21:03:40 JST varx/tech varx/tech
    in reply to
    • Dick Morrell ✔️.
    • Topher 🌱🐧💚

    @Cloudguy @topher It's at least a little bit vague. :-) I used to have the same login for the ecommerce and AWS sites, but I don't any more; I don't recall what happened, but I think they've separated them, or encouraged people to separate them.

    For people with *AWS-only* accounts, does anything need to be done? Because that's the bigger lift.

    In conversation Tuesday, 25-Apr-2023 21:03:40 JST from infosec.exchange permalink
  15. Embed this notice
    varx/tech (varx@infosec.exchange)'s status on Saturday, 24-Dec-2022 22:06:37 JST varx/tech varx/tech
    in reply to
    • pettter
    • Chris Wysopal

    @pettter @Weld Not here—they used a randomized controlled trial.

    In conversation Saturday, 24-Dec-2022 22:06:37 JST from infosec.exchange permalink
  • After

User actions

    varx/tech

    varx/tech

    Boston-area meat construct ␥ I just do what the plants tell me ␥ I'd rather be undermining the client-server paradigmThis is the more tech-y alt of https://cybersecurity.theater/@varx

    Tags
    • (None)

    Following 0

      Followers 0

        Groups 0

          Statistics

          User ID
          79880
          Member since
          24 Dec 2022
          Notices
          35
          Daily average
          0

          Feeds

          • Atom
          • Help
          • About
          • FAQ
          • TOS
          • Privacy
          • Source
          • Version
          • Contact

          GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

          Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.