> As far as I understand, it is important to have a contract that allows you to:
> [...]
> If the client insists on including the clauses above, be ready to move on.
These lines appear to contradict themselves, am I missing something?
138 karma · joined March 2, 2015
[ my public key: https://keybase.io/asherkin; my proof: https://keybase.io/asherkin/sigs/5Px0ip5cgqYCleGfMTH3V4wzcgvc0gOoEnaepChA7CQ ]
> [...]
> If the client insists on including the clauses above, be ready to move on.
These lines appear to contradict themselves, am I missing something?
The specific reason it is mentioned is because their recommendation is that the encryption key should be derived from both the input numbers and a secret baked into the hardware - which would then require brute-forcing the entire key rather than just the input numbers if the attacker only had the data on the drive.
With properly assembled hardware (yay, epoxy) protecting the crypto chip, extracting that key could be made very difficult, protecting against the attacker having the enclosure as well (the secure chip would need to enforce the rate limit itself).
You could try all possible passphrases with the wrong algorithm and you wouldn't get the plaintext, the algorithm is most certainly material.
Signage: https://www.tfl.gov.uk/cdn/static/cms/documents/lu-signs-man... Station Design: http://www.persona.uk.com/nle/B-Core_docs/G/NLE-G1.pdf
> Distribution/Aiding and Abetting the Distribution of Narcotics by Means of the Internet
Good ol' US justice system: Where you get charged with the same crime twice so they can double the sentence.
We've had false-positive AV detections a few times in the last couple years affect an open-source project I'm involved in, it is a massive support burden.
What would you suggest a developer do other than contact the AV vendor to get it sorted out, since they caused the false detection?
But it took you 3 weeks anyway?