Re: [openssl-dev] OPENSSL provided by Cavium

[balaji marisetti]

I think this question is better directed at Cavium support centre.

>I wanted to ask whether we can install Cavium OPENSSL Toolkit on
>Linux OS (on Cavium hardware), just as we install a standard OPENSSL?

Yes. You can install it as normal OpenSSL on Linux OS and all your
applications should work fine.

On Tue, Aug 9, 2016 at 9:26 AM, neutrino network
 wrote:
> Hi,
>
> Cavium provides a configured OPENSSL for better performance on their
> hardware. It usage must lowers the CPU utilization by crypto operations
> offloading. I wanted to ask whether we can install Cavium OPENSSL Toolkit on
> Linux OS (on Cavium hardware), just as we install a standard OPENSSL? OR the
> only way to use this Cavium OPENSSL is by making simple executive
> application/user space and use the provided OPENSSL as an API.
>
> Please guide and share any details (readme, tutorial, link etc) regarding
> Cavium OPENSSL.
>
>
> Regards
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
:-)balaji
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] need clarification on openssl s_server s_client applications

[balaji marisetti]

Hi Todd,

Thanks for the clarification.



On Thu, Apr 14, 2016 at 12:48 AM, Short, Todd <tsh...@akamai.com> wrote:
> DTLS standard: DTLS does not permit fragmentation of the data (handshaking
> has it’s own fragmentation mechanism separate from the record layer).
>
> See https://tools.ietf.org/html/rfc4347#section-4.2.3
>
> --
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Apr 13, 2016, at 9:11 AM, balaji marisetti <balajimarise...@gmail.com>
> wrote:
>
> Hi,
>
> When I try to send any data > MTU (1500) from s_server/client
> applications (in DTLS mode), I see an error (errno:90) on the sender
> side. Is it normal? Is it a limitation of the s_server/client
> applications or the OpenSSL implementation or the DTLS standard
> itself?
>
> I'm using Openssl-1.0.2g on Ubuntu-14.04
>
>
> Thanks,
> Balaji M
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
:-)balaji
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] need clarification on openssl s_server s_client applications

[balaji marisetti]

Hi,

When I try to send any data > MTU (1500) from s_server/client
applications (in DTLS mode), I see an error (errno:90) on the sender
side. Is it normal? Is it a limitation of the s_server/client
applications or the OpenSSL implementation or the DTLS standard
itself?

I'm using Openssl-1.0.2g on Ubuntu-14.04


Thanks,
Balaji M
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards

[balaji marisetti via RT]

Hi Andy,

Thanks for pointing us to a better alternative. We'll try and change
the way of configuring OpenSSL for OCTEON.


-Balaji M

On 25 May 2015 at 21:23, Andy Polyakov via RT r...@openssl.org wrote:
 Hi,

 This patch adds Cavium Networks' OCTEON target to Configure file. The diff  
 is taken against OpenSSL-1.0.2a release.

 Well, objective is not to collect as many exotic config lines as
 possible, but rather more generic ones that we are ready to support and
 make them flexible enough to be reusable in more specific contexts. For
 example in this case what prevents you from using

 ./Configure linux-generic32
 --cross-compile-prefix=mips64-octeon-linux-gnu- -mabi=n32

 and

 ./Configure linux-generic64 --cross-compile-prefix=mips64-octeon-linux-gnu-

 Or better yet

 ./Configure linux-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu-

 and

 ./Configure linux64-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu-

 and take advantage of assembly support?


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



-- 
:-)balaji


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards

[balaji marisetti]

Hi Andy,

Thanks for pointing us to a better alternative. We'll try and change
the way of configuring OpenSSL for OCTEON.


-Balaji M

On 25 May 2015 at 21:23, Andy Polyakov via RT r...@openssl.org wrote:
 Hi,

 This patch adds Cavium Networks' OCTEON target to Configure file. The diff  
 is taken against OpenSSL-1.0.2a release.

 Well, objective is not to collect as many exotic config lines as
 possible, but rather more generic ones that we are ready to support and
 make them flexible enough to be reusable in more specific contexts. For
 example in this case what prevents you from using

 ./Configure linux-generic32
 --cross-compile-prefix=mips64-octeon-linux-gnu- -mabi=n32

 and

 ./Configure linux-generic64 --cross-compile-prefix=mips64-octeon-linux-gnu-

 Or better yet

 ./Configure linux-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu-

 and

 ./Configure linux64-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu-

 and take advantage of assembly support?


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



-- 
:-)balaji
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards

[balaji marisetti]

Hi,

Can someone comment on this patch request. I just to know if there was
anything wrong (or requirement not met) for this patch to be accepted.

Thanks,
Balaji M

On 30 March 2015 at 23:24, Marisetti, Balaji via RT r...@openssl.org wrote:
 This patch adds Cavium Networks' OCTEON target to Configure file. The diff  
 is taken against OpenSSL-1.0.2a release.


 Thanks,

 Balaji M


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




-- 
:-)balaji
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards

[balaji marisetti via RT]

Hi,

Can someone comment on this patch request. I just to know if there was
anything wrong (or requirement not met) for this patch to be accepted.

Thanks,
Balaji M

On 30 March 2015 at 23:24, Marisetti, Balaji via RT r...@openssl.org wrote:
 This patch adds Cavium Networks' OCTEON target to Configure file. The diff  
 is taken against OpenSSL-1.0.2a release.


 Thanks,

 Balaji M


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




-- 
:-)balaji


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

EC_METHOD struct

[balaji marisetti]

Hello

In the EC_METHOD structure, the pointers to methods for converting
between affine and projective coordinates are named:

`point_set_Jprojective_coordinates_GFp` and
`point_get_Jprojective_coordinates_GFp`

Does that mean any implementation of EC_METHOD (for prime curves) can
only use Jacobian coordinates? Is it not possible to use some other
coordinate system (may be homogeneous)?

-- 
:-)balaji
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Return codes of EC_POINT_is_at_infinity, EC_POINT_is_on_curve

[balaji marisetti]

Hi All,

I have a doubt. Shouldn't the `EC_POINT_...` methods be returning -1
instead of 0 on error conditions?

Thanks,
Balaji M
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Return codes of EC_POINT_is_at_infinity, EC_POINT_is_on_curve

[balaji marisetti]

@Kyle Hamilton
So should all the new programs stick to the idiom or check for -1 return code?

On 11 July 2014 14:56, Ben Laurie b...@links.org wrote:
 On 11 July 2014 09:53, Kyle Hamilton aerow...@gmail.com wrote:
 EC_POINT_is_on_curve is documented to return -1 on error, 0 if it's not
 on the curve, and 1 if it is on the curve.

 However, this breaks the standard idiom if(!EC_POINT_is_on_curve()) {
 return BAD_KEY; }, because it requires an additional test for an error
 condition.

 Plenty of OpenSSL functions return -1, 0, 1. Plenty also return 0, 1.
 Its not optimal.

 I don't know what the best outcome would be in this situation.

 -Kyle H

 On 7/11/2014 12:34 AM, balaji marisetti wrote:
 Hi All,

 I have a doubt. Shouldn't the `EC_POINT_...` methods be returning -1
 instead of 0 on error conditions?

 Thanks,
 Balaji M
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org


 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org



-- 
:-)balaji
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org