> But, the whole of his complaint rests on this deficiency. It's not possible to constructively disagree with someone who is unwilling to acknowledge basic facts, or who promotes an alternate reality.
This really needs to be emphasized--if you cannot agree on what the facts are, you will never come to a real conclusion. This is something the article completely glosses over. However, I also I think there's also something beneath just agreeing on what constitutes facts that is equally important, which is a (roughly) shared value system.
The old, "liberally educated" world that the author references the death of in the 1960s (i.e. "Closing of the American Mind") was one of shared values--largely white, protestant values. What replaced it was a different value system--I've seen it called the "meritocratic" value system, or similar--which had fundamentally different core values, and was/is dominant among American conservatives and liberals until recently.
Currently, the furthest left and furthest right often don't agree on core values. On the left, I think almost any argument that uses a variation on "(holy text) said so" can be dismissed off-hand as an unconvincing argument when you're talking about things beyond your own personal behavior--however, my Mormon relatives feel quite differently. This gets uglier and further away from the mainstream when you start to dig into some of the belief systems that groups on the alt-right propose (simplifying, but often things like "only white people have intrinsic value"), as opposed to the mainstream belief systems of the last ~40 years ("all people have intrinsic value"). Similarly on the far left, I've seen a lot of disagreement with other things that I'd hold up as mainstream values of the last 40 years (such as "competition between independent actors leads to good outcomes for consumers*").
Disagreements when fundamental values differ will put any argument on hold before it gets started, and I expect the only real outcome is things that devolve into shouting matches, or worse. And from what I've seen, the range of acceptable values has widened dramatically in the last 15 years--I'm curious to see if this winds up coalescing into a new set of mainstream values after a while, or if things like the structure of the internet/"filter bubbles"/increased ideological splits will mark the end of an ideological "mainstream" as it used to exist.
> We're not even close to a world where tools can offer amazing protection.
Actually, we're reasonably close--the tools aren't quite there yet for mass consumption (many are still feel quite researchy), but given that the trend of (research -> industry) usually takes 10-25 years, I'd expect that more and more critical systems will be formally verified in 10 years. Even now, companies like Amazon are using some formal methods (modelling with TLA+) to validate that specifications will behave as expected. (https://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-...)
Formal methods & dependent types allow for some very cool tricks on top of that--basically, you can encode in the type system a proof that the program implementation matches a specification. CompCert is a mostly-formally verified C compiler--since it was released, iirc, no bugs have been found in the verified portion of the compiler. (CompCert page: http://compcert.inria.fr/man/manual001.html)
You can also prove that the specification has particular properties (in a distributed system, things like liveness and partition tolerance). Consider the Verdi framework (allows formal verification of distributed protocols) and their formal verification of RAFT. (Code here: https://github.com/uwplse/verdi-raft)
However--it's just that it currently takes a lot more work in terms of person-hours to do the development. But formal methods are getting used in more and more places, and they do make a difference in practice. (Wired has a not particularly deep, but straightforward article that shows another use: https://www.wired.com/2016/09/computer-scientists-close-perf... )
Anecdotally, as far as effort--I'm an industry programmer who writes mostly C#. I had to learn Coq (a formally verified language) for a class--it took me a couple of simple assignments to get the idea of how it worked. Even after a few months, hacking together a formally verified interpreter for a very simple language (functions, while loops, etc.--simple, but not trivial) took about 3-4 times longer than it would have taken me to do normally.
I think the problem is that the language for smart contracts that backs Ether hasn't been written with formal verification in mind. You could apply formal methods to anything after the fact but it doesn't look like they've made this easy here. You could claim that a C program could be made bug free eventually by applying formal methods for example but it would require a huge amount of work.
Is there a good reason they didn't use a battle tested pure functional language with a strong and expressive type system?
I'd agree, and the article basically says the same thing--the language is too expressive, and therefore hard to analyze. I don't know that much about the Ether devs, but I'd expect it just didn't occur to them--even among PL folks, knowledge & experience with something like coq is somewhat rare unless you went to the right undergrad or grad school. Especially if you weren't keeping up with the latest research in the last ~5-10 years or so.
Something like Coq with a few primitives to represent interacting with the Ether network, and an optimizing, verified cross compiler would have been a perfect fit for this sort of thing, in my opinion. It's a shame that they didn't go that route, the extra dev time to get it right probably wouldn't have been equivalent to 200+ dev-years of cost (~31 million).
> I don't know that much about the Ether devs, but I'd expect it just didn't occur to them--even among PL folks, knowledge & experience with something like coq is somewhat rare unless you went to the right undergrad or grad school. Especially if you weren't keeping up with the latest research in the last ~5-10 years or so.
Hmm, you'd think they'd know about languages like Haskell though.
I don't think it would be practical to expect developers to write verified code anyway; it's still far too challenging in general. Having a language where you could optionally formally verify the code would have been useful though.
> Something like Coq with a few primitives to represent interacting with the Ether network, and an optimizing, verified cross compiler would have been a perfect fit for this sort of thing, in my opinion
You wouldn't think something like Coq with a few primitives would make some contracts difficult to write?
Late response, but: coq has the optional verification that you're proposing. :)
In my experience, Coq is not significantly harder than OCaml to write unverified code in. It's missing some nice shorthand syntax, but other than that it feels pretty similar.
With coq, the main challenge is expressing things that are meant to "run forever" (any truly unbounded recursion)--but my understanding is that would be forced to halt when it ran out of ether (so it's bounded anyways, and if you needed to you could probably explicitly hand that fact to the compiler)--and I think you probably don't want something to loop indefinitely if each iteration costs ether.
The main issues with coq that I think you'd crop up against are things that a good optimizer/compiler could probably help with (e.x. things like the fact that integers are naively represented as cons cells, so addition is O(n) and multiplication is worse). However, I haven't written any smart contracts, so it's definitely possible I'm missing something obvious.
> I'm getting kind of sick of this "deep learning is a black box" trope, because it's really not true anymore.
That's fair/probably true.
I think there's two things that drive that--one, lack of a widely shared deep understanding of the field[0] (and not really needing a deep understanding to get good results--as both you and the author pointed out), and two, the fact that it feels like cheating, compared to the old ways of doing things. :P
[0] When the advice on getting a basic understanding is "read a textbook, then read the last 5 years of papers so that you aren't hopelessly behind", there just isn't going to be widespread understanding.
I'll have to watch this later, but I'd argue the issue, at least for me, isn't really surface level understanding. (At least, the kind I think could plausibly be imparted in 4 minutes. :))
The basic idea of deep learning has always seemed straightforward to me[0]. However, at least my perception is that it feels like there's a lot of deep magic going on in the details at the level that Google/Microsoft/Amazon/researchers are doing deep learning. That's honestly true of most active research areas[1], but since those results are also the results that keep getting a lot of attention, the "it's a black box" feeling makes sense to me. :)
[0] Having done both some moderately high level math and having a CS background, I feel like most ideas in CS fit this description, though. Our devil is the details.
[1] For instance: fairly recent results in weird applications of type theory are also super cool, and require some serious wizardry, but those get much less attention. (And are, I think, more taken for granted, since who doesn't understand a type system? /s)
Having until very recently worked in deep learning at Google, I can assure you that if you read and watch enough recent public papers and talks, you will be very, very close to the latest thinking of researchers at these companies.
You're right that it can take some time to do this edification work and develop the understanding for yourself -- the research is broader and more specialized than it appears at first glance -- and it does help to be surrounded by smart people puzzling over the same types of problems, but there's very little secret magic here. It is, however, of benefit to these companies to develop a public image of exclusivity and wizardry in their research; I fell into this trap too, before I saw how the sausage is made.
If you want to make your own fundamental innovations in deep learning, it can be very resource-intensive, both computationally and otherwise. However, it is easy to apply the current state-of-the-art to a broad spectrum of applications in novel ways.
One of the reasons I left is that I think there is a big opportunity in applying these powerful basic principles and approaches to more domains. The research companies are, IMO, focused on businesses that are or have the potential to become very, very large, and that can take advantage of their ability to leverage massive amounts of capital. This leaves many openings for new medium-sized businesses. Of course, as you grow, you can take stabs at progressively larger problems.
I'm with you 100%. RF has been around for ages, but it still is "black magic" to most EEs (after most people finish the standard 100 level courses describing op-amps, people tend to go into the digital domain and leave analog work to that small demographic). One EE will be able to design a fantastic 7 layers of poly, multiprocessing chip in his garage using Cadence and the TSMC 65nm libs, while someone else will be able to design a flawless cavity filter at 16 ghz. People have specific domains of expertise, even when they hold the same "EE" or "CS" or "Math" degree from the same university, largely based on which courses they elected to take in their 3rd and 4th year.
Likewise, fields advance quickly. I can grok how an z80 or 6502 works from NAND to Tetris, but even a mediocre second year grad student would wipe the floor with me. I, too, went pretty far down the road of mathematics, but watching MSRI lectures from the last few years leaves me struggling to keep up, in the field (algebraic topology) where I once felt comfortable. If you don't keep up with your field you're going to be lost.
The reason I think the 'black magic' trope keeps on being bandied about is because most people reading the articles describing ImageNet et al just don't have the background necessary to grok it[1]. If you had asked them a year ago what the convolution operator was, they'd have scratched their head. When they try to go and read that ImageNet paper they'll be left even more confused because the last time they thought about linear algebra was in their freshman year of uni. It'd be analogous to trying to write some computational fluid dynamics modeling software after not having taken/not touching diff eqs for a decade.
[1] This isn't to disparage those who didn't- everyone has their domain of expertise. I'm just trying to emphasize why the conception of 'black magic' exists. It's quite simple - when one has a tenuous grasp on the foundational knowledge upon some theory is built, you will have difficulty learning abstractions built upon said foundations.
Ah, this is interesting, because I've recently dabbled a bit in RF. My path went like this:
1) Interested in doing something with RF, don't know much about it, know that people say it's black magic.
2) Do some research... Ah, this is a pretty deep topic, and it might take a while to develop the necessary intuition.
3) Become competent enough to solve my immediate problem, recognize that it is a extensive field in which there is a lot of specialized practical knowledge that could be acquired.
4) Accept that I have higher life priorities than to go down the RF rabbit hole, but feel that I could learn it if I wanted to invest the time. No longer feels like black magic.
I think there is a distinction between fields like deep learning and RF, where most of the information is public if you know where to look, and say, cryptanalysis or nuclear weapon design or even stage magic, where the details and practical knowledge of the state-of-the-art are more locked behind closed doors. And for a field that you're not familiar with, it can be initially unclear which category it falls into. I think the existence of public conferences on the topic is a good indicator, though.
So it turns out you can basically use type theory to encode a surprisingly large number of desirable traits about your program. (Caveat being that as you get more restrictive, you reject more "good" programs at compile time--no free lunch with Rice's theorem.)
It turns out you can encode a lot of other interesting properties in a type system (esp. if you're building on top of the existing type system), though--you can ensure that a java program has no null-dereference checks (https://checkerframework.org/ has a system that does this), and Coq uses its type system to ensure that every program halts (as a consequence, though, it isn't actually Turing complete).
There's also cool things like Lackwit (http://ieeexplore.ieee.org/document/610284/) which basically (ab)used type inference algorithms to answer questions about a program ("does this pointer ever alias?", etc.).
I think you're kind of missing the author's point.
> My feeling is that the "perfect" abstraction of reality to geometry is actually a very high order function that we don't fully understand.
You don't need a perfect abstraction of reality, though. All you need to do is get close enough to catch up with humans or outperform them and you've solved most of the hard problems in computer vision. Fortunately--at human scales, which are the only ones you need to care about for computer vision, reality behaves closely enough to a pure Euclidean space that you're fine. :)
The author's primary argument seems slightly more nuanced, too, than just "It'd be nice if we could use old techniques".
Basically, they're claiming that if you can build geometric understanding into the ML model, you will get significantly better results that just naively plugging and chugging away with raw data. That's an empirical claim that can be validated by researchers--either it will give a significantly improved performance on well defined problems (stereo vision, etc.) or it won't. Vision is one of the research areas that have developed pretty good benchmarks over the years. :)
But that is exactly my point. Geometric models are the old tools we had. The new tools are ML Models. It would be nice if they both worked together. But there is nothing to say that they should. Nor is it obvious that it would be beneficial.
Your point that this is testable, though, is important. I fully agree with that and was not intending to dismiss the idea. Just because I am not as confident as the author, does not mean that I am right. :) (I'd accept that I am likely not right.)
You get other advantages for doing three/five node replication--online updates are free if you require (n-1) compatibility.
Reality is that if you need to hit 5+ nines and require strong consistency guarantees (like "we never lose our customer's data") at data center scale, you'll probably need something similar. Most people probably don't need those guarantees, however.
I should have clarified -- I meant mostly for things like OLTP databases.
I see why Google built Megastore, Spanner, etc. And sure, ZooKeeper or etcd makes sense for putting small amounts of configuration data.
But most of us aren't Google, and synchronously replicating the entire OLTP database, 3 or 5 nodes times the number of shards, seems kind of absurdly expensive for most people.
Having experienced slight feelings of melange/detachment following novels, video games, and movies in the past, and having experienced what this article is describing: it's not quite the same feeling.
With movies/novels/etc., I've always experienced what you're describing as something similar to a feeling of loss--the world you experienced or the story you were involved in or the characters you cared about will no longer be there as a new experience, no longer have new experiences as characters, etc. That 'world' is gone.
With VR, even if I don't really miss the experience, I've experienced what I'd describe as a "readjustment" phase of between 10 minutes and a couple hours (depending on length of experience and how recently I'd been in VR) where the real world feels disconnected/less real. It's a much more intense and visceral feeling, and doesn't have the same undertone of 'loss' that movies/novels have. It isn't a "Man, I'm not actually a space pilot in the year 3000" feeling, or a "I'll never be able to experience that world again" feeling, it's more of a visceral disassociation from the real world, as though my senses don't feel like they can quite trust the inputs they're receiving anymore.
"If it ain't broke, don't fix it." goes for attacks, too.
Why spend weeks/months searching for 0-days and hoping they will remain viable when you can spin up a fake login page and a bit.ly, find the people to target and send the targeted emails in a couple of days, max?
> Two layers is at least as secure as a single one of either layer.
This is not uniformly true for cryptosystems--it is not naively the case that P(Q(X)) is a secure form of encryption, just because P/Q is. A contrived example is when P and Q are inverses (so P(Q(X)) is plaintext), but it should be obvious that if P has the wrong interaction with Q it might make some of the message easier to attack.
> The question is whether it will hurt, and the answer is that it does not. Again, this is common sense.
It can hurt. It's subtle, but consider if a hash in the middle has a distribution issue (extreme case--hash in the middle maps everything to 0, now your entire hash stack is broken). In short: stacked hashes are no stronger than the first hash in the sequence (collision there = collision in the stacked algorithm) and have the potential to be weaker.
> This is not uniformly true for cryptosystems--it is not naively the case that P(Q(X)) is a secure form of encryption, just because P/Q is. A contrived example is when P and Q are inverses
If P and Q are inverses, then Q is not secure, because you could just apply P to its output.
The same holds true for encryption: if you have two independant keys K1 and K2, then if Mallory can crack P(Q(X, K2), K1), then she can crack Q(X, K2) just by picking a K1 at random and computing P(Q(X, K2), K1).
> A contrived example is when P and Q are inverses
I feel like you should already realize this (in which case I don't get why you're posting the comment), but while that's a cute mathematical existence proof, it's totally irrelevant as it's not something that can just happen out of the blue. Ciphertext looks random; you can't just reverse randomness without having the key/seed. So that's impossible in practice unless you've either somehow (a) broken the crypto, or (b) used related keys for both algorithms (which is obviously stupid and not something you would do if you thought about this for 5 seconds) or (c) something else silly along those lines, all of which even rudimentary knowledge of cryptography (or one might even argue, common sense) would prevent.
> It can hurt. It's subtle, but consider if a hash in the middle has a distribution issue
I don't know when you read my comment, but I edited it (I think) some ~15 minutes before you posted your comment to clarify that I wasn't referring to stacking arbitrary hashes. Read it again. I was referring to stacking hashes that are already thought to be cryptographically secure.
> I don't know when you read my comment, but I edited it (I think) some ~15 minutes before you posted your comment to clarify that I wasn't referring to stacking arbitrary hashes. Read it again. I was referring to stacking hashes that are already thought to be cryptographically secure.
It still doesn't make a difference in my argument. My point is that you gain no added strength via a stacked hash implementation because it's as weak as the first hash in the sequence, and that it is potentially worse because you can also attack it via attacks on later hashes in the sequence.
A stacked hash is as weak as the first hash in the sequence--this should be obvious. A collision in the first hash function will obviously cascade into all later ones, so your stacked hash function is as weak, or strong, as the first hash function. That means you gain no strength.
What I was showing via an obvious/contrived example (to keep the math easy) was that it is also possible to attack a stacked hash via weaknesses in later hashes in the sequence. I wasn't (I thought obviously) implying that you'd intentionally choose a hash that was weak for a middle one--but there are all sorts of hashes we once thought were secure that we don't think are secure anymore.
> I feel like you should already realize this (in which case I don't get why you're posting the comment), but while that's a cute mathematical existence proof, it's totally irrelevant as it's not something that can just happen out of the blue.
Fundamentally, all modern crypto relies heavily on math. I made a "cute mathematical existence proof" to make it obvious how stacking ciphers can weaken an encryption system. The reality is that exactly how ciphers interact is a subtle and hard to measure point, but it isn't safe to assume that composing cryptosystems will be as secure as either cryptosystem on its own, because features of the two systems could interact to weaken the overall security of the cryptosystem.
> It still doesn't make a difference in my argument. My point is that you gain no added strength via a stacked hash implementation because it's as weak as the first hash in the sequence
God, I wish really I could downvote replies.
Nobody said you should be applying the hash functions in sequence. There are at last 3 obvious approaches: (1) applying the functions sequentially, (2) concatenating their outputs, (3) XORing their outputs. None of these takes rocket science to figure out, and some 5 seconds of thinking would easily rule out #1 and #2 as inferior to #3.
Honest question: did you even spend 5 seconds actually thinking about what I wrote before deciding I must be wrong? I'm not sure if you realize this, but when you reply so confidently without thinking, you (and many others) active harm the whole field of infosec. I'm so frustrated and fed up with you and so many other people's overconfidence and lack of willingness to think for 5 seconds when it comes to cryptography.
>> I feel like you should already realize this (in which case I don't get why you're posting the comment), but while that's a cute mathematical existence proof, it's totally irrelevant as it's not something that can just happen out of the blue.
> Fundamentally, all modern crypto relies heavily on math. I made a "cute mathematical existence proof" to make it obvious how stacking ciphers can weaken an encryption system
Again: are you reading and thinking? Or are you just writing?
You're simultaneously literally claiming that two secure ciphers can be combined to result in an insecure cipher when their keys are generated independently. This is far more astonishing than the claim that the ciphers you're using are actually secure in the first place. You're already accepting the latter despite any sort of proof, yet you're bothered by the former? Hell, you haven't even shown shown this is possible for any pair of secure ciphers; your "example" was missing the most crucial part of the cipher -- the key. The whole argument is so crazy it's just utterly ridiculous.
> here are at last 3 obvious approaches: (1) applying the functions sequentially, (2) concatenating their outputs, (3) XORing their outputs. None of these takes rocket science to figure out, and some 5 seconds of thinking would easily rule out #1 and #2 as inferior to #3.
This is wrong. Concatenation would be harder to attack than XOR. Finding two things which hash to to two particular values in two separate hash functions is necessarily harder than finding two things which will hash to values which will XOR to the same value--almost a priori. You replace a double collision (across two hashes) which is very unlikely with an XOR collision, which is going to be exponentially easier.
> You're simultaneously literally claiming that two secure ciphers can be combined to result in an insecure cipher when their keys are generated independently. This is far more astonishing than the claim that the ciphers you're using are actually secure in the first place.
Since you seem to want practical examples on recent crypto: consider meet in the middle attacks on 2DES as an example of why combined cryptosystems are not necessarily as strong as you'd imagine. It's admittedly a weak example--still stronger than 1DES, and an old system. Fundamentally, combining cryptosystems, even with separate keys, gives you a new cryptosystem which requires separate analysis.
> Hell, you haven't even shown shown this is possible for any pair of secure ciphers; your "example" was missing the most crucial part of the cipher -- the key. The whole argument is so crazy it's just utterly ridiculous.
If I had a good attack on RSA + ECC, I'd be writing a paper about it. I'm gonna posit that if that's the kind of proof you want to believe you're "wrong", you'll remain happily "correct" in this scenario.
> This is wrong. Concatenation would be harder to attack than XOR. Finding two things which hash to to two particular values in two separate hash functions is necessarily harder than finding two things which will hash to values which will XOR to the same value
No, you're the one who's wrong. You're assuming the hash is secure and then trying to brute-force it. But the entire discussion is not about brute force; it's about when an adversary breaks the hash, i.e. one who is able to produce multiple inputs with the same hash much more quickly than with brute force. This means they can attack the hashes independently, whereas if you XOR, they can't do that. Heck, if you XOR, the probability that they'll be able to tell which algorithms you used already becomes astronomically low, let alone them breaking it.
> Since you seem to want practical examples on recent crypto: consider meet in the middle attacks on 2DES as an example of why combined cryptosystems are not necessarily as strong as you'd imagine.
Again, you're wrong. You said you were "making it obvious how stacking ciphers can WEAKEN an encryption system". All you proved is that it isn't twice as strong. I never claimed nor even imagined that it was twice as strong. I merely claimed that the probability of it being WEAKER is astonishingly lower than the probability of the crypto layers being strong in the first place. Why do you keep changing your arguments?
>> Hell, you haven't even shown shown this is possible for any pair of secure ciphers; your "example" was missing the most crucial part of the cipher -- the key. The whole argument is so crazy it's just utterly ridiculous.
> If I had a good attack on RSA + ECC, I'd be writing a paper about it. I'm gonna posit that if that's the kind of proof you want to believe you're "wrong", you'll remain happily "correct" in this scenario.
Way to keep changing the topic just to win the argument. I just pointed out that your counterexample ciphers didn't even have independent keys, for God's sake!! Instead of accepting that you made silly mistake, you're spreading meaningless FUD. Why can't you just accept you made an error instead of giving me this nonsense? Are you just a troll? If you keep trolling don't expect me to respond.
If you have a combined hash that is XYZ = weak_hash(m) XOR strong_hash(m), then you still have a birthday collision attack available. Just keep permutating the message in various ways, and in 2^(hash length / 2) operations you have two identical hashes with different inputs.
Edit: yes, this isn't new, but it is strictly weaker than to append the two hashes. It increases the difficulty as you have two hard targets you must hit with the same input, vs one target, which may even be weakened.
You're also assuming the hashes are fully uncorrelated. If the designs are similar, there could be a correlation between the two which biases the output, such that some bits often will be the same or different in certain ways. This can drastically reduce the number of possible outputs in known ways, and could even enable cryptanalysis to break it faster than bruteforce if part of the weaker hash counteracts parts of the other.
You also forgot timing attacks and other sidechannels in layered encryption.
> If you have a combined hash that is XYZ = weak_hash(m) XOR strong_hash(m), then you still have a birthday collision attack available. Just keep permutating the message in various ways, and in 2^(hash length / 2) operations you have two identical hashes with different inputs.
You understand what "good enough" means, right? Brute force is irrelevant if your hashes are long enough (e.g. say, 256 bits). Again, like the other guy, you're confused: we're trying to guard against broken hashes, not brute force attacks. Brute force attacks are trivial to guard against just by changing the length.
> Edit: yes, this isn't new, but it is strictly weaker than to append the two hashes. It increases the difficulty as you have two hard targets you must hit with the same input, vs one target, which may even be weakened.
I thought I already explained this, but I'll explain it again.
For a brute force attack, sure, it's weaker. But like I said, that's already trivial to guard against already, so that's irrelevant.
For a broken hash, it's MUCH STRONGER, since in the concatenation case, both hashes can leak information about the input (meaning breaking one can help break the other), whereas in this case it's the opposite: the adversary won't get any information about the input unless he breaks both hashes simultaneously.
You're thinking about the problem wrong.
> You also forgot timing attacks and other sidechannels in layered encryption.
Somebody already mentioned this in another comment chain. I initially thought of it but then forgot it, yeah. But it's just something to watch out for, not an argument for not doing it in the first place. It's also trivial to guard against if you apply a standard layer first (which doesn't preclude applying another standard one last, and putting your own layer in between).
Common sense is not so common. I would certainly find it very useful if the cryptographic community developed best practices for how to stack algorithms.
> Common sense is not so common. I would certainly find it very useful if the cryptographic community developed best practices for how to stack algorithms.
Here's the list of best practices for encryption:
1. Have at least one well-established & accepted cipher (e.g. AES).
2. Generate the keys for all the layers independently.
> There are more points to consider than that. For instance, which order should you apply the ciphers in?
No. The order shouldn't make any difference unless for some reason you're sending extra data in cleartext that is encrypted with one cipher but not the other. This is because the output of the standard cipher (e.g. AES) would look random, so that implies the final output must look random, and hence they won't be able to tell there's another layer on top just based on the order of the ciphers. That is, unless they've already broken the other standard cipher (in which case now you're only dealing with the custom layer regardless). If the final output isn't random, it means you're partially reversing the standard crypto, which, as I said above, cannot happen unless you've broken the crypto or avoided using independent keys.
Edit: I suppose the theoretically optimal thing to do may be to apply the standard cipher last, to absolutely, positively ensure that the adversary is forced to break that before they even know you have another layer underneath (to avoid parallelizability of breaking both). I can't imagine this ever being worse. But at this point we're talking about theoretical optimality; from a practical standpoint I don't see this mattering. But at the same time since I don't have an argument for doing it the other way, you might as well always do it this way.
I would suggest the standard cipher first. Because, if the home brewed one is used first, it may leak information over side channels.
Another concern is that if the home made cipher creates a cipher text with differing lengths depending on the content of the plain text, the standard cipher will not be able to obscure that length.
> I would suggest the standard cipher first. Because, if the home brewed one is used first, it may leak information over side channels.
Ahh! I remember realizing this once but then I completely forgot about it. It's a good point, thanks for mentioning it. The thing to note here though is that the only side-channel attack here is the time taken for the encryption to occur, since we're talking about networks (and not physical penetration of the system's environment)... which is admittedly nontrivial to defend against with modern CPUs, but which is not quite as hard to do as it might seem, if by side channel people think of the same thing I normally do (e.g. E/M waves from the monitor or something).
So maybe apply a standard layer initially, add your custom layers, then top it off with another standard layer?
> Another concern is that if the home made cipher creates a cipher text with differing lengths depending on the content of the plain text
I guess I assumed it was obvious you would never do this because it's common sense if you know even basic cryptography, and as far as I know, this is literally the only possible failure mode with regards to information leakage in the ciphertext itself, so it's not like you have to worry about other similar situations either. (But do correct me if I'm wrong.)
The odds that your homegrown function is an inverse to the dank-dispensary-function you've layered below it are as low as somebody cracking dank-func without insider knowledge. Dank-func would be worthless in all situations if it were the case.
Unless state-actor is willing to spend time decrypting homegrown-func, you have succeeded.
I'd argue that they pretty clearly are different, if you're talking about generic laziness-as-a-quality versus subject specific laziness.
Someone who isn't interested in school might be willing to work very hard at improving in a sport, or work very hard on their extracurricular club, or work very hard to teach themselves assembly and programming, or to learn a musical instrument. They might even be willing to work hard to teach themselves math, but be uninterested in putting effort into math class.
I guess it depends on if you consider "laziness" a universal character quality or not.
This really needs to be emphasized--if you cannot agree on what the facts are, you will never come to a real conclusion. This is something the article completely glosses over. However, I also I think there's also something beneath just agreeing on what constitutes facts that is equally important, which is a (roughly) shared value system.
The old, "liberally educated" world that the author references the death of in the 1960s (i.e. "Closing of the American Mind") was one of shared values--largely white, protestant values. What replaced it was a different value system--I've seen it called the "meritocratic" value system, or similar--which had fundamentally different core values, and was/is dominant among American conservatives and liberals until recently.
Currently, the furthest left and furthest right often don't agree on core values. On the left, I think almost any argument that uses a variation on "(holy text) said so" can be dismissed off-hand as an unconvincing argument when you're talking about things beyond your own personal behavior--however, my Mormon relatives feel quite differently. This gets uglier and further away from the mainstream when you start to dig into some of the belief systems that groups on the alt-right propose (simplifying, but often things like "only white people have intrinsic value"), as opposed to the mainstream belief systems of the last ~40 years ("all people have intrinsic value"). Similarly on the far left, I've seen a lot of disagreement with other things that I'd hold up as mainstream values of the last 40 years (such as "competition between independent actors leads to good outcomes for consumers*").
Disagreements when fundamental values differ will put any argument on hold before it gets started, and I expect the only real outcome is things that devolve into shouting matches, or worse. And from what I've seen, the range of acceptable values has widened dramatically in the last 15 years--I'm curious to see if this winds up coalescing into a new set of mainstream values after a while, or if things like the structure of the internet/"filter bubbles"/increased ideological splits will mark the end of an ideological "mainstream" as it used to exist.