Re: Erasing an OTP file on a SD card.

From: Paul Rubin (//phr.cx_at_NOSPAM.invalid)
Date: 07/28/04


Date: 28 Jul 2004 10:16:37 -0700

cesarbremer@raseac.com.br (Cesar Bremer Pinheiro) writes:
> > If the symmetric encryption is really strong, you don't need the OTP.
> > If the symmetric encryption is weak, it's because you don't know what
>
> If you think that using AES 256 bits is safe, use it in our system (i
> think in the same way), it is correctly implemented, if you want OTP,
> add OTP, it is an option.

The presence of OTP makes me lose any confidence in the product.

> > you're doing and implemented it incorrectly, and you probably didn't
> > implement the OTP correctly either.
>
> I don't think that only you have the competence to do that.

I'm just saying that if you did the cryptography right, OTP is not
needed, and if you did the cryptography wrong, you probably also did
the OTP wrong. OTP is much harder to get right than encryption is.
You've already gotten the OTP wrong by trying to store it on a flash
card.

> > So either way, the OTP/symmetric combination is unattractive.
> >
> Talking about security, i think the OTP/symmetric combination is
> very attractive. OTP is an option in my system, if you don't want
> to use-it simply don't use.

Let me explain a different way: let's say I read a description of your
product and it looks reasonable until I get to a part about how some
feature was designed according using astrology. Maybe I don't care
about that feature, but as soon as I see "astrology", it makes me
think that the designers don't understand science and that the whole
product is no good. OTP is the astrology of security implementation.
If I see that OTP is part of a product, that makes me suspicious of
the other parts too, even if I don't use the OTP part.

> I'm not making a telephone, if my user want a telephone, the better
> way to do that is buy a Nokia, i am making a secure voice system.

Nokia doesn't make an encrypted telephone.

> I agree with you when you are talking about easy to use, all this
> stuff are options to my client, if you don't want to change the key
> suggested by the system, don't do that, if you don't want to change
> the random file generated by the system, don't do that.

The more decisions the user has to make, the harder it is for them.

> Our system have a security of 256 bits, i don't want to use DH with
> 13000 bits.

Use 2048 bit DH like everyone else does, or use 512 bit ECDH, or
whatever. I think you're obsessing way too much about the crypto
algorithms, which will be the strongest part of the system if done
right. The attacker is going to concentrate on the weak parts, not
the strong parts. What are you doing about analog leakage between the
voice (plaintext) part of the phone, and the phone line side which
should carry only ciphertext? That's been a significant problem in
some commercial secure phones in the past. If the attacker can hear
the conversation in the clear by just listening carefully enough, no
amount of cryptography or OTP's is of any help.

> About DH, i agree with you, is very simple to be used, but and about
> the users using voice authentication talking with each other in each
> call a number sequence to avoid man-in-the-middle attack? You know
> that the users don't do that, and remember man-in-the-middle-attack.

Since your users can share secret keys, use those to authenticate the
session under the DH, or alternatively have some RSA or DSA
certificates or something. Your system as you describe it has no
forward secrecy and that's a far larger security weakness than the
theoretical possibility of someone cracking aes-128.

> We have a very secure system to closed groups, and we don't want voice
> authentication.

What happens if a phone gets stolen?

> I think we can offer a secure system where the users can previously
> exchange keys.(you only need to exchange the keys by infrared, push
> one button) If you can do that, why negociate the keys when calling?

So that you can destroy the secrets at the end of the session without
a lot of synchronization hassles.

> If you want your users talking using DH and using voice
> authentication, i think you could have serious problems. I don't see
> our users using secure systems to talk with a lot of people, usualy
> secure conversations are done with small and closed groups.

That's maybe reasonable about the small/closed groups, but you should
use DH anyway, even if there's only two users.