<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel">
    <title>gmane.comp.encryption.openssl.devel</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22684"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22683"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22682"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22681"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22680"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22679"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22678"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22677"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22676"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22675"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22674"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22673"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22672"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22671"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22670"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22668"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22667"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22666"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22665"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22664"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22684">
    <title>RE: Question on expiring certs on long-lived DTLS sessions</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22684</link>
    <description>&lt;pre&gt;
I don't think this is a -dev question, but not worth changing.


*certificate* lifecycle (approval, issuance, expiration, revocation, 
distribution, etc.) is external to SSL/TLS.

*session* lifecycle is kind of implicit in the TLS RFCs 
but I don't recall seeing any separate doc on it.

You need to to distinguish here between "context" (internal to 
openssl), "session" and "connection" which are not the same.


When a *session* is set up, yes. You normally create a (new) 
SSL/TLS connection by doing a full handshake which among other 
things validates the cert and creates a session; the session 
is basically the master-secret and authentication info.
You can then create additional connections using the same 
session, commonly called "resumption", if both endpoints 
(server and client) support it; openssl server does within 
a process by itself, and cross-process with some assistance;
openssl client does only with some application help.
Conversely and applicable to your question, you can create a 
new sessi&lt;/pre&gt;</description>
    <dc:creator>Dave Thompson</dc:creator>
    <dc:date>2013-05-22T23:22:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22683">
    <title>Re: [openssl.org #3052] [PATCH] OpenSSL 1.0.1e bug fix for x86_64-gf2m.pl use of STDOUT</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22683</link>
    <description>&lt;pre&gt;Looks like this goes with bug #2963 ("Windows build bug (perl/nasm
race) on OpenSSL 1.0.0c").

Other .pl files were fixed, but this one was somehow missed.

Phillip

On Tue, May 21, 2013 at 11:00 AM, Phillip Hellewell &amp;lt;sshock&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev&amp;lt; at &amp;gt;openssl.org
Automated List Manager                           majordomo&amp;lt; at &amp;gt;openssl.org

