Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
3 added 20 characters in body
source | link

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto because expertise in the crypto implementation is rare, hard to acquire and hard to access.

Therefore, I'd give the following advises:

  • Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needsclarity, ease of use, capability and fitness to you needs.
  • Make sure that the people how will be using it will understand how to use the API properlyunderstand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
  • Make sure the code is properly maintainedproperly maintained, now and in the future. This is probably the most important point.
  • What is the library reputationreputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
  • Try to avoid hard dependenciesavoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto because expertise in the crypto implementation is rare, hard to acquire and hard to access.

Therefore, I'd give the following advises:

  • Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.
  • Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
  • Make sure the code is properly maintained, now and in the future. This is probably the most important point.
  • What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
  • Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto because expertise in the crypto implementation is rare, hard to acquire and hard to access.

Therefore, I'd give the following advises:

  • Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.
  • Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
  • Make sure the code is properly maintained, now and in the future. This is probably the most important point.
  • What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
  • Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.

2 spelling, grammar
source | link

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto library because expertise in the crypto implementation is rare and, hard to acquire and hard to access.

Therefore, my advise isI'd give the following advises:

  • Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.  
  • Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
  • Make sure the code is properly maintained, now and in the future. This is probably the most important point.
  • What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
  • Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto library because expertise in crypto implementation is rare and hard to acquire and access.

Therefore, my advise is the following:

  • Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.  
  • Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
  • Make sure the code is properly maintained, now and in the future. This is probably the most important point.
  • What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
  • Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto because expertise in the crypto implementation is rare, hard to acquire and hard to access.

Therefore, I'd give the following advises:

  • Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.
  • Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
  • Make sure the code is properly maintained, now and in the future. This is probably the most important point.
  • What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
  • Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.

1
source | link

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto library because expertise in crypto implementation is rare and hard to acquire and access.

Therefore, my advise is the following:

  • Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.
  • Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
  • Make sure the code is properly maintained, now and in the future. This is probably the most important point.
  • What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
  • Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.