timmclean

For supply chain security, you might be interested in cargo-vet[0], a tool for coordinating and requiring manual reviews of open source dependencies. Both Mozilla and Google[1] have started publishing their audits.toml files, which are machine-readable files describing what source code reviews they have performed.

[0] https://github.com/mozilla/cargo-vet

[1] https://opensource.googleblog.com/2023/05/open-sourcing-our-...

Is there a reason why they couldn't split the load across multiple HSM? For something so sensitive I would've expected a design where one or more root/master keys (held in HSM) are periodically used to sign certificates for temporary keys (which are also held in HSM). The HSMs with the temporary keys would handle the production traffic. As long as the verification process can validate a certificate chain, then this design should allow them to scale to as many HSMs as are needed to handle the load...

Saving you a click: despite what the repo title might suggest, while the code is open source, the model weights cannot be used commercially without permission.

> The code in this repository is open-source under the Apache-2.0 license. The InternLM weights are fully open for academic research and also allow commercial use with written permission from the official team. For inquiries about commercial licenses and collaborations, please contact [email protected].

https://github.com/InternLM/InternLM#open-source-license

FWIW, spot prices for c5a.24xlarge in us-east-2b and us-east-2c seem to have been under $0.92/hr for most of the last 3 months. So, assuming some flexibility on the choice of region, that would adjust your estimate to $0.92 / $1.69 * $1233.70/mo = $671.60/mo, which looks a lot more reasonable. Hopefully I did that math right. Data egress prices are definitely still ridiculous, I agree.

Thank you for your comments on this thread and others today. They have been very helpful in understanding what is actually going on.

I believe you're thinking about `add`. According to Agner Fog's instruction tables, the load and ALU uops are fused for `add`s, but not in the case of `inc`

http://www.agner.org/optimize/instruction_tables.pdf

That all makes sense, but it doesn't seem to apply to the example code in the article, right? `inc` doesn't decode to a single fused uop on Ivy Bridge. AFAIK, the example code in both cases decodes to the same number of uops in the fused domain...

The important thing to take away from this article is that MD6 really shouldn't be used in any production software, unfortunately. MD6 didn't even make it past the first round of the SHA-3 competition, so it hasn't received much attention from cryptanalysts.

Cryptohipsters (can I coin this term?) should take a look at Skein (a third-round SHA-3 candidate), BLAKE2 (the successor of a third-round SHA-3 candidate), and Keccak (the SHA-3 winner). These hash functions have undergone much more analysis. Notably, BLAKE2 is faster than MD5 in many cases, but without the security problems of MD5.

I've been meaning to learn jq, so I decided to give it a try.

    FRUITS=$(cat input.json | jq '.models | map(select(.title == "fruits")) | .[0]')
    FRUIT_NAME_KEY=$(echo "$FRUITS" | jq '.fields | map(select(.name == "Name")) | .[0].key')
    
    FARMERS=$(cat input.json | jq '.models | map(select(.title == "farmers")) | .[0]')
    FARMER_NAME_KEY=$(echo "$FARMERS" | jq '.fields | map(select(.name == "Full name")) | .[0].key')
    FARMER_FRUITS_KEY=$(echo "$FARMERS" | jq '.fields | map(select(.name == "Fruits")) | .[0].key')
    
    BOB=$(echo "$FARMERS" | jq '.entities | map(select(.['$FARMER_NAME_KEY'] == "Bob, the farmer")) | .[0]')
    BOB_FRUIT_IDS=$(echo "$BOB" | jq '.['$FARMER_FRUITS_KEY'] | .[]' -r)
    
    for BOB_FRUIT_ID in "$BOB_FRUIT_IDS"; do
        echo "$FRUITS" | jq '.entities | map(select(._id == "'$BOB_FRUIT_ID'")) | .[0] | .['$FRUIT_NAME_KEY']'
    done

There's a bit of bash boilerplate, but honestly it was about what I would expect, given a structure with so many layers of indirection.

Pain points:

* Switching between bash and jq's filtering language led me to use string interpolation with bash variables. Malicious inputs can probably exploit this (and it was just awkward anyway).

* A "select one" filter would be nice, instead of select + get first element.

The author should use a library that provides a simple "encryptWithPublicKey" method, so that any choices about RSA key size, AES mode of operation, etc are all taken care of. NaCl[1] would probably be best, since it's written and audited by prominent cryptographers.

[1] http://nacl.cr.yp.to/

