Reputation
684
Top tag
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
6 11
Impact
~57k people reached

  • 0 posts edited
  • 0 helpful flags
  • 9 votes cast
Feb
10
comment How much can we trust open source implementations of crypto (security) libraries?
@RichieFrame: That in the case you mention the qualtity of auditing is better is clear. But how could it be ensured in practice for the users that a closed-source software doesn't contain (intentionally implanted) backdoors?
Feb
10
comment How much can we trust open source implementations of crypto (security) libraries?
@marstato: Couldn't "indirectly" have the same "value" as "directly" in this context? Say, a software error or the like causes a critical encrypted message of someone who is accused of something that is threatened with death sentence be cracked in a totalitarian country..
Feb
10
comment What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
@DeerHunter: Should I do more curtailments?
Feb
8
comment How much can we trust open source implementations of crypto (security) libraries?
@marstato: No contradiction to "still better off". But in case, say, one's life depends on some software being absolutely correct, that "better" might not turn out to be sufficiently helpful.
Feb
8
comment How much can we trust open source implementations of crypto (security) libraries?
One essential difficulty, at least with most large open-source packages, seems to be the result of the fact that they were not designed to highly facilitate review by outsiders. The problem could be poor documentations, poor structuring of the whole, poor programming style and scanty comments of codes. This is very very sad but on the other hand understandable. For otherwise the cost of development would be essentially higher and maybe the time of development would also be much longer.
Feb
8
comment How much can we trust open source implementations of crypto (security) libraries?
IMHO trust on IT-security software is nowadays virtually sort of faith. Human errors and malicious backdoors continue to be discovered. A recent issue is socat. Cf. my recent thread "What could eventually be done to mitigate the risks of errors and backdoors" (currently unfortunately yet on hold due to formulation issues unsatisfying for the moderators).
Feb
8
comment What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
@Ohnana: But that #1 would be the title line of my OP, isn't it? (I don't think I should start the body of my OP by repeating its title line.)
Feb
7
comment What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
@DeerHunter: A 2nd attempt of improvement has just been done.
Feb
7
revised What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
Formulation further curtailed.
Feb
7
revised What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
added 2 characters in body
Feb
7
revised What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
Argumentation is now more precise, a point of a comment received is taken into consideration.
Feb
7
comment What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
@schroeder: I suppose one should at the beginning not be too ambitious. IMHO one needs at the beginning to know whether there are some conceivable counter measures that are fairly likely to effectively work "in practice". Should these turned out to form an empty set, then it would have been irrelevant to further consider "how", including who is going to do the mitigation. IMHO, the essence of my discussion with Deer Hunter is not of such importance to be included into my OP.
Feb
7
comment What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
@DeerHunter: My OP doesn't contain proposals. I like to know what eventually feasible prevention measures are there and could be valuable subjects of R&D. I suppose this community helps one to obtain such knowledge.
Feb
7
comment What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
@DeerHunter: One prevention measure that quickly comes to mind for socat is actually very well known in software engineering (i.e. not limited to IT-security software), namely any computer codes, whether original or updates, should for safety/correctness reasons be checked/reviewed by independent knowedgeable/capable persons. It is IMHO fairly clear that such a review was absent in the case of socat.
Feb
7
comment What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
@DeerHunter: It's fine, if socat is taken (in retrospect) as a typical case to concretely ponder on what kind of feasible measures of prevention are there such that cases of the same genre would have a less probability of occurring in the future.
Feb
7
comment What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
@DeerHunter: The question is, I presume, sufficiently clearly delineated in the title line, namely which feasible remedies against the said risks are there and could be profitably discussed for their practicality in our community.
Feb
7
asked What could eventually be effectively done to mitigate the risks of errors and backdoors in IT-security software?
Feb
5
asked Q: What happened to socat?
Feb
5
awarded  Good Question
Feb
1
comment What is the current security status of Diffie-Hellman key exchange?
My main point is: There are recommendations by experts and government institutions. But how much trust should one have towards these in the era following revelations of Snowden and others? Also IMHO unsatisfying for the commen users is: A certain earlier recommended key size was found to be insufficient due to some discovered causes and one is told that from now on one should use another larger key size and everything would be ok. But isn't that also a solid testimony of the fact that in all the time during which the old key size was in vogue the communications of the users were insecure?