Yeah, I'm bouncing for now on the localhost requirement. Or, on a related issue of not parsing my .ssh/config, a Match directive, and not wanting it to parse it yet. I grep'ed for an env var to override, but only USER and SSH_AUTH_SOCK are pulled in.
I did go get install ...nerdlog/cmd/nerdlog-tui@latest just fine.
Thanks for hacking in the open, and releasing early.
Hey mcint, fyi both of these issues are addressed: the localhost one is addressed for real, and a Match issue is worked around: while it's still not properly implemented, at least it doesn't prevent Nerdlog from starting now. Just in case you wanted to give it another try.
I would say that their thanks is sincere, and that they're applauding you for releasing a new tool to a public/critical audience while also taking feedback in very constructive manner.
Excellent descriptive analysis. Wrong, misleading title, perhaps "technically correct," but at best with a "backdoored" meaning.
It points out the need and use for build-manager tools that go a step beyond union file system layers, but track then enforce that e.g. tests cannot pollute build artifacts. Take a causal trace graph of files affecting files, in the build process, make that trace graph explicit, and then build a way to enforce that graph, or report on deviations from previous trace graphs.
In defense of the author: nobody reads your article if the name is boring (that is my experience at least), which it would've been if they titled it more accurately. That gives incentive to authors to use click-bait titles.
In defense of the bank robber: no clerk simply gives you money if you aren't threatening them (that is my experience at least), which it would have been if they acted like a respectable citizen. This gives people the incentive to become bank robbers.
Can we update the title with the project name, adminer?
I've gently relied on this tool, it's basically delightful to use. Simple to deploy, doesn't fight the protocol and software stack it can be deployed alongside for securing, using. A shining, straightforward FOSS success.
I did not migrate anything, these two posts were from someone else's blog and they were up less than a week ago! Web link decay strikes again, I'll check if I can find where this person blog again, thanks for noticing.
You should include your name, and link to channel in the form's self description. I accidentally followed the link blindly, and had no context.
Anyone following the link directly without viewing comments or knowing your hn username will be confused. I suspect your intended audience is larger than: people who already know you and your content well.
Thanks for the comment and I'm sorry for the late response. HackerNews is bad in that you get no notifications. I agree and I updated the form, although I suspect no one will see it now :-)
> They also describe an attack against 11-round AES-256 that requires 2^70 time—almost practical.
>> AES is the best known and most widely used block cipher. Its three versions (AES-128, AES-192, and AES-256) differ in their key sizes (128 bits, 192 bits and 256 bits) and in their number of rounds (10, 12, and 14, respectively).
>> In the case of AES-128, there is no known attack which is faster than the 2^128 complexity of exhaustive search. However, AES-192 and AES-256 were recently shown to be breakable by attacks which require 2^176 and 2^119 time, respectively.
> They also describe an attack against 11-round AES-256 that requires
> 2^70 time—almost practical.
But... nobody uses 11-round AES-256. And, crucially, these are related-key attacks, not practical for, say, breaking TLS.
In 2009, a new related-key attack was discovered that exploits the
simplicity of AES's key schedule and has a complexity of 2^119. In
December 2009 it was improved to 2^99.5... However, related-key attacks
are not of concern in any properly designed cryptographic protocol, as
a properly designed protocol (i.e., implementational software) will
take care not to allow related keys, essentially by constraining an
attacker's means of selecting keys for relatedness.
(Note that the attack with time complexity 2^99.5 also requires 77 bits of memory, or ~16 ZiB, which is, um, billions of terabytes of RAM? edit: actually, this is 2^77 blocks worth of memory, so add a couple more orders of magnitude.)
To date, the best unconditional attack on any full variant of AES provides a factor of ~4 speedup, although it requires 9 PB of data just for AES-128.
Sure, but that inequality of meaning would have to lead to a 'Therefore I conclude this specific, highly infeasible, self-contradictory secret exists' - which is perhaps a common problem with arguments for religion.
I'm confident there's fairly mundane multi-generational secrets, without having to summon the illuminati or knights templar. Either way it doesn't negate the interest in having a technology that could provide that.
Cryptography isn't a technology for keeping secrets, its a technology for keeping secrets in transit. Its not particularly useful for keeping multigenerational secrets (how do you do key management over 100 years?)
> Is your suggestion that key rotation is a necessary requirement?
If you want your secret to last more than one human lifetime, you have to enroll new people into the system somehow.
My main argument would be that cryptography is mostly useless in such a scenario. It makes much more sense to put the secret in a filing cabinet, put a lock on the filing cabinet, and if you are really paranoid, maybe hire some people with guns to guard it. Cryptography for such a scenario is the sort of thing that happens in movies not real life.
And even if cryptography was used, it doesn't seem like public-key would be very applicable at all, so pcq is extra irrelavent.
Concur that PK is probably inappropriate, but not necessarily that this means PCQ would be (irrelevant).
The Voynich manuscript is likely a despairingly poor example of any argument, but it's the most famous long-lived / unresolved encoded text I could think of. (I think a year or two there was a claim it was properly decrypted but I'm not convinced it ever will be, mostly because I suspect it wasn't ever meant to make sense.)
Back to the key rotation question - I think we agree that's not a necessary requirement.
> Concur that PK is probably inappropriate, but not necessarily that this means PCQ would be (irrelevant).
PCQ is almost exclusively about public key crypto since traditional symmetric crypto is already quantum safe (with a caveat that you might need to double key lengths to reduce risk from grover's algorithm)
Diplomatic communications about how you plan / succeed at undermining allies. Or communications about atrocities you knew were happening, but decided to ignore.
There is plenty of reason to want to keep diplomatic and military communications secret for a long time.
> Diplomatic communications about how you plan / succeed at undermining allies. Or communications about atrocities you knew were happening, but decided to ignore.
>There is plenty of reason to want to keep diplomatic and military communications secret for a long time.
I don't think that makes sense. Why would you want to keep implicating communications around for 100 years? Wouldn't you just destroy them?
Cryptography isn't useful for secrets you want nobody to know. Its useful for secrets you want some people to know but not others.
That said it also seems questionable how much people care about atrocities hundred years after the fact. For example, nobody is boycotting IBM today for their role in the holocaust.
News of these things does come out from time to time, usually over a shorter time period, and these create embarrassment, shock, pain and anger, but has any had significant substantive consequences? Here is a hypothetical one to consider: FDR secretly informed Hitler that the US would support an invasion of the USSR - how far would be the consequences of such a revelation reach, if it were revealed today?
It's not so much about the impact of the secrets leaking. Instead, its about the impact on communications if diplomats need to worry about their communications leaking.
Because that was the number the person i was responding to gave.
In any case north korea has the bomb. I think the secret is out. The most difficult thing at this point is the engineering challenge not the book knowledge.
I was under the impression that information about how to build nukes was mostly well known by most countries, and it is just a matter of getting enough of the right type of uranium or whatever.
My genetic data will be relevant even after I'm dead because my children and grandchildren share it with me. And it's a modern kind of data that didn't exist in 1925.
I hate to tell you, but even if you have never done 23 and me or anything similar, enough of your family has that your genetic data is already very readily accessible to the parties who need it.
Realistically you cant keep that secret though. There are a lot of people who share enough of your dna to reconstruct parts of it. Possibly hundreds. And all it takes is a hair folicule or spit.
You are never keeping that secret against an interested adversary.