Heads up to anyone considering using this: the author wrote their own crypto code[1]. I would recommend against using this until that is fixed... I've already spotted a few vulnerabilities.

[1] https://github.com/FedericoCeratto/owefs/blob/master/pycrypt...

Modern password hashes are designed to use a large amount of RAM in addition to CPU time in order to make password cracking using ASICs and GPUs more difficult. The paper on Argon2[1], the winner of the recent password hashing competition, would be a good read if you're interested in learning more about how password hashes are designed.

[1] https://www.cryptolux.org/images/0/0d/Argon2.pdf

Mainly because it adds complexity, and complexity in crypto can hide subtle bugs. Example: http://blog.ircmaxell.com/2015/03/security-issue-combining-b...

To expand on this, here are a few mistakes that I caught while scrolling quickly:

> For production applications some AES variant or RC4 would be a better choice.

RC4 is not at all a good choice for new applications[1].

> SHA1

SHA-1 is broken (although not as badly as MD5). SHA-2 or SHA-3 should be preferred.

> 800-bit RSA

800 bits is alarmingly low. Browsers are currently upgrading from 1024-bit certificates[2].

[1] http://blog.cryptographyengineering.com/2013/03/attack-of-we...

[2] https://blog.mozilla.org/security/2014/09/08/phasing-out-cer...

I prototyped almost exactly this a couple years ago: https://www.timmclean.net/json-editor/

I haven't had time to come back to it, so I'm very glad to see that other people are working on the idea!

Code for a Cause : Web Developer for Healthcare Non-Profit (work from home in Toronto, ON)

We Canadians are proud of our universal health care, but our healthcare system faces difficult challenges. Our hospitals' staff use “enterprise”-quality software that is hostile to its users. Doctors often struggle with the software’s interfaces, and are unable to access the information that they need in a timely manner. Quality of care suffers.

KoNode is a small nonprofit software startup intent on fixing these problems. We’re building a series of open-source applications to “fill the gaps” in existing processes, and help medical staff provide better care.

Our team is ready to expand, and welcome a new developer with ninja-like coding skills and a passion for improving users' lives. A short-list of great perks of joining our team:

    - Work from home, on your own full-time schedule. Freelance freedom!
    - A team experienced with  healthcare workflow & users’ needs.
    - Regular in-person meetings at Toronto’s Centre for Social Innovation.
    - Strong network of healthcare, business, and programming consultants.
    - Happy, helpful team atmosphere. Driven to make an impact.

. . . and the goal we’re achieving together? Providing healthcare professionals (and beyond) with an accessible alternative to tedious, bulky, costly software. When an automated solution doesn’t yet exist... well, we make one happen. Simple.

Sounding even better? Here’s a picture of KoNode on the technical side:

    - Web (HTML/JS/CSS) + NodeJS (we use node-webkit, aka NW.js)
    - Cutting-edge libraries including Lodash, Moment.js, React, and more.
    - Modular design, piecing together apps using open-source and custom code.
    - Collaborative version control and feature management on Git[Hub].
    - Real-world testing & feedback with network of health professionals.

Team members must be able to meet in downtown Toronto periodically.

Ready to apply? Contact us with your resume and portfolio at [email protected]

Of course; I was speaking informally. "allowing collisions" == "allowing it to be feasible to find a collision"

Collision resistance is critical for most applications of the OP's scheme. The OP is proposing using hashes as identifiers for immutable content. Imagine the following:

- I publish a JavaScript library under this scheme using a hash without collision resistance.

- Popular/important websites refer to my library as hashname://..., trusting that this refers to the version of the library that they audited.

- I can then create a new, malicious version of the library that has the same hash and use it to infect popular sites.

Allowing collisions breaks the immutability requirement, which impacts security in many important cases.

N-bit hashes have at best (N/2)-bit collision resistance (see birthday attack[1]). An 80-bit security level does not have a large enough margin of safety nowadays.

RIPEMD has a 256-bit variant, but it hasn't received enough scrutiny.

[1] https://en.wikipedia.org/wiki/Birthday_attack

A member of the SHA2 (or SHA3) family would be more appropriate. RIPEMD-160 is slower and less resistant to collisions. I agree however that the use of SHA1 is problematic!

Agreed. Unfortunately, some implementations missed that:

https://github.com/namshi/jose/commit/127b4415e66d89b1fcfb5a...

https://github.com/davedoesdev/python-jwt/commit/5ddb71b2ed5...