Which in this case is those trying to discredit the investigation. They not only need to prove that there was something improper about the warrant, they also need to prove that the alleged impropriety of the warrant is relevant to the Mueller investigation. Neither of those things has been even substantiated, much less proved.
I can't go somewhere and pay for my coffee by directly handing over 20 shares of BigCorp. I can go places and pay directly using crypto.
Where can you buy coffee directly with cryptocoins? Not with some dollar-denominated debit card that is backed by an account containing cryptocoins... directly with cryptocoins? I don't think you actually can.
As others have said, though, there's absolutely no reason you couldn't do the same with stock. It's just not commonly done.
If you allow the coin-backed, dollar-denominated debit card in your definition of "paying with coins" then I not only can do that with stock, I do it regularly. I have a brokerage account that gives me a debit card and draws on my margin account, which is backed by the stocks and mutual funds I own. My account is more transparent about what's going on that the cryptocoin-backed equivalent, in that it's clear that what I'm actually doing is borrowing money against assets while the other tries to make it appear that the cryptocoins are being spent directly, but that doesn't change the fundamental equivalency.
That said, I also don't believe cryptocoins are securities. To be securities, there has to be ownership of something of some intrinsic value, even if it's abstracted several layers. Cryptocoins that are actually useable as currencies (not BTC) are currencies. The best analogy for BTC at this point is "Ponzi scheme".
It's an honest question. I'm curious what someone who analyzes and thinks about identity politics on one side thinks about how the other side applies the same concept. I have my own opinion, obviously, which is that both sides focus far too much on tribal identities and not enough on substantive issues, but I'm curious about the opinions of others.
Not by much though. My car goes close to 1000 MPH and its an economy class. Hell, every 24 hours it travels the circumference of the earth. It should at least win the 24 hour LeMans endurance.
Not by much? Musk's car is going to be accelerated to approximately 25,000 mph. If things go well. If they don't, small pieces of it may reach even higher velocities.
" And auto is much better than having to remember the exact type of an object. "
No, it really isn't. Auto is just a nasty hack that allows variable types to be defined on the fly which is fine for a scripting language written by beginners but has no place in a professional system level language. Its for lazy coders who don't really have a full grasp of the codebase they're working on. Any autos I see in code are ripped out and if any of my team use them they get told to sort it out or I get someone else to do it.
Especially when you later decide to change the type of v because a different container class is more efficient in some relevant way in this case. Yeah, you can paper over this with typedefs (or type aliases), but no type specification for citer is actually going to be clearer, because everyone knows that citer has to be a const iterator over v.
There are situations in which explicitly specifying the type enhances clarity, situations in which it's neutral, and situations in which it makes the code less readable, due to lots of unnecessary syntactic complexity to mentally parse. When to use or not use "auto" is a decision that should be made with the reader in mind. Any rule specifying that it must always or never be used is foolish and counterproductive.
Like many features in every language -- and especially in C++, which is chock full of them -- "auto" can easily be overused. I've read code that made me go look up function prototypes to figure out what types variables were, because every return value was assigned to an "auto" variable. That's bad code. Even worse is non-trivial functions that return auto (C++14's return type deduction) and force me to find return statements and trace back the type of the variable returned, which itself may have been declared as "auto"!
But the fact that a feature can be abused doesn't make it bad or useless. It just means that it should be used thoughtfully and appropriately, when it helps clarity.
Cleanly compiles, and helpfully does nothing at all. What's not to like?
Nice:-)
Though I have to admit I quite like modern C++, and lambdas, and even the lambda syntax. And I find [](){}(); instantly understandable. But it's still quite funny.
So you stopped using the words "master" and "slave" because you had a black colleague?
My God, where's that meteor when we need it?
You're right. Tablizer shouldn't have waited until he was working with a black colleague to recognize that "primary" and "secondary" (or, even better, "replica") were both more accurate and less potentially offensive. But, hey, we're only human. At least he did recognize it when brought face to face with the potential offense.
When a language is gleefully throwing away well understood, well used terms
You mean vague, poorly-defined terms. Master/slave is used in many different contexts, where the "master" and the "slave" have very different sorts of relationships. In the case of databases, for example, "active" and "replica" are much more accurate and informative. In the case of build systems (the context in the linked discussion), "coordinator" and "worker" are better.
If it were a case where there really were no better terms that don't also carry racial baggage, I guess you might have a point. But with respect to master/slave, there's almost always an alternative pair of words that is clearer and more informative in addition to less politically problematic.
(Also, this discussion has nothing to do with the language, it's a thread about build infrastructure. Precision and clarity in language are valuable characteristics for programmers.)
When I'm rough-around-the-edges and talk/joke around as such, where's the tolerance for ME?
Yeah, that's where it breaks done, doesn't it.
Tolerance is a mutual agreement, a contract if you will, not a moral obligation. If you don't want to sign onto the contract, fine, but don't expect those who do to apply its terms to you. In fact, expect them to attack you mercilessly if they can't simply eject you. If you want to be protected by the agreement, you have to abide by it. It's like a peace treaty of sorts.
I'll certainly grant that the concept of tolerance is sometimes applied to stifle simple disagreement that is not actually intolerance, and that's wrong, and those cases should be called out. But most of the time it's a good idea -- and honestly it's pretty easy to do if you just broaden your horizons a bit.
Good luck when you're stopped by the police/military in some shit-hole country. Encrypted files? No problem, just beat them until they decrypt.
It's easy enough to use an asymmetric encryption algorithm, with the private key stored on a computer in another country. Won't save you the beating, but assuming they actually need proof to keep you in prison (a big, big "if" in the countries where you might feel like you need encryption, and in which the authorities are willing to use rubber hose cryptanalysis), they'll be unable to get it.
If necessary, you could even use jurisdictionally-diverse key splitting. The idea is to pick a handful of mutually-antagonistic countries who are unlikely to be willing to cooperate with one another to recover your key, then cryptographically split your private key (perhaps with an m-of-n technique to give yourself some redundancy) and store one piece in each of them.
Protecting your data from the authorities is totally feasible. Protecting yourself... maybe not so much.
Interesting. But it should be pointed out that the implementation is very badly done from a security perspective. I only spent a few minutes looking at it and found several showstoppers in both design and implementation. Among them:
1. The basic file encryption algorithm is a stream cipher construction using a simple LFSR as the stream generator. This is almost certainly trivial to break; standard LFSRs are in no way designed for cryptographic security. I suspect the LFSR was used for performance, and I'm sure it does in fact perform much better than, say, AES in CTR mode (where AES is used to generate a bitstream XORed with the plaintext in the same way the LFSR output is). While no good stream cipher is likely to match the LFSR performance, there are several that would provide moderate performance and high security, such as ChaCha20 -- or perhaps even a reduced-round variant like ChaCha12 or even Salsa20/12.
Note that someone has contributed an XTEA implementation which is much better, security-wise, than the LFSR but actually slower than AES. If you're going to do that, just use AES.
2. Even if the LFSR-based encryption algorithm were good, it uses 64-bit keys, which is just too small. Oddly enough, when you use the provided RSA mode for asymmetric write-only encryption (decryption can only be done on your PC), the author seems to recommend a 4096-bit RSA key size, which is roughly equivalent to a ~160-bit symmetric encryption key, and which is quite slow. It makes no sense to use such a huge, slow RSA key to protect small symmetric keys.
3. Password hashing uses the same LFSR plus some shifting and masking. Almost certainly insecure, and there's really no reason at all not to use a good password hashing algorithm like Argon2, or at least scrypt.
4. In asymmetric mode, the code appears to use random padding for RSA operations. There are really good reasons for the PKCS#1 v1.5 and RSA-OAEP padding modes that are normally used. It's possible that a very careful analysis of this implementation may show that under certain operational assumptions random padding is okay... but I seriously doubt that any such careful analysis has been done. I would never bother doing anything of the sort and would simply use OAEP. (Or, better yet, avoid RSA and instead use an elliptic curve algorithm -- less tricky to use correctly, faster, smaller keys and even the provides possibility to derive keys from passwords. There's really no reason to use RSA for anything anymore unless you have to interoperate with legacy infrastructure that already uses it.)
5. RSA key generation is done on-device, with the private key written to the SD card, then later deleted. You can't actually delete things from SD cards, not with any confidence. Much better to do keygen off device so only the public key ever exists on the SD.
6. A glance at the RSA key generation code throws up a number of red flags. I suspect the key generation is buggy.
7. I didn't find the random number generator, but given all of the above, I'd be shocked to find that it's actually good. A bad RNG can easily destroy the security of the best cryptographic design.
When I get some time (ha!) I'm going to see if I can get ML running on my 70D and hack together a better version, using Curve25519 ECDH and ChaCha20 with 128-bit keys, with asymmetric keygen done off-device, and a decent PRNG plus the best seeding mechanism available. To make it more usable, I'll see if I can keep the last few dozen per-file keys in RAM, which will allow the photographer to look at the images on the camera, until the camera is turned off. More paranoid users should be able to disable the retention of keys in RAM.
Sounds like a fun project. One which I may or may not get to before 2025 or so...
I'm not sure if this is better or worse than the other misspelling of "cojones" that I often see, which is "cajones" (meaning "large boxes", usually referring to drawers in dressers and cabinets).
Google can do it because they are atypical. It is no indicator that, say, a bank or a hospital can do the same.
Google can do it from scratch because they are atypical. I agree that a bank or hospital absolutely could not build all of the necessary infrastructure to do it, but that's no longer necessary. Google's BeyondCorp program is one of several "vendors" (I believe Google's stuff is all open source) that provide the necessary proxy software and related bits, and it will get easier over time.
On the actual subject, if you really want every system to be individually administrated and fully secured, then go ahead and run this model. For a small network, with, say, less than ten computers this may even work.
FWIW, Google does this with a very large and complex network (100K+ employees). Google has taken the next step beyond this, actually, and recognized that once you have ensured you don't extend any trust to your internal networks, there's no reason to treat external networks as less secure. (See https://www.beyondcorp.com/).
The solution to the problem you mention is standardization. Specifically, standardize all of your internal applications on web interfaces. Once everything is a web site, then you can stand up a set of proxies that provide secure tunnels to the application servers. So every connection to every server goes through the proxy servers first. TLS is used from client to proxy and from proxy to app server, obviously. The proxies do all of the authentication of client device and user, and much of the authorization checking as well. The proxy server adds some headers with the user's identity, including any relevant LDAP groups the user is in. The application servers are configured to accept connections only from proxy servers (proxies present client certs) and can simply trust the contents of the headers to provide accurate user and group IDs, in case they need to do fine-grained authorization.
With some client and server-side utilities this can be made to work even for third-party applications which are not and cannot be made to be web applications. The client app is coerced into connecting to a local socket provided by the client-side utility, which in turn tunnels the data through a TLS connection to the proxy, which tunnels it through another TLS connection to the server-side utility, which then delivers it to the actual server. With some customization the server-side utility can even do whatever sort of authentication the server wants as well.
Not only does this model make a zero-trust network practical, it also provides enterprise-wide single-sign on, and provides a single point for auditing the operation and usage of all internal web apps. Note also that it's not necessarily incompatible with perimeter defense. You can do that, too, if you want. But with a zero-trust infrastructure in place, perimeter defense truly becomes an additional defense-in-depth layer (assuming you don't add any proxy rules of the form "If connection from within perimeter, then don't require auth").
his criminal activity
Please define his criminal activity that he has committed under NZ law.
Well, New Zealand is a signatory to the Berne Convention and a member of the World Trade Organization, which not only means that New Zealand honors US copyrights (and vice versa), but that the countries have certain reciprocal obligations around enforcement.
And although I haven't followed it closely, as I recall the NZ High Court endorsed Dotcom's extradition to the US last year. OTOH, that doesn't mean everything else the NZ police did was legal or correct, and their overreaching and screwups are the basis for this lawsuit.
I'd liken it to, when you were a kid, and you had a gripe/complaint about your parents. You'd have to petition your parents for a change of rules or procedures.
If only there were a separate but co-equal someone to your parents you could petition for redress of your grievances.
There is (in the traditional family, at least). If Dad won't listen, you go to Mom, or vice versa. Of course, Mom and Dad generally have a very similar perspective, and have strong reasons to be closely aligned. Like branches of the government.
I honestly can't decide which is worse - Dotcom winning or the American bullies winning. It's a no-win situation from my perspective.
How about: the Rule of Law winning? Documented norms that apply to everyone from the bum on the street corner to Bill Gates are a win for everyone.[1]
In this particular case, it means that New Zealand should have followed its own laws, procedures and the treaties to which it is signatory without regard to political pressure brought by the United States. If those laws indicated that Dotcom should be arrested and extradited, well and good. If, as appears to be the case, New Zealand authorities violated their own laws, then Dotcom deserves compensation. I seriously doubt that he deserves 6.8B NZD. In an ideal outcome he ends up exactly where he would have without the illegal police action, which isn't "winning" it's "not losing".
[1] Yeah, everyone knows that the bum on the street corner and Bill Gates do not get treated the same way, but that just means it's an aspirational goal toward which we should work, not something we should cynically laugh off. The further we are from it, the more seriously we need to take it and the more strongly we need to react when our appointed representatives fail to execute it.
I still don't see a use for a smartphone - I'd take a feature phone with Audible and Kindle if one existed.
And virtually every other user just needs a feature phone plus their particular set of needs.
The same is true of computers of all sorts. The value in a programmable computer for the typical person isn't that it will do everything, because the typical person doesn't do everything. It's that it will do all of the small set of things the person needs to do... whatever those things might be.
This. It seems that the guy who left doesn't seem to understand this
Other than the relatively small part of the company that is focused on selling and delivering ads, basically nobody in Google thinks of users as the product. Everyone thinks of end users as the customer, regardless of the fact that 90% of dollars actually flow from advertisers.
Living paycheck to paycheck has little to do with income and a lot to do with spending. I know people making $200K per year and living paycheck to paycheck. I know people making $30K per year who have healthy savings.
True, but there is a limit. If you pay $500/month rent, that's 6K a year. Big chunk of that 30K just for one thing. And many places don't have rents or house payments that low. Add a car, utility bills, phone bills, and there's not much left. Then the car breaks, your roof leaks, you get sick. You're in trouble even if you haven't screwed up financially.
True, there is a limit -- and the fact that getting sick can destroy people is a serious problem that we need to fix. But the car breaking, the roof leaking... those actually shouldn't screw you unless you get several such shocks in quick succession. The key is that whatever your income level is, you need to live on less than that, and save the rest. If you budget to save 20% of your income and live on 80%, you can build up a cushion so a few shocks are survivable.
If it's simply not possible to live on 80% of your income, then you have a serious problem. And by "not possible" I mean there's no way to scale back your lifestyle -- live in a smaller place, drive a cheaper car, lower your utility or phone bills, etc. But the majority of lower-middle income Americans are not in that situation.
Living paycheck to paycheck has little to do with income and a lot to do with spending.
Sounds like the "up from your bootstraps" mantra.
Nonsense. It's certainly true that there is an income level below which things become impossible. But that is actually not the case for most people in the middle and lower-middle class in the United States.
Bourgeoisiesplaining to the poor is incredibly obnoxious.
And so is inventing assholish words like "Bourgeoisiesplaining", as is using them with people who didn't come from anything remotely like "Bourgeosie". I'm also not talking about those who are actually poor, but the large majority who do have enough to live, but just don't manage it well.
Please actually read what I write, rather than just writing me off as clueless. I come from a poor family, not a wealthy one. My father grew up in serious poverty -- five kids in a single bed sort of poverty. I grew up in a lower middle class lifestyle (we qualified for and received government assistance, like free school lunch, government cheese, etc.). I'm moderately wealthy, but the only one of my five siblings who is.
I find it very interesting that among my own relatives who are lower-middle income and lower-income it's consistently those who pay 10% of their small income to the church in tithing who are the most economically stable. Given two families, both with total incomes of less than $40K, the one that gives 10% of that meager income away every paycheck is better off -- not only doesn't live paycheck to paycheck, but actually has more/better stuff. How can that possibly make sense?
It works that way for two reasons. The first is that the family that pays tithing does it by assuming at the outset that a chunk of their income isn't available for spending. They have been taught to "first pay the Lord, then pay yourself, then spend what's left". So they pay 10% to the church, put 20% in savings, and figure out how to live on whatever is left. The 20% in savings means that they almost always have a cushion. The second is that that 10% paid in tithing in some sense represents an emergency fund of last resort. If all of the savings is exhausted, they can choose not to pay tithing for a month or two. This almost never happens, though.
The bottom line is that the tithe-payer's choice to live on 70% of their income provides a level of elasticity that allows them to make better choices. When the old car breaks down again, they have the money to fix it without having to pawn stuff or take extortionate payday loans -- or worse, not be able to fix it. I have one relative who wrecked their car and was then unable to go to work, dropping their income to nothing. (I actually paid for the repairs when I heard about it, but without that family "safety net" they'd have been in serious trouble.) When it's obvious that someone is going to need new shoes in a few months, and shoes are on sale now, there's money to buy the sale-priced shoes now rather than buying them at full price when it becomes impossible to wait any longer. And so on.
Your economic situation is a function of two factors, your income and your choices about how you spend it. Except in cases of true poverty, boosting income without also focusing on choices almost never results in greater economic stability, it just increases expenditures. On the other hand, focusing on making better choices nearly always increases stability and, over the course of a few months or years, increases standard of living as well.
Slashdot Mirror
The burden of proof is on the accuser.
Which in this case is those trying to discredit the investigation. They not only need to prove that there was something improper about the warrant, they also need to prove that the alleged impropriety of the warrant is relevant to the Mueller investigation. Neither of those things has been even substantiated, much less proved.
I can't go somewhere and pay for my coffee by directly handing over 20 shares of BigCorp. I can go places and pay directly using crypto.
Where can you buy coffee directly with cryptocoins? Not with some dollar-denominated debit card that is backed by an account containing cryptocoins... directly with cryptocoins? I don't think you actually can.
As others have said, though, there's absolutely no reason you couldn't do the same with stock. It's just not commonly done.
If you allow the coin-backed, dollar-denominated debit card in your definition of "paying with coins" then I not only can do that with stock, I do it regularly. I have a brokerage account that gives me a debit card and draws on my margin account, which is backed by the stocks and mutual funds I own. My account is more transparent about what's going on that the cryptocoin-backed equivalent, in that it's clear that what I'm actually doing is borrowing money against assets while the other tries to make it appear that the cryptocoins are being spent directly, but that doesn't change the fundamental equivalency.
That said, I also don't believe cryptocoins are securities. To be securities, there has to be ownership of something of some intrinsic value, even if it's abstracted several layers. Cryptocoins that are actually useable as currencies (not BTC) are currencies. The best analogy for BTC at this point is "Ponzi scheme".
It's an honest question. I'm curious what someone who analyzes and thinks about identity politics on one side thinks about how the other side applies the same concept. I have my own opinion, obviously, which is that both sides focus far too much on tribal identities and not enough on substantive issues, but I'm curious about the opinions of others.
He thinks SJW's and their identity politics are really similar to the marxist ideology that caused so much suffering in Russia.
What does he think about Trumpians and their identity politics?
Normal orbit is 17,500 MPH, is this one out more?
It's being launched into solar orbit, not Earth orbit.
Not by much though. My car goes close to 1000 MPH and its an economy class. Hell, every 24 hours it travels the circumference of the earth. It should at least win the 24 hour LeMans endurance.
Not by much? Musk's car is going to be accelerated to approximately 25,000 mph. If things go well. If they don't, small pieces of it may reach even higher velocities.
" And auto is much better than having to remember the exact type of an object. "
No, it really isn't. Auto is just a nasty hack that allows variable types to be defined on the fly which is fine for a scripting language written by beginners but has no place in a professional system level language. Its for lazy coders who don't really have a full grasp of the codebase they're working on. Any autos I see in code are ripped out and if any of my team use them they get told to sort it out or I get someone else to do it.
Right, because:
std::vector<int>::const_iterator citer = v.cbegin();
is better than:
auto citer = v.cbegin();
Especially when you later decide to change the type of v because a different container class is more efficient in some relevant way in this case. Yeah, you can paper over this with typedefs (or type aliases), but no type specification for citer is actually going to be clearer, because everyone knows that citer has to be a const iterator over v.
There are situations in which explicitly specifying the type enhances clarity, situations in which it's neutral, and situations in which it makes the code less readable, due to lots of unnecessary syntactic complexity to mentally parse. When to use or not use "auto" is a decision that should be made with the reader in mind. Any rule specifying that it must always or never be used is foolish and counterproductive.
Like many features in every language -- and especially in C++, which is chock full of them -- "auto" can easily be overused. I've read code that made me go look up function prototypes to figure out what types variables were, because every return value was assigned to an "auto" variable. That's bad code. Even worse is non-trivial functions that return auto (C++14's return type deduction) and force me to find return statements and trace back the type of the variable returned, which itself may have been declared as "auto"!
But the fact that a feature can be abused doesn't make it bad or useless. It just means that it should be used thoughtfully and appropriately, when it helps clarity.
And now, we have a language for which the code
[](){}();
Cleanly compiles, and helpfully does nothing at all. What's not to like?
Nice :-)
Though I have to admit I quite like modern C++, and lambdas, and even the lambda syntax. And I find [](){}(); instantly understandable. But it's still quite funny.
So you stopped using the words "master" and "slave" because you had a black colleague? My God, where's that meteor when we need it?
You're right. Tablizer shouldn't have waited until he was working with a black colleague to recognize that "primary" and "secondary" (or, even better, "replica") were both more accurate and less potentially offensive. But, hey, we're only human. At least he did recognize it when brought face to face with the potential offense.
When a language is gleefully throwing away well understood, well used terms
You mean vague, poorly-defined terms. Master/slave is used in many different contexts, where the "master" and the "slave" have very different sorts of relationships. In the case of databases, for example, "active" and "replica" are much more accurate and informative. In the case of build systems (the context in the linked discussion), "coordinator" and "worker" are better.
If it were a case where there really were no better terms that don't also carry racial baggage, I guess you might have a point. But with respect to master/slave, there's almost always an alternative pair of words that is clearer and more informative in addition to less politically problematic.
(Also, this discussion has nothing to do with the language, it's a thread about build infrastructure. Precision and clarity in language are valuable characteristics for programmers.)
When I'm rough-around-the-edges and talk/joke around as such, where's the tolerance for ME?
Yeah, that's where it breaks done, doesn't it.
Tolerance is a mutual agreement, a contract if you will, not a moral obligation. If you don't want to sign onto the contract, fine, but don't expect those who do to apply its terms to you. In fact, expect them to attack you mercilessly if they can't simply eject you. If you want to be protected by the agreement, you have to abide by it. It's like a peace treaty of sorts.
I'll certainly grant that the concept of tolerance is sometimes applied to stifle simple disagreement that is not actually intolerance, and that's wrong, and those cases should be called out. But most of the time it's a good idea -- and honestly it's pretty easy to do if you just broaden your horizons a bit.
Good luck when you're stopped by the police/military in some shit-hole country. Encrypted files? No problem, just beat them until they decrypt.
It's easy enough to use an asymmetric encryption algorithm, with the private key stored on a computer in another country. Won't save you the beating, but assuming they actually need proof to keep you in prison (a big, big "if" in the countries where you might feel like you need encryption, and in which the authorities are willing to use rubber hose cryptanalysis), they'll be unable to get it.
If necessary, you could even use jurisdictionally-diverse key splitting. The idea is to pick a handful of mutually-antagonistic countries who are unlikely to be willing to cooperate with one another to recover your key, then cryptographically split your private key (perhaps with an m-of-n technique to give yourself some redundancy) and store one piece in each of them.
Protecting your data from the authorities is totally feasible. Protecting yourself... maybe not so much.
It looks like it's possible using Magiclantern open-source firmware for Canon cameras: https://www.magiclantern.fm/fo...
Interesting. But it should be pointed out that the implementation is very badly done from a security perspective. I only spent a few minutes looking at it and found several showstoppers in both design and implementation. Among them:
1. The basic file encryption algorithm is a stream cipher construction using a simple LFSR as the stream generator. This is almost certainly trivial to break; standard LFSRs are in no way designed for cryptographic security. I suspect the LFSR was used for performance, and I'm sure it does in fact perform much better than, say, AES in CTR mode (where AES is used to generate a bitstream XORed with the plaintext in the same way the LFSR output is). While no good stream cipher is likely to match the LFSR performance, there are several that would provide moderate performance and high security, such as ChaCha20 -- or perhaps even a reduced-round variant like ChaCha12 or even Salsa20/12.
Note that someone has contributed an XTEA implementation which is much better, security-wise, than the LFSR but actually slower than AES. If you're going to do that, just use AES.
2. Even if the LFSR-based encryption algorithm were good, it uses 64-bit keys, which is just too small. Oddly enough, when you use the provided RSA mode for asymmetric write-only encryption (decryption can only be done on your PC), the author seems to recommend a 4096-bit RSA key size, which is roughly equivalent to a ~160-bit symmetric encryption key, and which is quite slow. It makes no sense to use such a huge, slow RSA key to protect small symmetric keys.
3. Password hashing uses the same LFSR plus some shifting and masking. Almost certainly insecure, and there's really no reason at all not to use a good password hashing algorithm like Argon2, or at least scrypt.
4. In asymmetric mode, the code appears to use random padding for RSA operations. There are really good reasons for the PKCS#1 v1.5 and RSA-OAEP padding modes that are normally used. It's possible that a very careful analysis of this implementation may show that under certain operational assumptions random padding is okay... but I seriously doubt that any such careful analysis has been done. I would never bother doing anything of the sort and would simply use OAEP. (Or, better yet, avoid RSA and instead use an elliptic curve algorithm -- less tricky to use correctly, faster, smaller keys and even the provides possibility to derive keys from passwords. There's really no reason to use RSA for anything anymore unless you have to interoperate with legacy infrastructure that already uses it.)
5. RSA key generation is done on-device, with the private key written to the SD card, then later deleted. You can't actually delete things from SD cards, not with any confidence. Much better to do keygen off device so only the public key ever exists on the SD.
6. A glance at the RSA key generation code throws up a number of red flags. I suspect the key generation is buggy.
7. I didn't find the random number generator, but given all of the above, I'd be shocked to find that it's actually good. A bad RNG can easily destroy the security of the best cryptographic design.
When I get some time (ha!) I'm going to see if I can get ML running on my 70D and hack together a better version, using Curve25519 ECDH and ChaCha20 with 128-bit keys, with asymmetric keygen done off-device, and a decent PRNG plus the best seeding mechanism available. To make it more usable, I'll see if I can keep the last few dozen per-file keys in RAM, which will allow the photographer to look at the images on the camera, until the camera is turned off. More paranoid users should be able to disable the retention of keys in RAM.
Sounds like a fun project. One which I may or may not get to before 2025 or so...
if there is no one to walk the package to the door for me then the service is not nearly as good or valuable to me
Does it have to be a human that walks it to the door, or can a robot do that?
cojonas
Female testicles? Would those be ovaries?
I'm not sure if this is better or worse than the other misspelling of "cojones" that I often see, which is "cajones" (meaning "large boxes", usually referring to drawers in dressers and cabinets).
Google can do it because they are atypical. It is no indicator that, say, a bank or a hospital can do the same.
Google can do it from scratch because they are atypical. I agree that a bank or hospital absolutely could not build all of the necessary infrastructure to do it, but that's no longer necessary. Google's BeyondCorp program is one of several "vendors" (I believe Google's stuff is all open source) that provide the necessary proxy software and related bits, and it will get easier over time.
On the actual subject, if you really want every system to be individually administrated and fully secured, then go ahead and run this model. For a small network, with, say, less than ten computers this may even work.
FWIW, Google does this with a very large and complex network (100K+ employees). Google has taken the next step beyond this, actually, and recognized that once you have ensured you don't extend any trust to your internal networks, there's no reason to treat external networks as less secure. (See https://www.beyondcorp.com/).
The solution to the problem you mention is standardization. Specifically, standardize all of your internal applications on web interfaces. Once everything is a web site, then you can stand up a set of proxies that provide secure tunnels to the application servers. So every connection to every server goes through the proxy servers first. TLS is used from client to proxy and from proxy to app server, obviously. The proxies do all of the authentication of client device and user, and much of the authorization checking as well. The proxy server adds some headers with the user's identity, including any relevant LDAP groups the user is in. The application servers are configured to accept connections only from proxy servers (proxies present client certs) and can simply trust the contents of the headers to provide accurate user and group IDs, in case they need to do fine-grained authorization.
With some client and server-side utilities this can be made to work even for third-party applications which are not and cannot be made to be web applications. The client app is coerced into connecting to a local socket provided by the client-side utility, which in turn tunnels the data through a TLS connection to the proxy, which tunnels it through another TLS connection to the server-side utility, which then delivers it to the actual server. With some customization the server-side utility can even do whatever sort of authentication the server wants as well.
Not only does this model make a zero-trust network practical, it also provides enterprise-wide single-sign on, and provides a single point for auditing the operation and usage of all internal web apps. Note also that it's not necessarily incompatible with perimeter defense. You can do that, too, if you want. But with a zero-trust infrastructure in place, perimeter defense truly becomes an additional defense-in-depth layer (assuming you don't add any proxy rules of the form "If connection from within perimeter, then don't require auth").
But tell me I have to lock up my phone in a "pouch" and you can shove your concert where the sun doesn't shine.
So, you like going to a concert and looking over a sea of glowing cellphone screens when you look at the stage?
I find it unfortunate that this is necessary. But I do see the value.
his criminal activity Please define his criminal activity that he has committed under NZ law.
Well, New Zealand is a signatory to the Berne Convention and a member of the World Trade Organization, which not only means that New Zealand honors US copyrights (and vice versa), but that the countries have certain reciprocal obligations around enforcement.
And although I haven't followed it closely, as I recall the NZ High Court endorsed Dotcom's extradition to the US last year. OTOH, that doesn't mean everything else the NZ police did was legal or correct, and their overreaching and screwups are the basis for this lawsuit.
I'd liken it to, when you were a kid, and you had a gripe/complaint about your parents. You'd have to petition your parents for a change of rules or procedures.
If only there were a separate but co-equal someone to your parents you could petition for redress of your grievances.
There is (in the traditional family, at least). If Dad won't listen, you go to Mom, or vice versa. Of course, Mom and Dad generally have a very similar perspective, and have strong reasons to be closely aligned. Like branches of the government.
I honestly can't decide which is worse - Dotcom winning or the American bullies winning. It's a no-win situation from my perspective.
How about: the Rule of Law winning? Documented norms that apply to everyone from the bum on the street corner to Bill Gates are a win for everyone.[1]
In this particular case, it means that New Zealand should have followed its own laws, procedures and the treaties to which it is signatory without regard to political pressure brought by the United States. If those laws indicated that Dotcom should be arrested and extradited, well and good. If, as appears to be the case, New Zealand authorities violated their own laws, then Dotcom deserves compensation. I seriously doubt that he deserves 6.8B NZD. In an ideal outcome he ends up exactly where he would have without the illegal police action, which isn't "winning" it's "not losing".
[1] Yeah, everyone knows that the bum on the street corner and Bill Gates do not get treated the same way, but that just means it's an aspirational goal toward which we should work, not something we should cynically laugh off. The further we are from it, the more seriously we need to take it and the more strongly we need to react when our appointed representatives fail to execute it.
I still don't see a use for a smartphone - I'd take a feature phone with Audible and Kindle if one existed.
And virtually every other user just needs a feature phone plus their particular set of needs.
The same is true of computers of all sorts. The value in a programmable computer for the typical person isn't that it will do everything, because the typical person doesn't do everything. It's that it will do all of the small set of things the person needs to do... whatever those things might be.
This. It seems that the guy who left doesn't seem to understand this
Other than the relatively small part of the company that is focused on selling and delivering ads, basically nobody in Google thinks of users as the product. Everyone thinks of end users as the customer, regardless of the fact that 90% of dollars actually flow from advertisers.
(I work for Google.)
Living paycheck to paycheck has little to do with income and a lot to do with spending. I know people making $200K per year and living paycheck to paycheck. I know people making $30K per year who have healthy savings.
True, but there is a limit. If you pay $500/month rent, that's 6K a year. Big chunk of that 30K just for one thing. And many places don't have rents or house payments that low. Add a car, utility bills, phone bills, and there's not much left. Then the car breaks, your roof leaks, you get sick. You're in trouble even if you haven't screwed up financially.
True, there is a limit -- and the fact that getting sick can destroy people is a serious problem that we need to fix. But the car breaking, the roof leaking... those actually shouldn't screw you unless you get several such shocks in quick succession. The key is that whatever your income level is, you need to live on less than that, and save the rest. If you budget to save 20% of your income and live on 80%, you can build up a cushion so a few shocks are survivable.
If it's simply not possible to live on 80% of your income, then you have a serious problem. And by "not possible" I mean there's no way to scale back your lifestyle -- live in a smaller place, drive a cheaper car, lower your utility or phone bills, etc. But the majority of lower-middle income Americans are not in that situation.
Sounds like the "up from your bootstraps" mantra.
Nonsense. It's certainly true that there is an income level below which things become impossible. But that is actually not the case for most people in the middle and lower-middle class in the United States.
Bourgeoisiesplaining to the poor is incredibly obnoxious.
And so is inventing assholish words like "Bourgeoisiesplaining", as is using them with people who didn't come from anything remotely like "Bourgeosie". I'm also not talking about those who are actually poor, but the large majority who do have enough to live, but just don't manage it well.
Please actually read what I write, rather than just writing me off as clueless. I come from a poor family, not a wealthy one. My father grew up in serious poverty -- five kids in a single bed sort of poverty. I grew up in a lower middle class lifestyle (we qualified for and received government assistance, like free school lunch, government cheese, etc.). I'm moderately wealthy, but the only one of my five siblings who is.
I find it very interesting that among my own relatives who are lower-middle income and lower-income it's consistently those who pay 10% of their small income to the church in tithing who are the most economically stable. Given two families, both with total incomes of less than $40K, the one that gives 10% of that meager income away every paycheck is better off -- not only doesn't live paycheck to paycheck, but actually has more/better stuff. How can that possibly make sense?
It works that way for two reasons. The first is that the family that pays tithing does it by assuming at the outset that a chunk of their income isn't available for spending. They have been taught to "first pay the Lord, then pay yourself, then spend what's left". So they pay 10% to the church, put 20% in savings, and figure out how to live on whatever is left. The 20% in savings means that they almost always have a cushion. The second is that that 10% paid in tithing in some sense represents an emergency fund of last resort. If all of the savings is exhausted, they can choose not to pay tithing for a month or two. This almost never happens, though.
The bottom line is that the tithe-payer's choice to live on 70% of their income provides a level of elasticity that allows them to make better choices. When the old car breaks down again, they have the money to fix it without having to pawn stuff or take extortionate payday loans -- or worse, not be able to fix it. I have one relative who wrecked their car and was then unable to go to work, dropping their income to nothing. (I actually paid for the repairs when I heard about it, but without that family "safety net" they'd have been in serious trouble.) When it's obvious that someone is going to need new shoes in a few months, and shoes are on sale now, there's money to buy the sale-priced shoes now rather than buying them at full price when it becomes impossible to wait any longer. And so on.
Your economic situation is a function of two factors, your income and your choices about how you spend it. Except in cases of true poverty, boosting income without also focusing on choices almost never results in greater economic stability, it just increases expenditures. On the other hand, focusing on making better choices nearly always increases stability and, over the course of a few months or years, increases standard of living as well.