if you want to answer the question "How much money did a person with CC X spend on porn", you can look it up without entering the secure domain.
In order to do this you need to know the salt, so I'm assuming it's in the public database as well, i.e.
Public: { H(CC+Salt), Salt, Amount of money spent on porn, Amount of student debt }
no one without access to the private side can find credit cards in the DB or other stuff -- to within the computational costs of the operation multiplied by the entropy of the salt.
Anyone able to do the first operation (looking up an entry for a given CCN) can recover all of the CCNs by brute forcing the CCN space, which isn't all that big. It's not clear what you meant by "+" in "H(CC+Salt)". If you meant concatenation, then you've provided the attacker with a nice way to speed up the search. If you meant XOR, or even addition... hmm... it's not obvious if there's an optimization in that case. If you used a proper keyed hash, like HMAC, then the attacker must do the full operation for each candidate CC and (known) salt. Still, that is well within the realm of possibility, and it doesn't depend at all on the size of the salt space.
If the salts are not public, then they're not salts, they're keys, and it's necessary to possess the proper key in order to look up an entry for a given CCN. And, of course, anyone with the secret knowledge can brute force the CCN space, so you may as well just give them access to the private database.
I don't think your scheme accomplishes what you think it does.
I designed and wrote a suite that passed a 3d party, hostile, security audit.
I don't normally play the credential game, but if that's what you want to do...
Me too. Many times. Including once an audit by the NSA (back when they actually tried to strengthen security). I've also been a security consultant for dozens of fortune 500 companies, and similarly-sized international corporations around the world. I've consulted for the US and Israeli militaries. I'm currently a crypto security engineer at Google, and the lead maintainer of a popular open source crypto library. I'm not a real cryptographer, mind you, since I don't have any published cryptanalytic papers and don't really have the chops to write them... though I do have a couple of colleagues who are prominent academic cryptographers and they listen when I talk. That last point is the strongest credential I can offer, IMO.
And I'm here to tell you: Do NOT roll your own algorithms, not even by tweaking published ones. Use only published, peer-reviewed, time-tested algorithms and apply published, peer-reviewed, time-tested protocols to construct the security properties you require. The literature and practice includes constructs for virtually any set of security properties you might want (well, the ones which aren't impossible). Learn and use them... and hire someone else with greater expertise to review them. In spite of -- actually, because of -- my decades of experience, I run everything even remotely novel past my real cryptographer colleagues, and they immediately turn to published literature, not trusting their own decades of even deeper experience. And then I have my code carefully reviewed by other engineers with backgrounds similar to mine.
If I were I to seriously suggest hacking up MD5 for anything requiring security, my colleagues would all wonder if I had been replaced by an (incompetent) alien. Actually, I'd have a hard time convincing them I wasn't joking.
In this case, what you want is HMAC with a standard cryptographically-secure hash and a key with sufficient entropy.
You can simply use the 256 bits of garbage if all you need is an identifier.
Yes, but you need to get the same 256 bits of garbage each time you encounter a given driver ID. This means adding a lookup table. Much simpler and faster to use a keyed hash as your lookup table.
nope, it has to do with the key. given a tag # and license # you can dictionary attack the hash. especially since the the source data is known, easy to break.
If they'd used a keyed hash of tag # and license #, it wouldn't have been breakable. Even HMAC-MD5 would have been fine, given sufficient entropy in the key, though I'd have used HMAC-SHA256 just as a matter of good crypto hygiene.
And a custom algorithm is wrong, wrong, wrong. That's just begging for weakness in the solution. Use the proper standard algorithm for the job.
If you keep them secret then they're not salts, they're keys. The definition of "salt" in the cryptographic world includes the notion that it need not be kept secret, just as "IV" is a value which need not be secret but must not be predictable, and "nonce" is a value which need not be secret or predictable (indeed a salt is technically a form of or application of a nonce).
Another characteristic of salts is that you use a different salt for each entry. That's counterproductive in the case being discussed, because the whole point is to compute the same value for a given driver ID, so that you can compute statistics across that driver's logs (but without knowing who the driver is). So to use per-entry keys, you actually have to store a mapping from ID to key so you can look up the correct key each time you encounter a given ID in the obscuring process. If you're doing that you might as well not bother with hashing at all: just pick random values for each driver ID and use the random value in place of the ID as the "obscured" form. Since there will be no link between random IDs and the driver IDs they substitute except for your mapping table, it's impossible for anyone without the table to reverse the mapping.
There's nothing wrong with using a keyed hash, but it's better to use a proper keyed hash construction, like HMAC; salt is generally employed simply by hashing the salt with the value to be obscured, which enables various attacks depending on whether the salt is first or last.
So the right way to do hash-based obscuring in this context is to pick a random secret key and use it to HMAC each of the driver IDs. You'll get the same value for each driver ID, but only someone with the HMAC key can exploit the small driver ID space to discover the mapping.
Thereby introducing a known plaintext into a cryptographic construct--something not to be taken lightly.
You don't know what you're talking about.
First, with any decent cipher or keyed hash, known plaintext by itself poses no risk to security. If it does, then by definition your cryptographic construct is pre-broken and you should get another one that works. Encryption should nearly always be randomized not because known plaintext is a problem, but to avoid replay attacks. That's not relevant here, in fact "replay" is a desired feature since the whole point is to produce IDs which can be correlated within a defined context.
Oh, it's wise to avoid known plaintext when convenient, on the theory that your fundamental algorithm may become broken in the future. But it's better to plan for algorithm agility in that case... and, frankly, it's a corner case.
If all you need is unique IDs, a random sort and cardinal numbering is better (no known plaintext introduced to later convey extra information like license plate # in the event of a break). Random IDs would work just as well.
If you have the option of doing that, fine. But in many cases the data is streaming in and you can't stop the world to sort and assign IDs. So to use a random ID you'd have to store a mapping of real value to random ID and look up the appropriate random ID -- or add a new one -- for each item that comes in. A keyed hash is much simpler and faster.
There's an incredible amount of bad homebrew crypto suggestions on this article. Play with it, learn the principles, but please, for the love of FSM, don't trust it.
There are always lots of bad suggestions, which is why I offered a good one.
Always assumed anywhere term "anonymized data" is used it is more likely than not to be companies and governments paying lip service to its customers... where data could easily be reversed into an identifiable way by either taking advantage of insufficient entropy or cross referencing datasets.
It's worth mentioning that one possible solution in this sort of situation is to use a keyed hash. Assuming a good base hash (which MD5 really isn't, any more, but HMAC MD5 would likely have been fine) and a well-secured key with sufficient entropy, it is infeasible to reverse the hash. Cross-referencing may still be an issue, though straight brute force reversing of the hashing isn't. To eliminate the possibility of cross-referencing it's necessary to use a different hash key for each database.
Of course, like all cryptographic "solutions", this merely replaces a large secret (the contents of the database(s)) with a small secret (the key or keys). Still, it's typically easier to secure a key than a database. "Easier" doesn't mean "easy". Depending on the application, though it's often the case that if all you need is unique IDs for delivery to a third party, you can just generate a random key, use it to hash all of the to-be-secured IDs then discard the key.
Oh, and the real "solution", of course, is to hire someone who knows what they're doing and give them the time and resources to fully and accurately understand the security problem they're trying to solve. They'll either do the job or tell you it can't be done (or do the job and screw it up in a subtle and non-obvious way rather than a stupid and obvious one... but hey, at least if it's broken it'll be subtle and non-obvious break).
If the software is complete crap - and it makes the company money.... it's a success. This is a bitter pill for developers to swallow, generally, but it is true.
Heh. It's too bitter a pill to me to be able to express it quite that baldly. Doesn't make you wrong, though, at least in some contexts. I prefer not to work in such contexts.
Yes, I've seen it cleaned up. I've even seen (and been on, and led) teams who track their technical debt, measured in terms of estimated person-days to clean it up, and deliberately schedule periods of time focused on debt paydown, both short sprints and longer-term efforts.
I've even seen organizations mismanaged like yours which have turned around and began deliberately managing their technical debt. It starts with the engineers educating management about technical debt. Unless the managers are fools (and most of them actually aren't, they just seem that way because engineers and managers don't communicate well), they quickly grasp the idea and its consequences. Even then, you can still have managers that care only about the short term, because they expect to be promoted and out of the mess before the note comes due, and there's really not much you can do about them except to quietly try to manage it yourself. But given a reasonably-intelligent manager who is interested in next year and the year after, teaching them (gently, non-confrontationally and above all non-condescendingly) about the concept of technical debt will help them to understand and work with you.
One key to making it work is that you must be able to quantify technical debt. That means being able to make reasonably-accurate estimates of its impact and cost to fix. That, in turn, means that you have to be capable of making reasonably-accurate estimates of how long it takes your team to accomplish a given piece of work (feature or debt paydown). And you have to establish a track record with the manager so that he or she trusts you and your estimates.
I'm not saying it's easy, but it absolutely can be done... and it'll make your time at work much less stressful. It may or may not result in any decisions being changed, but when you're sure that management understands your concerns, and considers them to be perfectly valid and important, it makes it much easier to accept when they decide to take the shortcut anyway. And if the team is visibly and conscientiously tracking technical debt (e.g. as a regular part of weekly status reports), most managers will begin seeing it as a variable to manage, including by finding opportunities to pay it down, and by understanding when it impedes new work.
What I haven't seen work is "We want all the features, we'll just do a half assed version of it and not keep track of the tech debt." turn out well.
I have. It always leaves a mess to clean up later, but it's sometimes the difference between having a product team to clean up the mess or having the whole thing die. I've also seen startups fail because the development team refused to cut corners, resulting in missing the market window of opportunity.
I should also mention that Google's interview process deliberately chooses to err on the side of rejecting qualified people in order to avoid hiring unqualified people. Since no one knows how to accurately discern between them, Google prefers to reject good people rather than risk hiring those who can't cut it. So the fact that you didn't get the offer doesn't mean you weren't qualified.
It's generally accepted that if you took a successful Google engineer and ran him (or her, but it's usually him) through the hiring process (blind, no one realizing he already works for Google), there's about a 50/50 chance he'd make it.
Also, if you're interested in giving it another shot, e-mail me.
I strongly doubt that age was the issue -- and I say this as a 45 year-old Google engineer, who got hired at age 42, and works with a bunch of other (recently-hired) engineers in their 40s, 50s and even 60s. I also work with a bunch of younger engineers.
Google isn't perfect, of course, but it's the closest thing I've seen to a pure meritocracy in my 25 years in the industry.
Amazing how many managers think you can save time by cutting quality isn't it?
You absolutely can save time by cutting corners, including quality. You have to cut the right corners and you have to understand what it's going to do to you down the road, but it often is the right decision.
One of the most useful notions to arise in the software industry in recent decades is the concept of technical debt. Cutting corners now means storing up trouble for later, and debt is an absolutely awesome way to think and talk about it -- a big bonus is that it's a concept that management is perfectly able to understand, including the fact that the time will come when it's necessary to stop spending development resources on buying new features and start using it to pay down the debt.
And as I mentioned before, accruing some technical debt is often exactly the right decision. If getting the next version out the door a couple of months earlier is the difference between keeping the company alive and not, then there's simply no question. It's much better to accept the debt (just like borrowing money from the bank to make payroll) so that there's income later to pay it off. On the other hand, if the resources are available to do it right, avoiding debt increases future agility -- and going the other direction, spending development resources on making the codebase more flexible is a lot like building cash reserves, something smart companies do when times are good.
This. If I didn't have to worry about people torrenting movies or downloading kiddie porn, I'd be happy to share some bandwidth. Unfortunately, the real world dictates I not even consider this.
I hear this all the time, but I've yet to see a single example of someone being prosecuted for someone else's use of their bandwidth. On the other hand, I've seen numerous cases of judges ruling that merely because activity occurred on a specific IP address, that doesn't prove that the owner of that address did them. If anything, it seems to me that sharing your connection provides you with plausible deniability.
I agree. I doubt perjury charges will be brought, and doubt even more that they would be successful. But I do expect judges to take a much harder line going forward.
I think they'll argue that it wasn't perjury. They weren't told to claim the information was from a "confidential informant" -- a snitch -- but a "confidential source", which isn't well-defined. I think the wording was chosen to mislead the judge into thinking they meant a CI, but without actually lying. Of course, intending to deceive may be perjury, even if what you say is the literal truth, but it's much harder to pin down.
What products does Google sell to the US government?
You.
A) That's not true. Do you have a citation?
B) Even if it were, it wouldn't be relevant to this thread, in which the claim is that not making BoringSSL FIPS-compliant will somehow make it irrelevant because it would impact Google's ability to sell products to the government. If Google did sell information to the government, the lack of FIPS certification on BoringSSL clearly wouldn't be an obstacle.
Without FIPS certification system engineers won't be able to include BoringSSL in US-government facing applications, since doing so will disqualify them from procurement lists. Since US gov't is largest consumer of cryptographic products in the North American market, BoringSSL must certify or stay irrelevant.
Right, because Google is irrelevant.
It will be if it can't sell products to the US government.
What products does Google sell to the US government? And, in general, it's not like the government is the only customer in the world.
Without FIPS certification system engineers won't be able to include BoringSSL in US-government facing applications, since doing so will disqualify them from procurement lists. Since US gov't is largest consumer of cryptographic products in the North American market, BoringSSL must certify or stay irrelevant.
Slashdot Mirror
if you want to answer the question "How much money did a person with CC X spend on porn", you can look it up without entering the secure domain.
In order to do this you need to know the salt, so I'm assuming it's in the public database as well, i.e.
Public: { H(CC+Salt), Salt, Amount of money spent on porn, Amount of student debt }
no one without access to the private side can find credit cards in the DB or other stuff -- to within the computational costs of the operation multiplied by the entropy of the salt.
Anyone able to do the first operation (looking up an entry for a given CCN) can recover all of the CCNs by brute forcing the CCN space, which isn't all that big. It's not clear what you meant by "+" in "H(CC+Salt)". If you meant concatenation, then you've provided the attacker with a nice way to speed up the search. If you meant XOR, or even addition... hmm... it's not obvious if there's an optimization in that case. If you used a proper keyed hash, like HMAC, then the attacker must do the full operation for each candidate CC and (known) salt. Still, that is well within the realm of possibility, and it doesn't depend at all on the size of the salt space.
If the salts are not public, then they're not salts, they're keys, and it's necessary to possess the proper key in order to look up an entry for a given CCN. And, of course, anyone with the secret knowledge can brute force the CCN space, so you may as well just give them access to the private database.
I don't think your scheme accomplishes what you think it does.
randomized_id = HMAC_SHA256(id, key)
How hard was that?
Not to mention the fact that in some contexts database lookups are prohibitively expensive.
I designed and wrote a suite that passed a 3d party, hostile, security audit.
I don't normally play the credential game, but if that's what you want to do...
Me too. Many times. Including once an audit by the NSA (back when they actually tried to strengthen security). I've also been a security consultant for dozens of fortune 500 companies, and similarly-sized international corporations around the world. I've consulted for the US and Israeli militaries. I'm currently a crypto security engineer at Google, and the lead maintainer of a popular open source crypto library. I'm not a real cryptographer, mind you, since I don't have any published cryptanalytic papers and don't really have the chops to write them... though I do have a couple of colleagues who are prominent academic cryptographers and they listen when I talk. That last point is the strongest credential I can offer, IMO.
And I'm here to tell you: Do NOT roll your own algorithms, not even by tweaking published ones. Use only published, peer-reviewed, time-tested algorithms and apply published, peer-reviewed, time-tested protocols to construct the security properties you require. The literature and practice includes constructs for virtually any set of security properties you might want (well, the ones which aren't impossible). Learn and use them... and hire someone else with greater expertise to review them. In spite of -- actually, because of -- my decades of experience, I run everything even remotely novel past my real cryptographer colleagues, and they immediately turn to published literature, not trusting their own decades of even deeper experience. And then I have my code carefully reviewed by other engineers with backgrounds similar to mine.
If I were I to seriously suggest hacking up MD5 for anything requiring security, my colleagues would all wonder if I had been replaced by an (incompetent) alien. Actually, I'd have a hard time convincing them I wasn't joking.
In this case, what you want is HMAC with a standard cryptographically-secure hash and a key with sufficient entropy.
You can simply use the 256 bits of garbage if all you need is an identifier.
Yes, but you need to get the same 256 bits of garbage each time you encounter a given driver ID. This means adding a lookup table. Much simpler and faster to use a keyed hash as your lookup table.
The solution is VERY simple. Generate a random 256 bit string. Hash random-string+data, and use the output as the identifier.
This. Except rather than hashing the key with the data, use a proper keyed hash construction. HMAC is a good choice.
nope, it has to do with the key. given a tag # and license # you can dictionary attack the hash. especially since the the source data is known, easy to break.
If they'd used a keyed hash of tag # and license #, it wouldn't have been breakable. Even HMAC-MD5 would have been fine, given sufficient entropy in the key, though I'd have used HMAC-SHA256 just as a matter of good crypto hygiene.
And a custom algorithm is wrong, wrong, wrong. That's just begging for weakness in the solution. Use the proper standard algorithm for the job.
Salts are secret if you want them to be
If you keep them secret then they're not salts, they're keys. The definition of "salt" in the cryptographic world includes the notion that it need not be kept secret, just as "IV" is a value which need not be secret but must not be predictable, and "nonce" is a value which need not be secret or predictable (indeed a salt is technically a form of or application of a nonce).
Another characteristic of salts is that you use a different salt for each entry. That's counterproductive in the case being discussed, because the whole point is to compute the same value for a given driver ID, so that you can compute statistics across that driver's logs (but without knowing who the driver is). So to use per-entry keys, you actually have to store a mapping from ID to key so you can look up the correct key each time you encounter a given ID in the obscuring process. If you're doing that you might as well not bother with hashing at all: just pick random values for each driver ID and use the random value in place of the ID as the "obscured" form. Since there will be no link between random IDs and the driver IDs they substitute except for your mapping table, it's impossible for anyone without the table to reverse the mapping.
There's nothing wrong with using a keyed hash, but it's better to use a proper keyed hash construction, like HMAC; salt is generally employed simply by hashing the salt with the value to be obscured, which enables various attacks depending on whether the salt is first or last.
So the right way to do hash-based obscuring in this context is to pick a random secret key and use it to HMAC each of the driver IDs. You'll get the same value for each driver ID, but only someone with the HMAC key can exploit the small driver ID space to discover the mapping.
Thereby introducing a known plaintext into a cryptographic construct--something not to be taken lightly.
You don't know what you're talking about.
First, with any decent cipher or keyed hash, known plaintext by itself poses no risk to security. If it does, then by definition your cryptographic construct is pre-broken and you should get another one that works. Encryption should nearly always be randomized not because known plaintext is a problem, but to avoid replay attacks. That's not relevant here, in fact "replay" is a desired feature since the whole point is to produce IDs which can be correlated within a defined context.
Oh, it's wise to avoid known plaintext when convenient, on the theory that your fundamental algorithm may become broken in the future. But it's better to plan for algorithm agility in that case... and, frankly, it's a corner case.
If all you need is unique IDs, a random sort and cardinal numbering is better (no known plaintext introduced to later convey extra information like license plate # in the event of a break). Random IDs would work just as well.
If you have the option of doing that, fine. But in many cases the data is streaming in and you can't stop the world to sort and assign IDs. So to use a random ID you'd have to store a mapping of real value to random ID and look up the appropriate random ID -- or add a new one -- for each item that comes in. A keyed hash is much simpler and faster.
There's an incredible amount of bad homebrew crypto suggestions on this article. Play with it, learn the principles, but please, for the love of FSM, don't trust it.
There are always lots of bad suggestions, which is why I offered a good one.
Always assumed anywhere term "anonymized data" is used it is more likely than not to be companies and governments paying lip service to its customers... where data could easily be reversed into an identifiable way by either taking advantage of insufficient entropy or cross referencing datasets.
It's worth mentioning that one possible solution in this sort of situation is to use a keyed hash. Assuming a good base hash (which MD5 really isn't, any more, but HMAC MD5 would likely have been fine) and a well-secured key with sufficient entropy, it is infeasible to reverse the hash. Cross-referencing may still be an issue, though straight brute force reversing of the hashing isn't. To eliminate the possibility of cross-referencing it's necessary to use a different hash key for each database.
Of course, like all cryptographic "solutions", this merely replaces a large secret (the contents of the database(s)) with a small secret (the key or keys). Still, it's typically easier to secure a key than a database. "Easier" doesn't mean "easy". Depending on the application, though it's often the case that if all you need is unique IDs for delivery to a third party, you can just generate a random key, use it to hash all of the to-be-secured IDs then discard the key.
Oh, and the real "solution", of course, is to hire someone who knows what they're doing and give them the time and resources to fully and accurately understand the security problem they're trying to solve. They'll either do the job or tell you it can't be done (or do the job and screw it up in a subtle and non-obvious way rather than a stupid and obvious one... but hey, at least if it's broken it'll be subtle and non-obvious break).
If the software is complete crap - and it makes the company money.... it's a success. This is a bitter pill for developers to swallow, generally, but it is true.
Heh. It's too bitter a pill to me to be able to express it quite that baldly. Doesn't make you wrong, though, at least in some contexts. I prefer not to work in such contexts.
People have had their homes raided and their equipment seized or have been sued for damages because someone else abused their internet connection.
Cite?
wikipedia.org/wiki/Swatting
Way to pretend to answer the question while really ducking it. Have you considered a career in politics?
Yes, I've seen it cleaned up. I've even seen (and been on, and led) teams who track their technical debt, measured in terms of estimated person-days to clean it up, and deliberately schedule periods of time focused on debt paydown, both short sprints and longer-term efforts.
I've even seen organizations mismanaged like yours which have turned around and began deliberately managing their technical debt. It starts with the engineers educating management about technical debt. Unless the managers are fools (and most of them actually aren't, they just seem that way because engineers and managers don't communicate well), they quickly grasp the idea and its consequences. Even then, you can still have managers that care only about the short term, because they expect to be promoted and out of the mess before the note comes due, and there's really not much you can do about them except to quietly try to manage it yourself. But given a reasonably-intelligent manager who is interested in next year and the year after, teaching them (gently, non-confrontationally and above all non-condescendingly) about the concept of technical debt will help them to understand and work with you.
One key to making it work is that you must be able to quantify technical debt. That means being able to make reasonably-accurate estimates of its impact and cost to fix. That, in turn, means that you have to be capable of making reasonably-accurate estimates of how long it takes your team to accomplish a given piece of work (feature or debt paydown). And you have to establish a track record with the manager so that he or she trusts you and your estimates.
I'm not saying it's easy, but it absolutely can be done... and it'll make your time at work much less stressful. It may or may not result in any decisions being changed, but when you're sure that management understands your concerns, and considers them to be perfectly valid and important, it makes it much easier to accept when they decide to take the shortcut anyway. And if the team is visibly and conscientiously tracking technical debt (e.g. as a regular part of weekly status reports), most managers will begin seeing it as a variable to manage, including by finding opportunities to pay it down, and by understanding when it impedes new work.
What I haven't seen work is "We want all the features, we'll just do a half assed version of it and not keep track of the tech debt." turn out well.
I have. It always leaves a mess to clean up later, but it's sometimes the difference between having a product team to clean up the mess or having the whole thing die. I've also seen startups fail because the development team refused to cut corners, resulting in missing the market window of opportunity.
Context matters.
People have had their homes raided and their equipment seized or have been sued for damages because someone else abused their internet connection.
Cite?
I did not expect to get the job, which I did not.
I should also mention that Google's interview process deliberately chooses to err on the side of rejecting qualified people in order to avoid hiring unqualified people. Since no one knows how to accurately discern between them, Google prefers to reject good people rather than risk hiring those who can't cut it. So the fact that you didn't get the offer doesn't mean you weren't qualified.
It's generally accepted that if you took a successful Google engineer and ran him (or her, but it's usually him) through the hiring process (blind, no one realizing he already works for Google), there's about a 50/50 chance he'd make it.
Also, if you're interested in giving it another shot, e-mail me.
I strongly doubt that age was the issue -- and I say this as a 45 year-old Google engineer, who got hired at age 42, and works with a bunch of other (recently-hired) engineers in their 40s, 50s and even 60s. I also work with a bunch of younger engineers.
Google isn't perfect, of course, but it's the closest thing I've seen to a pure meritocracy in my 25 years in the industry.
Amazing how many managers think you can save time by cutting quality isn't it?
You absolutely can save time by cutting corners, including quality. You have to cut the right corners and you have to understand what it's going to do to you down the road, but it often is the right decision.
One of the most useful notions to arise in the software industry in recent decades is the concept of technical debt. Cutting corners now means storing up trouble for later, and debt is an absolutely awesome way to think and talk about it -- a big bonus is that it's a concept that management is perfectly able to understand, including the fact that the time will come when it's necessary to stop spending development resources on buying new features and start using it to pay down the debt.
And as I mentioned before, accruing some technical debt is often exactly the right decision. If getting the next version out the door a couple of months earlier is the difference between keeping the company alive and not, then there's simply no question. It's much better to accept the debt (just like borrowing money from the bank to make payroll) so that there's income later to pay it off. On the other hand, if the resources are available to do it right, avoiding debt increases future agility -- and going the other direction, spending development resources on making the codebase more flexible is a lot like building cash reserves, something smart companies do when times are good.
This. If I didn't have to worry about people torrenting movies or downloading kiddie porn, I'd be happy to share some bandwidth. Unfortunately, the real world dictates I not even consider this.
I hear this all the time, but I've yet to see a single example of someone being prosecuted for someone else's use of their bandwidth. On the other hand, I've seen numerous cases of judges ruling that merely because activity occurred on a specific IP address, that doesn't prove that the owner of that address did them. If anything, it seems to me that sharing your connection provides you with plausible deniability.
I agree. I doubt perjury charges will be brought, and doubt even more that they would be successful. But I do expect judges to take a much harder line going forward.
You missed the last sentence of my post, apparently.
Instructions were given to commit perjury
I think they'll argue that it wasn't perjury. They weren't told to claim the information was from a "confidential informant" -- a snitch -- but a "confidential source", which isn't well-defined. I think the wording was chosen to mislead the judge into thinking they meant a CI, but without actually lying. Of course, intending to deceive may be perjury, even if what you say is the literal truth, but it's much harder to pin down.
What products does Google sell to the US government?
You.
A) That's not true. Do you have a citation?
B) Even if it were, it wouldn't be relevant to this thread, in which the claim is that not making BoringSSL FIPS-compliant will somehow make it irrelevant because it would impact Google's ability to sell products to the government. If Google did sell information to the government, the lack of FIPS certification on BoringSSL clearly wouldn't be an obstacle.
Without FIPS certification system engineers won't be able to include BoringSSL in US-government facing applications, since doing so will disqualify them from procurement lists. Since US gov't is largest consumer of cryptographic products in the North American market, BoringSSL must certify or stay irrelevant.
Right, because Google is irrelevant.
It will be if it can't sell products to the US government.
What products does Google sell to the US government? And, in general, it's not like the government is the only customer in the world.
Without FIPS certification system engineers won't be able to include BoringSSL in US-government facing applications, since doing so will disqualify them from procurement lists. Since US gov't is largest consumer of cryptographic products in the North American market, BoringSSL must certify or stay irrelevant.
Right, because Google is irrelevant.
Yes. Because they don't want anyone else to have that data that they have gone to such effort to collect.
Or at least not without paying for it.
FYI, Google does not sell user data.