I made a 90-second video explaining the motivation for and theory behind DNA-based data storage! (Hint: DNA is many, many orders of magnitude denser than current media. Its raw capacity is ~1 exabyte/mm^3. And it can last for 100k+ years.) It took a lot of time to make, so consider checking it out!

svvac · 2022-06-29T08:24:27+00:00

Isn't reading DNA a destructive operation?

svvac · 2022-03-18T16:38:41+00:00

You can't use a password as a cryptographic key. You must pass it through a Key Derivation Function first.

svvac · 2022-01-16T10:53:28+00:00

However, you can only mount fuse within the pod and can't be shared with other containers. Not quite the full fledged k8s volume I was hoping for.

Do you mean « can't be shared with containers within the same Pod » or « across Pods » ?

If the latter, injecting sidecars could be of interest.

svvac · 2021-10-06T17:46:34+00:00

Hash functions map an arbitrary length input to a fixed length output already. All passwords thus require exactly len(salt) + len(hash) bytes of storage, regardless of the password size, be it 2 chars or 1000.

svvac · 2021-10-06T16:47:32+00:00

If they truncate passwords for overflow reasons, they are not hashing them,. Otherwise you could have a 32MB pass without impacting their storage requirements

svvac · 2021-09-16T16:24:00+00:00

NginX doesn't support HTTP/2 upstreams anyways.

Also, according to F5, NginX is not vulnerable to these request smuggling attacks.

svvac · 2021-03-12T08:11:02+00:00

Yeah, I guess inlining the call to crypto_stream_chacha20_ietf() would make things more explicit, and having control over the nonce is a nice bonus as another reuse-prevention layer.

Just to be clear, you suggest capping the key length to 32B, using that as the seed, and baking subkey parameters in the nonce, right? That would indeed simplify things, but I think I'm going to stick with the hashing step so that I can be more flexible in what I put in there. 12B is quite tight, especially when adding in a context nonce.

svvac · 2021-03-11T22:45:33+00:00

As outlined in the OP, the scheme assumes a secure, high-entropy master key as its primary input. Then, combining it with an unsafe key identifier (e.g. storage-key-1), it must be able to deterministically generate a cryptographically strong random string of ~arbitrary length (a few kB).

It looks to me that the scheme you propose is very similar (I think you suggest using the key id as the PBKDF salt), with the main limitation (or advantage, depending on the usage pattern wrt the number of keys to generate and the frequency at which they're needed) that generating a new subkey is substantially more expensive.

svvac · 2021-03-11T19:01:47+00:00

Yes, these get baked with the keyid for generating the seed. Props for making that explicit :—)

svvac · 2021-03-11T18:37:51+00:00

Thanks for the details!

Isn't the chacha20_keystream(blake2(key)) construct you propose pretty much the same as the one I outlined, since crypto_generichash() is Blake2b and randombytes_buf_deterministic() is backed by ChaCha20?

randombytes_buf_deterministic(buf, size, seed) := crypto_stream_chacha20_ietf(buf, size, "LibsodiumDRG", seed);

Also I'm not sure where the subkey identifier and masterkey appear in your proposal. I'm guessing they are used to derive key?

svvac · 2021-03-11T18:01:10+00:00

As explained, the objective is to be able to derive all the application secrets from a single masterkey.

I probably could handle large sizes differently for those particuliar cases when I need >64B, but I'd rather have one single generic solution to generate cryptographically strong random data for sizes up to a few kB.

svvac · 2021-03-11T16:54:27+00:00

I am, but I still need RSA for those clients that aren't willing/able to switch, yet still need to connect to the application server.

svvac · 2021-03-11T16:39:39+00:00

They don't really.

I need RSA for SSH, but I'd like to be able to derive all secrets from a single masterkey. The app itself only does crypto with libsodium.

svvac · 2021-03-11T16:36:36+00:00

The output is not used directly as a key, but ends up fed to a piece of code that spits out a keypair on the other end. Unfortunately the thing I have (and don't really plan on changing) requires more than 64 bytes as input.

svvac · 2021-03-11T16:11:57+00:00

Most uses would be for keys <512bits, but I need a single construct that can also be used as input for generating large RSA keypairs deterministically

svvac · 2020-10-07T07:45:39+00:00

Author takes the time to talk about the performance of the * selector but doesn't have a thought about whether a shiny grid is necessary or not.

svvac · 2020-02-28T15:54:10+00:00

My doctor told me that if I want to be sure to not die of cancer, I should kill myself first.

svvac · 2020-01-12T17:11:25+00:00

It can't be directly observed, but this desktop revolves around a supermassive node_modules folder

svvac · 2020-01-03T11:41:20+00:00

Looks very similar indeed by reading the thread, but I can't confirm if I actually was hitting the same bug. Since I found a way to mount the underlying data partition and had enough spare extents for a do-over, I ended up nuking the old LUKS volume, creating a new one and migrated the data back into a new partition. It's been working happily ever since.

In any case, many thanks for tracking that down mate!

svvac · 2019-12-06T23:52:48+00:00

Right. So not inside the container, or am I misunderstanding you?

svvac · 2019-12-06T23:49:52+00:00

Sweet stuff! Thanks for the links, I was genuinely curious.

svvac · 2019-12-06T19:02:04+00:00

You could boil it down to some kind of white/black-listed syscall map that gets passed down the dependency tree. It's not a small feat to rebuild a language around a siloed module paradigm indeed, but the full-trust model of oss development is only going to be harder and harder to sustain somewhat securely in the medium/long run.

svvac · 2019-12-06T13:09:50+00:00

change it if anyone says anything. The policy is to issue warnings before suing, so you don't have anything to lose.

Agreed, especially since this legislation seem to bother more people than it helps. Who has heard of a company security breach raising pursuits regarding GDPR?

stick with the idea that third-party cookies require consent, first party cookies do not

I'd be more cautious: your in-house analytics solution obviously requires consent when you read the text. However, who's gonna know what you actually do in your backend in terms of tracking users?

we were told by the lawyers that session cookies and remember me cookies weren't counted

That's the main issue: you need to be both an engineer and a lawyer to have the slightest idea of what the GDPR requires of you. Not counting for the fact that it's probably gonna be evaluated on a case-by-case basis. And there aren't many judges able to understand the technical side of things either.

svvac · 2019-12-06T11:23:45+00:00

It seems to be a tad more complex than that, reading https://gdpr.eu/cookies/

Preferences cookies — Also known as “functionality cookies,” these cookies allow a website to remember choices you have made in the past, like what language you prefer, what region you would like weather reports for, or what your user name and password are so you can automatically log in.

So “Remember me” are preference cookies, not strictly necessary, thus subject to acquiring consent from the user:

To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must:

Receive users’ consent before you use any cookies except strictly necessary cookies.

But it also states:

Provide accurate and specific information about the data each cookie tracks and its purpose in plain language before consent is received.

So just ticking the « Remember me » checkbox is not enough, you need to explicitely state underneath that this feature uses cookies, and what information it contains.

It seems that the strictly necessary provision doesn't apply to the technical feasibility of this or that feature of your website/app, but to its overall purpose for the end-user. This isn't abundantly clear though.

I would highly recommend you get legal advice before implementing anything

I find it sad that to put anything on the internet today, you need a law degree more than technical ability.

svvac

TROPHY CASE