I'm not sure what you mean by a "practical" concern. There are firms offering DPA testing services of PIN pads, so I'd say that yes, defending against DPA is a pragmatic decision. Researchers demonstrated OpenSSL timing attacks that were very successful against other servers located in the same physical Amazon cloud server.

Most successful crypto attacks I know of have been "side-channel" attacks. Protocols are generally the weak links, much more so than the well-tested algorithms. (The same is not true for hash digest algorithms, however, as most have had flaws discovered recently.) In particular, I've seen many problems arise because designers have added support for forwarding and/or backward compatibility in the same implementation. Or they may have a code defining the choice of protocol between AES-256, IDEA, CAST, or 3DES, but if you set the protocol to something invalid, the encryption is downgraded to the old default value of DES, ROT-13, or no encryption at all.

I would recommend that once you come up with your protocol, have it reviewed by external parties who are motivated (paid) to have you get it right. You need cryptographers who are fluent in current attack scenarios. As you throw trained eyeballs at your protocol, explain to them the flaws you were aware of and how you mitigated them, then let them work on the problem. Once you get their feedback, listen to it with an open mind. The worst decision you can make is to say "I know what I'm doing."

I'm not sure what you mean by a "practical" concern. There are firms offering DPA testing services of PIN pads, so I'd say that yes, defending against DPA is a pragmatic decision. Researchers demonstrated OpenSSL timing attacks that were very successful against other servers located in the same physical Amazon cloud server.

Most successful crypto attacks I know of have been "side-channel" attacks. Protocols are generally the weak links, much more so than the well-tested algorithms. (The same is not true for hash digest algorithms, however, as most have had flaws discovered recently.) In particular, I've seen many problems arise because designers have added support for forward and/or backward compatibility in the same implementation. Or they may have a code defining the choice of protocol between AES-256, IDEA, CAST, or 3DES, but if you set the protocol to something invalid, the encryption is downgraded to the old default value of DES, ROT-13, or no encryption at all.

I would recommend that once you come up with your protocol, have it reviewed by external parties who are motivated (paid) to have you get it right. You need cryptographers who are fluent in current attack scenarios. As you throw trained eyeballs at your protocol, explain to them the flaws you were aware of and how you mitigated them, then let them work on the problem. Once you get their feedback, listen to it with an open mind. The worst decision you can make is to say "I know what I'm doing."

I'm not sure what you mean by a "practical" concern. There are firms offering DPA testing services of PIN pads, so I'd say that yes, defending against DPA is a pragmatic decision. Researchers demonstrated openssl timing attacks that were very successful against other servers located in the same physical Amazon cloud server.

Most successful crypto attacks I know of have been "side channel" attacks. Protocols are generally the weak links, much more so than the well tested algorithms. (The same is not true for hash digest algorithms, however, as most have had flaws discovered recently.) In particular, I've seen many problems arise because designers have added support for forward and/or backward compatibility in the same implementation. Or they may have a code defining the choice of protocol between AES-256, IDEA, CAST, or 3DES, but if you set the protocol to something invalid, the encryption is downgraded to the old default value of DES, ROT-13, or no encryption at all.

I would recommend that once you come up with your protocol, have it reviewed by external parties who are motivated (paid) to have you get it right. You need cryptographers who are fluent in current attack scenarios. As you throw trained eyeballs at your protocol, explain to them the flaws you were aware of and how you mitigated them, then let them work on the problem. Once you get their feedback, listen to it with an open mind. The worst decision you can make is to say "I know what I'm doing."

I'm not sure what you mean by a "practical" concern. There are firms offering DPA testing services of PIN pads, so I'd say that yes, defending against DPA is a pragmatic decision. Researchers demonstrated OpenSSL timing attacks that were very successful against other servers located in the same physical Amazon cloud server.

Most successful crypto attacks I know of have been "side-channel" attacks. Protocols are generally the weak links, much more so than the well-tested algorithms. (The same is not true for hash digest algorithms, however, as most have had flaws discovered recently.) In particular, I've seen many problems arise because designers have added support for forwarding and/or backward compatibility in the same implementation. Or they may have a code defining the choice of protocol between AES-256, IDEA, CAST, or 3DES, but if you set the protocol to something invalid, the encryption is downgraded to the old default value of DES, ROT-13, or no encryption at all.

I would recommend that once you come up with your protocol, have it reviewed by external parties who are motivated (paid) to have you get it right. You need cryptographers who are fluent in current attack scenarios. As you throw trained eyeballs at your protocol, explain to them the flaws you were aware of and how you mitigated them, then let them work on the problem. Once you get their feedback, listen to it with an open mind. The worst decision you can make is to say "I know what I'm doing."