On 14 May 2013 14:44, yassine ahmed for4for...@gmail.com wrote:
hi all,
please i don't know how calculate the icv (Integrity Check Value). used in
aes-gcm algorithm
The Integrity Check Value is known as the authentication tag.
In order to retrieve the tag you must call EVP_CIPHER_CTX_ctrl
All
CCM mode ciphers do not appear to be loaded as part of a call to
OpenSSL_add_all_ciphers. Is that a bug or on purpose?
Thanks
Matt
__
OpenSSL Project http://www.openssl.org
Development
Have you tried using the EVP version and then i2d_PUBKEY?
Matt
On 7 April 2013 10:14, crvchul julianmel...@gmail.com wrote:
Hello,
It would be very great if my problem could be solved here.
In C I have to make a Diffie-Hellman Key Exchange and the problem is that
the corresponding Java
Any thoughts on this issue?
As things currently stand binary curves are pretty much unusable in a FIPS
capable OpenSSL build.
Thanks
Matt
On 22 March 2013 19:41, Matt Caswell via RT r...@openssl.org wrote:
Hello
When using OpenSSL-1.0.1e-fips a call to PEM_write_bio_PrivateKey
silently
On 27 March 2013 21:03, Ben Laurie b...@links.org wrote:
The OSF is not actually the one that would benefit from such a
licence, so the whole idea that it (or we) should pay for one seems
weird to me.
Well, I wasn't actually suggesting that the OSF should pay for it
itself, merely that the OSF
On 6 February 2013 15:04, Steve Marquess marqu...@opensslfoundation.com wrote:
On 02/06/2013 09:43 AM, Salz, Rich wrote:
There are actually two licenses. The second allows all software (even
closed), but only for non-military use.
I would say that's still a problem. For example, we could
On 27 March 2013 11:52, Michael Sierchio ku...@tenebras.com wrote:
Does Phil still teach at UC Davis? You could always ask him directly
for clarification or a waiver.
Hi contact details are on the web page describing the various license
options (and yes its a UC Davis email address). It would
Hello
When using OpenSSL-1.0.1e-fips a call to PEM_write_bio_PrivateKey
silently fails and produces a corrupt pem file when using an
EVP_PKEY_EC key and a binary curve. The same function works fine when
not using a FIPS capable OpenSSL. I suspect the same problem will
affect any ASN.1 routines
On 21 March 2013 09:06, Leon Brits le...@parsec.co.za wrote:
First off the private key created with the sect233r1 curve are:
-BEGIN PRIVATE KEY-
MHYCAQAwCQYHKoZIzj0CAQRmMGQCAQEEHVnVyx1BHVTaKFSi758nc0v1SnWNQ1aR
BYRjL4ZboUADPgAEAVZmnrloR8NnuKI7pzD8n8UYXHannulPUv2JVqeiAXI1bnBR
On 20 March 2013 19:44, Steve Marquess marqu...@opensslfoundation.com wrote:
There are tools of a sort to convert between docbook, pod, and markdown.
I've played with a couple of them, but I think annoying little details
will keep such tools from representing any net labor savings over manual
On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote:
Hi Matt,
I use:
$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
I was able to successfully parse your attached private key.
I've attached my smallest prime, binary and kolbitz curve key pairs. As I
said the prime curve parses
Hi Leon
On 21 March 2013 17:27, Matt Caswell fr...@baggins.org wrote:
On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote:
Hi Matt,
I use:
$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
I was able to successfully parse your attached private key.
I've attached my smallest prime
On 20 March 2013 10:36, Leon Brits le...@parsec.co.za wrote:
List,
I've continued so long to use the NIST prime curves to implement sign/verify
using EVP. I am basically using the same code as for RSA and DSA. This
mechanism is so transparent (nice!) that I just want to verify that it is
On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote:
Hi Matt,
I use:
$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
I was able to successfully parse your attached private key.
I've attached my smallest prime, binary and kolbitz curve key pairs. As I
said the prime curve parses
On 20 March 2013 07:27, Leon Brits le...@parsec.co.za wrote:
Thanks for that explanation - so, just to understand the history, why is
there no secp256_r1 as well as the ANSI standard curve. In other words, why
does the ANSI curve replace it instead of being an additional curve?
I have no
On 20 March 2013 21:11, Matt Caswell fr...@baggins.org wrote:
On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote:
Hi Matt,
I use:
$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
I was able to successfully parse your attached private key.
I've attached my smallest prime, binary
On 19 March 2013 10:22, Leon Brits le...@parsec.co.za wrote:
Matt / List,
Thanks for the example. It sure helped a lot. But I am still stuck at the EC
key generation.
I’ve created keys for NIST Prime curves (224-571bit), Binary and Kolbits
curves (233-571 bit). I then convert the keys
On 19 March 2013 19:38, Steve Marquess marqu...@opensslfoundation.com wrote:
I took a quick look to see what utilities might be available to convert
between pod and mediawiki markup formats. pod2markdown (CPAN) is close
but not quite there.
The pod markup language is pretty basic. If something
On 19 March 2013 10:22, Leon Brits le...@parsec.co.za wrote:
I’ve created keys for NIST Prime curves (224-571bit), Binary and Kolbits
curves (233-571 bit). I then convert the keys to PEM using the same method
which I used successfully for RSA and DSA which only calls
PEM_write_bio_PrivateKey()
On Thu, Mar 14, 2013, Leon Brits wrote:
Hi List,
I just want to verify: Elliptic curve functions are not encapsulated by
the
EVP functions - correct? If so, what is the
EVP_PKEY_CTX_set_ec_paramgen_curve_nid function then used for? If NOT
so,
then please help with an example
This site would be a good place to start:
http://www.keylength.com/
Matt
On 6 March 2013 13:56, Ido Regev ido.re...@ecitele.com wrote:
We have a requirement from one of our customers regarding the encryption
algorithms – Make use of published public encryption algorithms that are
Hi Steve
On 4 March 2013 14:22, Dr. Stephen Henson st...@openssl.org wrote:
CMAC needs a separate API because it doesn't behave like a normal cipher.
Check out the CMAC_* functions. They behave in a very similar way to the
HMAC_* functions except they take a cipher instead of a digest
On 5 March 2013 14:13, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 05, 2013, Leon Brits wrote:
Just want to add that I do set the data sizes before EncryptUpdate and
DecryptUpdate and mentioned in the CCM section of the OpenSSL support
page.
This page does answer both my
On 5 March 2013 18:36, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 05, 2013, Matt Caswell wrote:
On 5 March 2013 14:13, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 05, 2013, Leon Brits wrote:
Just want to add that I do set the data sizes before
On 25/08/12 22:48, Andrey Kulikov wrote:
Does this behavior a bug, or somewhere documented convention?
I've studied FIPS 180-3, SP 800-57 and SEC 1: Elliptic Curve
Cryptography but didn't find any indications of such conventions.
Maybe I overlooked something?
By convention the key size for
On 26/08/12 14:50, Andrey Kulikov wrote:
By convention the key size for ECC is given as the number of bits in
the order.
E.g. see table 3 in SEC 1.
Could you please provide a reference to document, defining this
convention?
Unfortunatelly table 3 in section B.2.1 of SEC 1 (both v1 and v2)
On 26/08/12 16:15, Andrey Kulikov wrote:
For ECC the key size is stated to be size of n in bits (where n is
the order).
'n' is an order of base point 'G' on EC - i.e. size of private key
(what should be in range [1; n-1]), not public.
Thus, I understand that it is a size of EC private key
On 26/08/12 16:51, Andrey Kulikov wrote:
Talking about the bit-length of the public key data is not particularly
helpful because it depends on whether it is in compressed format or not.
Sorry, but size of public key does not depends on size of it's
representation.
It can be compressed,
Hello
The openssl EC library is a fantastic resource which provides an
extensive set of functions for performing work with elliptic curves.
Unfortunately the documentation available is somewhat minimalistic.
The documentation is not in the standard openssl pod format (it is
instead in doxygen
Hi
I have encountered a problem whilst building the HTML documentation. All
appears to build successfully, however when I view the file
crypto/crypto.html and click on the link dsa, this takes me to
apps/dsa.html instead of the expected crypto/dsa.html.
Interestingly the documentation on
901 - 930 of 930 matches
Mail list logo
