[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-developers] bzrtp support for AES with 256-bit keys
From: |
Test Sv |
Subject: |
Re: [Linphone-developers] bzrtp support for AES with 256-bit keys |
Date: |
Fri, 23 Jan 2015 05:00:38 -0800 |
Hello;
Nice job by the developers team at Simlar. It is an important new capability to
linphone that many users needed and would like to use.
In general, aes-256 is highly recommended as by far the best encryption method
currently available. Although, there are well known serious vulnerabilities in
some of the implementations for aes-256 which undermind the algorithm. Few
years ago, at least one serious vulnerability was identified in zrtp, and was
corrcted later by most of people.
Therefore, aes-256 should be the default encryption on linphone that is
automatically available to the user out of the box after installation (i.e.
without having to go to the settings menu). Users who are interested in down
grading to the aes-128, they can go to the settings menu to do so. Those users
should know that most of people can crack aes-128 without any difficulty.
To the best of my knowledge, linphone and bzrtp never been subjected to an
indepedent and complete security audit. There are several organizations in
Russia and Europe that provide such a highly specialized audit.
Keep up the good work Simlar.
Cheers;
--------------------------------------------
On Fri, 1/23/15, Johan Pascal <address@hidden> wrote:
Subject: Re: [Linphone-developers] bzrtp support for AES with 256-bit keys
To: address@hidden
Date: Friday, January 23, 2015, 6:15 AM
Hi Ben,
and thanks for the patch.
I had a quick look at it, very nice rework on
the tests cases!
Few
remarks:
- I think we should stick to AES128
being the default (switch in
bzrtpCrypto_getAvailableCryptoTypes). The user
will set it to AES256 if
needed.
- You may want to export also
the algorithm defines and not only the
types in bzrtp.h (commit 4) otherwise the user
won't be able to safely
use the get/set
functions.
- We shall
ensure that mandatory algorithms are always present in the
context supported list, by either checking
their presence in the input
supportedTypes
of bzrtp_setSupportedCryptoTypes and queing them at the
end if they are missing or tweaking the
selectCommonAlgo to add them if
they are
missing.(first one seems cleaner)
- Same kind of problem (which was already there
before your patches)
with the incoming
HelloPacket parsing: we shall ensure that if the
packet doesn't contain a mandatory algo, it
is added at the end of the
list as
specified in the RFC section 5.2:
"If a
mandatory algorithm is not included in the list, it
is implicitly added to the end of the
list for preference."
Which means the
in function bzrtp_packetParser, all the tests on
messageData->xx == 0 to set the mandatory
algo shall be replaced by
something
checking the presence of the mandatory algo in the
messageData->xx field after parsing it from
the packet.
- min function
seems fine to me as it is.
I'll have to rework the mediastream patch
as I've done some
modifications in
zrtp.c, they're in branch dev_dtls for now but will be
merge to master soon.
regards,
johan
On 23/01/15 03:58, Ben Sartor
wrote:
> Hi Johan,
>
> thanks for you
answer. I have tried to implement things like you
suggested.
>
> Patches
0001 and 0002 are unchanged.
>
> Patches 0003 to 0005 add the the getter
and setter you suggested.
>
> Patches 0006 to 0009 implement the tests.
I completely refactored the function
>
"test_algoAgreement". Is it ok for you to write
tests this way?
>
>
Patches 0010 to 0012 are some code cleanup suggestions and
were not discussed
> before. Let me know
what you think.
> Is there a better place
for the min-function? Maybe even a macro like
> discussed here [1]? Is
"__typeof__" ok?
>
> [1] http://stackoverflow.com/questions/3437404/min-and-max-in-c
>
> The mediastreamer2
patch of my initial post still applies and may be used
for
> testing.
>
> Kind Regards,
> Ben
>
>> Hi Ben,
>>
>>> Yes. Just to be sure, did you mean
implementing functions like this:
>>>
>>> void
bzrtp_setSupportedCipherTypes(bzrtpContext_t *zrtpContext,
uint8_t
>>> availableTypes[7],
const uint8_t availableTypesCount);
>>>
>>>
uint8_t bzrtp_getSupportedCipherTypes(bzrtpContext_t
*zrtpContext, uint8_t
>>>
availableTypes[7]);
>>
>> Yes but you want to add an uint8_t
algoType argument(just like
>>
bzrtpCrypto_getAvailableCryptoTypes function) to both of
them in order
>> to use the same
function to get/set the available algos for block
>> cipher/key exchange/SAS
rendering/Hash.
>>
>>>> This means we also must add a
way to store the user configuration in
>>>> linphone. I was thinking the
easiest way would be to store it in the
>>>> config file and access it only
manually for now. I can implement this if
>>>> you're lost on the way
linphone manage the config file.
>>>
>>> I
haven't had a look to linphone config file management,
yet. Let's see
>>> how far I
get or if you find time first.
>>
>> It's quite simple, but if you
struggle tell me and I'll have a look at
>> it when you're done with bzrtp. We
can use an already existing config
>>
setting used to select SRTP protection profile(see misc.c
const
>> MSCryptoSuite *
linphone_core_get_srtp_crypto_suites(LinphoneCore *lc);)
>> for the block cipher algo selection
and do something for the other algo
>>
types when needed.
>>
>>>> Last, this must be covered by
automatic tests.(Key exchange between two
>>>> users using different set of
cipher block algo)
>>>
>>> I'm not sure what you mean:
Would you prefer a test similar to the
>>> existing
>>> "test_algoAgreement" or
would it be better to write a test for the
>>> function
>>> "selectCommonAlgo"
directly?
>>
>>
I was thinking of extending the test_algoAgreement to
include block
>> cipher selection and
some test on linphone call to check correct reading
>> of the configuration from file, but it
can't harm to have a test for the
>> selectCommonAlgo too.
>>
>> Thanks for
your contribution.
>>
>> Have a good day
>>
>> johan
>>
>>
_______________________________________________
>> Linphone-developers mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/linphone-developers
>
>
>
>
_______________________________________________
> Linphone-developers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/linphone-developers
>
_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, (continued)
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Peter Villeneuve, 2015/01/18
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Ghislain MARY, 2015/01/19
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Peter Villeneuve, 2015/01/19
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Anton Pomozov, 2015/01/19
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Peter Villeneuve, 2015/01/19
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Anton Pomozov, 2015/01/19
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Guillaume BIENKOWSKI, 2015/01/20
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Anton Pomozov, 2015/01/20
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Ben Sartor, 2015/01/22
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Johan Pascal, 2015/01/23
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys,
Test Sv <=
- [Linphone-developers] Video Conference, Test Sv, 2015/01/26
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Ben Sartor, 2015/01/26
- Re: [Linphone-developers] bzrtp support for AES with 256-bit keys, Johan Pascal, 2015/01/27