&lt;/pre&gt;</description>
    <dc:creator>Phillip Hellewell via RT</dc:creator>
    <dc:date>2013-05-22T14:08:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22682">
    <title>[openssl.org #3052] [PATCH] OpenSSL 1.0.1e bug fix for x86_64-gf2m.pl use of STDOUT</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22682</link>
    <description>&lt;pre&gt;My build script was failing to generate x86_64-gfm2.obj, both when
using masn and nasm.

Unlike all the other x86_64*.pl files, it was opening STDOUT directly,
so I changed it to work like the others and that fixed the problem.

Please apply this patch.

Thanks,
Phillip Hellewell

&lt;/pre&gt;</description>
    <dc:creator>Phillip Hellewell via RT</dc:creator>
    <dc:date>2013-05-22T14:06:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22681">
    <title>[openssl.org #3051] [PATCH] Build fixes for 8a97a330</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22681</link>
    <description>&lt;pre&gt;This patch fixes a couple of minor build issues on the current master
branch (8a97a330).

&lt;/pre&gt;</description>
    <dc:creator>Adam Langley via RT</dc:creator>
    <dc:date>2013-05-22T14:05:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22680">
    <title>[openssl.org #3050] x509 PEM certificate input parsing bug</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22680</link>
    <description>&lt;pre&gt;I hit a bug when inputting an x509 certificate into openssl. My CA is
Entrust.net, and they have some certificates for download that have no line
endings in the encoding. This causes openssl parser to fail when it tries
to read the certificate, even thought the certificate is valid. Here is the
response from Entrust.net:

I checked into this formatting question some more for you.  The Certificate

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev&amp;lt; at &amp;gt;openssl.org
Automated List Manager                           majordomo&amp;lt; at &amp;gt;openssl.org

&lt;/pre&gt;</description>
    <dc:creator>Casey McGinty via RT</dc:creator>
    <dc:date>2013-05-22T14:05:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22679">
    <title>Question on expiring certs on long-lived DTLS sessions</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22679</link>
    <description>&lt;pre&gt;

We want to be able to handle long-lived connections/sessions, and we are therefore wondering about situations where a client or server certificate may expire either 1)after we have established a context, or 2)after a session has started.  Perhaps the first question is: how often is a certificate validated?


Do we have to programmatically manage this situation (dealing with expiring certs &amp;amp; adding new certs) within our app, or is it possible to point to a cert store that we can then update with a new cert via the openSSL command line tool?

Thanks.
&lt;/pre&gt;</description>
    <dc:creator>Paul Pazandak</dc:creator>
    <dc:date>2013-05-21T19:53:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22678">
    <title>Question on expiring certs on long-lived DTLS sessions</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22678</link>
    <description>&lt;pre&gt;
All,

We want to be able to handle long-lived connections/sessions, and we are therefore wondering about situations where a client or server certificate may expire either 1)after we have established a context, or 2)after a session has started.  Perhaps the first question is: how often is a certificate validated?
[if there are docs that describe the certificate lifecycle (I couldn't find them), pls point us to them!]

From an initial digging into the code, it appears that the certificate is only validated before a session is set up.  So, if a cert expires after this, it will never be detected as long as the session is running.  Is this true?

Do we have to programmatically manage expiring certs (dealing with expiring certs &amp;amp; adding new certs) within our app, or is it possible to point to a cert store that we can then update external to the app (e.g. with a new cert via the openSSL command line tool) and then have the openSSL lib manage it?

Thanks!

Paul
&lt;/pre&gt;</description>
    <dc:creator>Paul Pazandak</dc:creator>
    <dc:date>2013-05-22T01:57:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22677">
    <title>Running OpenSSL test suite against custom crypto engine?</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22677</link>
    <description>&lt;pre&gt;Hey,

When 'make test' is invoked, a huge suite of tests is run against OpenSSL.
I have a custom OpenSSL engine (this one:
http://rt.openssl.org/Ticket/Display.html?id=2554 ), and I'm looking for
bugs in the whole stack (the hardware, the engine, etc).

Is there a way to run the test suite against a specific engine?

Thanks
-JT
&lt;/pre&gt;</description>
    <dc:creator>JT Olds</dc:creator>
    <dc:date>2013-05-21T22:31:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22676">
    <title>Re: Smart card support with Openssl</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22676</link>
    <description>&lt;pre&gt;

On 5/18/2013 2:09 PM, Rajeswari K wrote:

Have a look at
https://www.opensc-project.org/opensc/wiki/engine_pkcs11

This is an engine that can call pkcs11, either the OpenSC
or some other PKCS#11 implementation.




&lt;/pre&gt;</description>
    <dc:creator>Douglas E. Engert</dc:creator>
    <dc:date>2013-05-21T19:37:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22675">
    <title>Cipher sorting: ssl_cipher_apply_rule() never processes list with one member?</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22675</link>
    <description>&lt;pre&gt;Hi,
while debugging I discovered what I think is a bug in
the CIPHER list handling ssl_cipher_apply_rule().
I think it does not work for a list of size one.

OpenSSL version 1.0.1c.
ssl_ciph.c: 956
Function: ssl_cipher_apply_rule
951:        curr = head;
950:        last = tail;
......
954:   for (;;)
955:   {
956:     if ((curr == NULL) || (curr == last)) break;

The break criteria "(curr == last) is strange.
I arrive here with only ONE member in my list, so
-&amp;gt; head == tail  -&amp;gt; curr == last.
So it breaks the for loop directly and does not process the rule below.

I think the problem is specific for a list of one member.
Can someone please help to confirm if this is a bug or not?

Best regards
Peter
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev&amp;lt; at &amp;gt;openssl.org
Automated List Manager                           majordomo&amp;lt; at &amp;gt;openssl.org

&lt;/pre&gt;</description>
    <dc:creator>Peter Sandelin</dc:creator>
    <dc:date>2013-05-21T07:51:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22674">
    <title>Re: [PATCH][RFC] CPU Jitter random number generator</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22674</link>
    <description>&lt;pre&gt;On Tue, 21 May 2013 12:04:13 +0200
Andy Polyakov &amp;lt;appro&amp;lt; at &amp;gt;openssl.org&amp;gt; wrote:

Hi Andy,


Unfortuately I am not an assembler wizzard, but I guess you only try to
return parts of the rdtsc instruction?

Without optimization:

$ gcc -o test test.c
$ ./test &amp;gt; test.out
cat test.out | wc
 128886  128886  386814

Test with optimizations:

$ gcc -O2 -o test test.c
./test &amp;gt; test.out
$ cat test.out | wc
 270876  270876  812741

So, where is the problem?

This is performed on

$ cat /proc/cpuinfo | grep CPU
model name      : Intel(R) Core(TM) i7-2620M CPU &amp;lt; at &amp;gt; 2.70GHz


All values I see fluctuate according to the values in the graph in
chapter 2.

By any chance, did you disable your TSC (you could do that on a
per-process basis)?

Bottom line, with the code you suggest, I still see the same
fluctuations I used to draw the graphs in chapter 2. Note, this is just
a visual inspection of the values I see in test.out.


Very interesting that you have a different reaction on your system.

All tests I did so far on different CPUs&lt;/pre&gt;</description>
    <dc:creator>Stephan Mueller</dc:creator>
    <dc:date>2013-05-21T16:36:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22673">
    <title>Re: [PATCH][RFC] CPU Jitter random number generator</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22673</link>
    <description>&lt;pre&gt;Hi,


Consider following snippet:

static inline unsigned int rdtsc()
{ int eax;
        asm volatile("rdtsc":"=a"(eax)::"edx");
  return eax;
}
main()
{ int i;
  unsigned int diff1, diff0 = rdtsc() - rdtsc();

     for (i=0;i&amp;lt;10000000;i++)
        if ((diff1 = rdtsc() - rdtsc()) != diff0)
                printf("%u\n",-diff0), diff0=diff1;
}

How many lines do you think it would print? If I compile it with
optimization on, my Sandy Bridge system prints ... ~100 lines. Hundred
out of 10 million tries. Of the hundred half of values is 28 and half is
thousands and up, obviously timer interrupts. Thousands and up is
something you suggest to disregard, so all we have is single value of
28. What "miniscule variations" of which "instruction" are we talking
about? What I'm trying to say is that I can't see that you managed to
actually formulate what is "the root cause of entropy". "CPU execution
time jitter" does not describe it. I'd argue that variations originate
from interactions with memory subsystem. You use c&lt;/pre&gt;</description>
    <dc:creator>Andy Polyakov</dc:creator>
    <dc:date>2013-05-21T10:04:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22672">
    <title>RE: [openssl.org #2886] AutoReply: openssl cms cmsout serial number output format</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22672</link>
    <description>&lt;pre&gt;ping

-----Original Message-----
From: The default queue via RT [mailto:rt&amp;lt; at &amp;gt;openssl.org] 
Sent: Monday, October 01, 2012 9:29 AM
To: lusky&amp;lt; at &amp;gt;blown.net
Subject: [openssl.org #2886] AutoReply: openssl cms cmsout serial number output format 


Greetings,

This message has been automatically generated in response to the creation of a trouble ticket regarding:
"openssl cms cmsout serial number output format", a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been assigned an ID of [openssl.org #2886].

Please include the string:

         [openssl.org #2886]

in the subject line of all future correspondence about this issue. To do so, you may reply to this message.

                        Thank you,
                        rt&amp;lt; at &amp;gt;openssl.org

-------------------------------------------------------------------------
The serial number output for in cmsout is inconsistent with the format displayed by openssl x509 -text.  cmsout always displays an integer, whereas
x50&lt;/pre&gt;</description>
    <dc:creator>Jon Lusky via RT</dc:creator>
    <dc:date>2013-05-19T14:43:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22671">
    <title>Smart card support with Openssl</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22671</link>
    <description>&lt;pre&gt;Hello Users/dev Team,

Need some urgent help to program openssl for smart card/HSM.

Our smart card never shares private keys. All crypto operations such as
encryption,decryption will be performed by smart card. And any such actions
from openssl needs to be redirected to smart card. Only certicate is left
open.

Have read about pkcs11 crypto engine support at openssl. Currently we are
using openssl 0.9.8q. Does this version supports pkcs11 engine support?
If supports, can you provide which part of the code needs to be changed to
have successful handshake using smart card.

Currently our openssl code is expecting a private key to perform handshake.
When smart card is used, private_key is updated with NULL at SSL_ACCEPT().
Hence, its throwing as no shard cipher during handshake.

Please provide a sample application how to program openssl for smart card
 where private key is not known.

Thanks in advance.

Rajeswari.
&lt;/pre&gt;</description>
    <dc:creator>Rajeswari K</dc:creator>
    <dc:date>2013-05-18T19:09:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22670">
    <title>Re: simple https server using openssl</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22670</link>
    <description>&lt;pre&gt;Please do not double post to the same question to both mailing lists.
openssl s_client is just that, a client not a server.

If your looking for something other than a web server implementation of the
SSL/TLS protocol perhaps something higher level like node.js will suffice


On Fri, May 17, 2013 at 11:34 AM, Indtiny s &amp;lt;indtiny&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>Jason Gerfen</dc:creator>
    <dc:date>2013-05-17T18:02:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22668">
    <title>[openssl.org #3049] c_rehash skips PEM files with windows line feeds</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22668</link>
    <description>&lt;pre&gt;Perl script 'c_rehash' does not process PEM files that have
CRLF line feeds.
OpenSSL command line tool does not have a problem parsing PEM files with 
windows line feeds.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev&amp;lt; at &amp;gt;openssl.org
Automated List Manager                           majordomo&amp;lt; at &amp;gt;openssl.org

&lt;/pre&gt;</description>
    <dc:creator>Arnis Par?ovs via RT</dc:creator>
    <dc:date>2013-05-17T16:08:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22667">
    <title>Re: Integrity Check Value (ICV)</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22667</link>
    <description>&lt;pre&gt;The authentication tag is calculated during the encryption operation.
It must then be passed along with the encrypted message. The
decryption operation requires both parts. It is safe to pass the tag
"in the clear".

Matt
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev&amp;lt; at &amp;gt;openssl.org
Automated List Manager                           majordomo&amp;lt; at &amp;gt;openssl.org

&lt;/pre&gt;</description>
    <dc:creator>Matt Caswell</dc:creator>
    <dc:date>2013-05-17T08:17:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22666">
    <title>[PATCH][RFC] CPU Jitter random number generator</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22666</link>
    <description>&lt;pre&gt;Hi,

[1] patch at http://www.chronox.de/jent/jitterentropy-20130516.tar.bz2

To overcome the insufficient amount of entropy present (at least) on a
Linux box, I implemented the CPU Jitter random number generator
available at http://www.chronox.de/ . The heart of the RNG is about 30
lines of easy to read code. The readme in the main directory explains
the different code files. The new version now implements the RNG as an
OpenSSL engine as well as provides a patch for RAND_poll.

The documentation of the CPU Jitter random number generator
(http://www.chronox.de/jent/doc/index.html and PDF at
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and
pictures are better in PDF) offers a full analysis of:

- the root cause of entropy

- a design of the RNG

- statistical tests and analyses

- entropy assessment and explanation of the flow of entropy

The document also explains the core concept to have a fully
decentralized entropy collector for every caller in need of entropy.

The appendix of the do&lt;/pre&gt;</description>
    <dc:creator>Stephan Mueller</dc:creator>
    <dc:date>2013-05-17T07:12:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22665">
    <title>Re: Integrity Check Value (ICV)</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22665</link>
    <description>&lt;pre&gt;Ok but for decryption part , based on the example
(http://marc.info/?l=openssl-cvs&amp;amp;m=135042865227553) we need to provide the
authentication tag(gcm-tag or tag)

i have integrate this code ,how can i get this variable to use it.




--
View this message in context: http://openssl.6102.n7.nabble.com/Integrity-Check-Value-ICV-tp45101p45148.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev&amp;lt; at &amp;gt;openssl.org
Automated List Manager                           majordomo&amp;lt; at &amp;gt;openssl.org

&lt;/pre&gt;</description>
    <dc:creator>yassine ahmed</dc:creator>
    <dc:date>2013-05-16T13:35:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22664">
    <title>Re: Integrity Check Value (ICV)</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22664</link>
    <description>&lt;pre&gt;
The "Integrity Check Value" is known as the authentication tag.

In order to retrieve the tag you must call EVP_CIPHER_CTX_ctrl with a
"type" argument of EVP_CTRL_GCM_GET_TAG. A full example is available
here:

http://wiki.opensslfoundation.com/index.php/EVP_Authenticated_Encryption_and_Decryption

Also see the openssl manual:
http://wiki.opensslfoundation.com/index.php/Manual:EVP_EncryptInit%283%29#GCM_Mode

Matt
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev&amp;lt; at &amp;gt;openssl.org
Automated List Manager                           majordomo&amp;lt; at &amp;gt;openssl.org

&lt;/pre&gt;</description>
    <dc:creator>Matt Caswell</dc:creator>
    <dc:date>2013-05-15T21:38:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22662">
    <title>Re: [openssl.org #3046] bug report, openssl 1.0.1e sha1 hash generation</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/22662</link>
    <description>&lt;pre&gt;Hey,


root shell's built-in echo doesn't support "-n" parameter:

$ echo -n "12345" | openssl dgst -sha1 -hex
(stdin)= 8cb2237d0679ca88db6464eac60da96345513964
$ echo "-n 12345" | openssl dgst -sha1 -hex
(stdin)= 10298ad22a68325ec5b2a69f209cac87135a5884

Best regards,
Piotr Sikora
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev&amp;lt; at &amp;gt;openssl.org
Automated List Manager                           majordomo&amp;lt; at &amp;gt;openssl.org

&lt;/pre&gt;</description>
    <dc:creator>Piotr Sikora</dc:creator>
    <dc:date>2013-05-15T18:06:43</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.encryption.openssl.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.encryption.openssl.devel</link>
  </textinput>
</rdf:RDF>
