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 internlm@pjlab.org.cn.

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 david@konode.ca

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...

oh god, hopefully not

It shouldn't affect end-to-end encryption, because those keys should only be generated at the endpoints (i.e. the users' devices, probably not running FreeBSD). It could affect TLS, etc, however.

Do you have HTTPS Everywhere installed? Their JavaScript is hosted on HTTP, so it gets blocked with a mixed content warning on Firefox (probably on Chrome too).

KDFs are definitely suitable for password storage, so I'm pretty confused at how the author arrived at their conclusion. They mention that scrypt with low security params is less secure than bcrypt at an adequate security setting. This doesn't seem particularly alarming or even surprising.

I think a better take away would be: "If you use scrypt, make sure you choose adequate security parameters. If you're already using bcrypt, there's no need to switch to scrypt."

Edit: the first paragraph of the scrypt paper actually brings up the fact that the problems of password storage and key derivation are equivalent:

Password-based key derivation functions are used for two primary purposes: First, to hash passwords so that an attacker who gains access to a password file does not immediately possess the passwords contained therewithin; and second, to generate cryptographic keys to be used for encrypting and/or authenticating data. While these two uses appear to be cryptologically quite different [...] they turn out to be effectively equivalent

https://www.tarsnap.com/scrypt/scrypt.pdf

If you XOR'd this RNG's output with, say, /dev/urandom, you could mitigate that risk significantly (you would be no worse off than before).

"reliable rides" fits with their stance on surge pricing -- they want to be a service that can always get you a ride, as long as you're willing to pay the price (not saying this is good or bad).

Real-time updates to queries looks awesome. Way simpler than doing pushing updates through pubsub. Great work, guys!

In case this is helpful: I interned at a company, Polychart, where we built a product similar to chart.io that is now open source and can be self-hosted: https://www.polychart.com/

I think the interesting stuff starts on page 2:

With the help of Mathematica, one of us found some counterexamples to our conjectures. Fortunately, another one of us was using Maple and, when checking those supposed counterexamples, found that they were not counterexamples at all. After revising our algorithms from scratch, we concluded that either the computations performed with Mathematica or the computations performed with Maple had to be wrong. Things started to become clear when the colleague using Mathematica also found some “counterexamples” to the above-mentioned result of Karlin and Szego for the case in (1) and, even more dramatically, his algorithm yielded different outputs given the same inputs. Our conclusion was that Mathematica was computing incorrectly.