[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-developers] Fw: Re: bzrtp support for AES with 256-bit key
|
From: |
Test Sv |
|
Subject: |
Re: [Linphone-developers] Fw: Re: bzrtp support for AES with 256-bit keys |
|
Date: |
Fri, 23 Jan 2015 06:27:06 -0800 |
I find that very puzzling as I have my email address with Yahoo for several
years and this the first time I hear about?. I have no idea how Gmail does its
verification?.
--------------------------------------------
On Fri, 1/23/15, Guillaume BIENKOWSKI <address@hidden> wrote:
Subject: Re: [Linphone-developers] Fw: Re: bzrtp support for AES with 256-bit
keys
To: "address@hidden" <address@hidden>
Date: Friday, January 23, 2015, 9:20 AM
Hello Test
SV,
From Gmail's point
of view, all your messages are marked as spam, this is the
error messages that pops up when I look at your messages
from my spam folder:
Why
is this message in Spam? It
has a from address in yahoo.com but
has failed yahoo.com's required tests
for authentication. Learn
more
(link is https://support.google.com/mail/answer/1366858?hl=en&expand=5
)
Maybe that's the
reason.
Guillaume
BIENKOWSKIhttp://www.belledonne-communications.com/
sip:address@hidden
On
Fri, Jan 23, 2015 at 3:07 PM, Test Sv <address@hidden>
wrote:
I am sending this email again after I received a very
strange message from linphone in response to the email that
my membership has been disabled due to excessive bounces
which I am very clean what it means?!.
--- On Fri, 1/23/15, Test Sv <address@hidden>
wrote:
> From: Test Sv <address@hidden>
> Subject: Re: [Linphone-developers] bzrtp support for
AES with 256-bit keys
> To: address@hidden
> Date: Friday, January 23, 2015, 8:00 AM
>
>
>
>
>
> 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
>
_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers
-----Inline Attachment Follows-----
_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers