Re: [openssl.org #2981] BUG: 1.0.1e 64-bit C implementation ECDHE* chiphersuites incompatible with https://google.com

2013-02-15 Thread Serguei E. Leontiev 
Hi, Andy,

> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=750398acd85a7ae220d272d28a76dff7bb269c31
> works around this one.
> 
> Serguei, could you test if it fixes even your problem[s]?

Thank you. OK, ectest passed.

-- 
Sorry for my bests English.
 
Sternberg Astronom. w:+7(495)780-4820 USSR,Moscow,127018,Sushchevskij val 16-5
Institute, MSU  h:+7(495)318-1146 USSR,Moscow,113303,Kakhovka 6-40
m:+7(916)686-1081 SMS: 
   



14.02.2013, в 12:56, Andy Polyakov via RT  написал(а):

 Probably this "strict aliasing" 64-bit optimization bug for 
 "crypto/bn/bn_nist.c"
>> 
>> What bug are you talking about?  There doesn't seem to be a strict
>> aliasing warning in that file, and they use a union to get around
>> the problem.
>> 
 Mac OSX compiler fail test/ectest: cc [Apple LLVM version 4.2 
 (clang-425.0.24) (based on LLVM 3.2svn)] gcc-mp-4.3 gcc-mp-4.4 gcc-mp-4.5 
 gcc-mp-4.6 clang-mp-3.0 clang-mp-3.1 clang-mp-3.2
 
 Mac OSX compiler test/ectest OK: gcc-apple-4.2 gcc-mp-4.7 gcc-mp-4.8 
 [gcc-mp-4.8 (MacPorts gcc48 4.8-20130203_0+universal) 4.8.0 20130203 
 (experimental)] clang-mp-2.9 clang-mp-3.3 [clang version 3.3 (trunk 
 173279)]
>> 
>> I can at least reproduce the problem with clang 3.0.
> 
> Oh, that I managed to reproduce.
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=750398acd85a7ae220d272d28a76dff7bb269c31
> works around this one.
> 
> Serguei, could you test if it fixes even your problem[s]?
> 
>> PS: I think at least this patch makes sense, but doesn't change anything:
>> --- a/crypto/bn/bn_nist.c
>> +++ b/crypto/bn/bn_nist.c
>> @@ -530,7 +530,7 @@ int BN_nist_mod_224(BIGNUM *r, const BIGNUM *a, const 
>> BIGNUM *field,
>>{
>>NIST_INT64  acc;/* accumulator */
>>unsigned int*rp=(unsigned int *)r_d;
>> -   const unsigned int  *bp=(const unsigned int *)buf;
>> +   const unsigned int  *bp=(const unsigned int *)buf.ui;
>> 
>>acc  = rp[0];   acc -= bp[7-7];
>>acc -= bp[11-7]; rp[0] = (unsigned int)acc; acc >>= 
>> 32;
> 
> The typo will be fixed as we go.
> 
> 
> __
> 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

[openssl.org #2992] [PATCH] Fix POD errors to stop make install_docs dying with pod2man 2.5.0+

2013-02-15 Thread Lutz Jaenicke via RT 
Applied.

Thanks,
Lutz

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

[openssl.org #2992] [PATCH] Fix POD errors to stop make install_docs dying with pod2man 2.5.0+

2013-02-15 Thread Nick Alcock via RT 
podlators 2.5.0 has switched to dying on POD syntax errors. This means
that a bunch of long-standing erroneous POD in the openssl documentation
now leads to fatal errors from pod2man, halting installation.

Unfortunately POD constraints mean that you have to sort numeric lists
in ascending order if they start with 1: you cannot do 1, 0, 2 even if
you want 1 to appear first. I've reshuffled such (alas, I wish there
were a better way but I don't know of one).
---
Applies against 1.0.1, 1.0.2, and master, though it only fixes POD
errors known to exist in 1.0.1.

 doc/crypto/X509_STORE_CTX_get_error.pod   |  2 ++
 doc/ssl/SSL_CTX_set_client_CA_list.pod|  8 
 doc/ssl/SSL_CTX_use_psk_identity_hint.pod |  4 
 doc/ssl/SSL_accept.pod| 10 +-
 doc/ssl/SSL_connect.pod   | 10 +-
 doc/ssl/SSL_do_handshake.pod  | 10 +-
 doc/ssl/SSL_shutdown.pod  | 10 +-
 7 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/doc/crypto/X509_STORE_CTX_get_error.pod 
b/doc/crypto/X509_STORE_CTX_get_error.pod
index a883f6c..60e8332 100644
--- a/doc/crypto/X509_STORE_CTX_get_error.pod
+++ b/doc/crypto/X509_STORE_CTX_get_error.pod
@@ -278,6 +278,8 @@ happen if extended CRL checking is enabled.
 an application specific error. This will never be returned unless explicitly
 set by an application.
 
+=back
+
 =head1 NOTES
 
 The above functions should be used instead of directly referencing the fields
diff --git a/doc/ssl/SSL_CTX_set_client_CA_list.pod 
b/doc/ssl/SSL_CTX_set_client_CA_list.pod
index 632b556..5e66133 100644
--- a/doc/ssl/SSL_CTX_set_client_CA_list.pod
+++ b/doc/ssl/SSL_CTX_set_client_CA_list.pod
@@ -66,16 +66,16 @@ values:
 
 =over 4
 
-=item 1
-
-The operation succeeded.
-
 =item 0
 
 A failure while manipulating the STACK_OF(X509_NAME) object occurred or
 the X509_NAME could not be extracted from B. Check the error stack
 to find out the reason.
 
+=item 1
+
+The operation succeeded.
+
 =back
 
 =head1 EXAMPLES
diff --git a/doc/ssl/SSL_CTX_use_psk_identity_hint.pod 
b/doc/ssl/SSL_CTX_use_psk_identity_hint.pod
index b80e25b..7e60df5 100644
--- a/doc/ssl/SSL_CTX_use_psk_identity_hint.pod
+++ b/doc/ssl/SSL_CTX_use_psk_identity_hint.pod
@@ -81,6 +81,8 @@ SSL_CTX_use_psk_identity_hint() and 
SSL_use_psk_identity_hint() return
 
 Return values from the server callback are interpreted as follows:
 
+=over 4
+
 =item > 0
 
 PSK identity was found and the server callback has provided the PSK
@@ -99,4 +101,6 @@ completely.
 PSK identity was not found. An "unknown_psk_identity" alert message
 will be sent and the connection setup fails.
 
+=back
+
 =cut
diff --git a/doc/ssl/SSL_accept.pod b/doc/ssl/SSL_accept.pod
index cc724c0..b1c34d1 100644
--- a/doc/ssl/SSL_accept.pod
+++ b/doc/ssl/SSL_accept.pod
@@ -44,17 +44,17 @@ The following return values can occur:
 
 =over 4
 
-=item 1
-
-The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
-established.
-
 =item 0
 
 The TLS/SSL handshake was not successful but was shut down controlled and
 by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
 return value B to find out the reason.
 
+=item 1
+
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
+established.
+
 =item E0
 
 The TLS/SSL handshake was not successful because a fatal error occurred either
diff --git a/doc/ssl/SSL_connect.pod b/doc/ssl/SSL_connect.pod
index cc56ebb..946ca89 100644
--- a/doc/ssl/SSL_connect.pod
+++ b/doc/ssl/SSL_connect.pod
@@ -41,17 +41,17 @@ The following return values can occur:
 
 =over 4
 
-=item 1
-
-The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
-established.
-
 =item 0
 
 The TLS/SSL handshake was not successful but was shut down controlled and
 by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
 return value B to find out the reason.
 
+=item 1
+
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
+established.
+
 =item E0
 
 The TLS/SSL handshake was not successful, because a fatal error occurred either
diff --git a/doc/ssl/SSL_do_handshake.pod b/doc/ssl/SSL_do_handshake.pod
index 2435764..7f8cf24 100644
--- a/doc/ssl/SSL_do_handshake.pod
+++ b/doc/ssl/SSL_do_handshake.pod
@@ -45,17 +45,17 @@ The following return values can occur:
 
 =over 4
 
-=item 1
-
-The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
-established.
-
 =item 0
 
 The TLS/SSL handshake was not successful but was shut down controlled and
 by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
 return value B to find out the reason.
 
+=item 1
+
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
+established.
+
 =item E0
 
 The TLS/SSL handshake was not successful because a fatal error occurred either
diff --git a/doc/ssl/SSL_shutdown.pod b/doc/ssl/SSL_shutdown.pod
index 89911a

[openssl.org #2991] Certifacte verification with a RSA-SHA512 hash algorithm fails

2013-02-15 Thread Stephen Henson via RT 
On Fri Feb 15 10:24:22 2013, woll...@igel.com wrote:
>
> we are using OpenSSL 0.9.8k. It's not the command line utility.
> We are linking against libcrypto and libssl. We load the CA
> certificates with SSL_CTX_set_default_verify_paths (c_rehash has
> been executed before), disable the automatic verification by
> setting SSL_CTX_set_verify to SSL_VERIFY_NONE, to the handshake
> with BIO_do_handshake, get the server certificate with
> SSL_get_peer_certificate and then verify the certificate by using
> SSL_get_verfify_result. The result value of this function is set to
> X509_V_ERR_CERT_SIGNATURE_FAILURE. The problem seems to be the
> signature algorithm which is used: sha512WithRSAEncryption.
>

Are you including a call to OpenSSL_add_all_algorithms() in your application?
SSL_library_init() only adds a subset of supported signature algorithms and
doesn't include SHA512.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

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

Re: [openssl.org #2978] CVS repositories serving stale data

2013-02-15 Thread Vladimir Kotal 

On 02/07/13 23:35, Andy Polyakov via RT wrote:

The CVS repositories on cvs.openssl.org are still up and serving stale
data. Please turn them off


If you're referring to http://cvs.openssl.org, then removal would hardly
be appropriate, because there are references to it in lists and RT. It
would be appropriate to switch off anonymous CVS access.


That's what I meant.

Thanks,


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

verify certificate by OCSP server failed

2013-02-15 Thread vikony vikon 
Hi all,
i tired to verify a certificate by using OCSP server and i am gettting the 
following error:


[root@VMQCRND30 apache]# openssl ocsp -issuer CA29.cer -cert CARD1.cer -url 
http://ocsp.nsn0.rcvs.nit.disa.mil
Error connecting BIO
Error querying OCSP responsder
139778352207688:error:0200206E:system library:connect:Connection timed 
out:bss_conn.c:269:host=ocsp.nsn0.rcvs.nit.disa.mil:80
139778352207688:error:20073067:BIO routines:CONN_STATE:connect 
error:bss_conn.c:273:

Any idea?
Does is it related to the fact i am using proxy serveR?
thx
vIK
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2989] AutoReply: OpenSSL-1.0.1e fails test suite on OSX

2013-02-15 Thread Andy Polyakov via RT 
> The current Macports Portfile specifies:
> 
>  -L${prefix}/lib --openssldir=${prefix}/etc/openssl zlib no-krb5 shared 
> no-asm
> 
> Removing no-asm allows test suite to run with 100% passes.
> 
> So the problem is appears to be the C-code version of the related code.

Please follow http://rt.openssl.org/Ticket/Display.html?id=2981.



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

Re: [openssl.org #2989] AutoReply: OpenSSL-1.0.1e fails test suite on OSX

2013-02-15 Thread David Favor via RT 
The current Macports Portfile specifies:

 -L${prefix}/lib --openssldir=${prefix}/etc/openssl zlib no-krb5 shared 
no-asm

Removing no-asm allows test suite to run with 100% passes.

So the problem is appears to be the C-code version of the related code.

-- 
Love feeling your best ever, all day, every day?
Click http://RadicalHealth.com for the easy way!


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

Re: [openssl.org #2784] [PATCH] Eefficient implementations of SHA256 and SHA512, using the Simultaneous Message Scheduling method

2013-02-15 Thread Andy Polyakov via RT 
>>  [1] S. Gueron, V. Krasnov: "Parallelizing message schedules to accelerate 
>> the
>>  computations of hash functions", http://eprint.iacr.org/2012/067.pdf
>>  
>>
> ...
> 
> As for Haswell. As discussed it's capable of executing 8xSMS SHA256 and 
> 4xSMS SHA512, i.e. loading 8/4x input blocks and pre-processing them 
> simultaneously. Improvement estimates are much higher, 14% for SHA256 
> and 20% for SHA512. On the other hand the processor is also capable of 
> loading 2x data and pre-processing already parallelized schedules 
> simultaneously... More careful consideration will be given at later point.

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=c4558efbf3a44a1b5e68dce46347dd3888db4760
adds AVX2 code. The code does not use SMS either, not in form discussed
in paper. This is because estimated performance improvement is even less
than for AVX1 code, at most 3% for SHA256 and 1.5% for SHA512. Estimate
is based on amount of computational instructions, i.e. discounting for
zero-latency moves. For reference. Above 14/20% estimate refers to
improvement over code that doesn't pre-process multiple input blocks at
all. While 3/1.5% are "relative" to committed code that loads pair of
input blocks and process them in parallel. In other words there is
simultaneous message schedule processing taking place, simply not in way
suggested in paper.


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

[openssl.org #2991] Certifacte verification with a RSA-SHA512 hash algorithm fails

2013-02-15 Thread Dominic Wollner via RT 
Hi,

we are using OpenSSL 0.9.8k. It's not the command line utility. We are linking 
against libcrypto and libssl. We load the CA certificates with 
SSL_CTX_set_default_verify_paths (c_rehash has been executed before), disable 
the automatic verification by setting SSL_CTX_set_verify to SSL_VERIFY_NONE, to 
the handshake with BIO_do_handshake, get the server certificate with 
SSL_get_peer_certificate and then verify the certificate by using 
SSL_get_verfify_result. The result value of this function is set to 
X509_V_ERR_CERT_SIGNATURE_FAILURE. The problem seems to be the signature 
algorithm which is used: sha512WithRSAEncryption.

The CA certificate:
-BEGIN CERTIFICATE-
MIIFXTCCA0WgAwIBAgIQJ2goVVph+bhIJDNPz39sajANBgkqhkiG9w0BAQ0FADBB
MRQwEgYKCZImiZPyLGQBGRYEdGVzdDETMBEGCgmSJomT8ixkARkWA3JkcDEUMBIG
A1UEAxMLcmRwLXRlc3QtQ0EwHhcNMTMwMTIzMTQwMTMxWhcNMTgwMTIzMTQxMTI5
WjBBMRQwEgYKCZImiZPyLGQBGRYEdGVzdDETMBEGCgmSJomT8ixkARkWA3JkcDEU
MBIGA1UEAxMLcmRwLXRlc3QtQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC9KPfTsIOH3fAYVLPibPrF4SWoTfyeAnintp7+Bt1I29CXJFAncFA3oDmc
L2DOJxp9X7rDcZ7+pxk9yssaqYQPEUyCxOZ6oeMMyYMlcfWN0bVp30vRl7FxU1nL
G2pZLjrbbB1//IoOVKQR4ku2ayAv9ASRFcKojj00MMNwBQukTJhaEDgou7z8UewM
OWnzDAtTlHnK+foAHWhFbVAQYjbElyW0nzBbtc0wASq+VuXVSI/usIy81ll2tQyA
7DkoG9p+nKL9tlgtFXkg5K5qM2W4+D9wqZqWJc0qsEIJMi29csj0juCV37eb2ETl
8pAs+0Z7fv6Iw6b9IizpFYMNm7xHCRJw+uyfiudLFPk+gAEkhgtdlsS9qWQaeBY/
yeWLxSrNa3/hLCDhLZ8WZs2OS3RKlJP0Kw++SiAVh0g9+bjJnfvvPQ8h2QvkLF1F
xOi/xs2ngtmAQlUusf4Z5mWGa2scy0khLXAC5aGKe10UO4dVKZNcFvREhbzPqtPD
AtPRSU9V/tsbjVpMJEQQVfx8yPoujZkOK/VsjxATVI4Sw9Grsx4koTAcbli0fTSm
zdgewI/5jqNfR+xmBfGbsuqZ1EYjE8kA5K64rmxhw7b0kFVNWziLk3wKekQxrrqt
EMZF+rjMr9fuJjXw2d72yHHnTx/dSdbnKrHgfgPy15Zh8iVlCQIDAQABo1EwTzAL
BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU6EAyH5hw4hjk
74TpjnsbYq1jv3MwEAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQENBQADggIB
ADfDjc6yq7M3P/tWb0tPU0xaG6xh/o1CPHn5HDUswqMpYN077vO6/ggznWuaTW7C
s7r+ApzC97wCiAMIx/RKG5/Z+qQTSjB9kJUcgyxjdGcOxh9ZgU5solzXDwRaudoO
VNvlbl4rrRrHZqo/mMUpXTo/89rZ9oX7cZHRk3M2f8ISGBWhnAgb/vabSly43JEp
joQWx5Q16BfPlPzBFfPL3o5nhSQ2j1GfTBBuECR3hCFDIKAM3jIYs0AjBQcFwoV1
DY5nr76pN0veYNTtdDEuNtxuM8RIlQzVpPFbIBNG/UUJ0JwjhE0QyPIQF8lzikxd
vCjFY9bTmiMEtZQeMjvM3V8jj8d0jFUTRmHLb9XdNYAmp9HOFbbabV7L27PuJB3x
9hp+urUaZ994ltaWBl0CAY8T42s6qoWMJm2RrIyvgqy0khlEFLW+w4jGmkBN0SRt
5E52mu7RfQnVVo2EGQEIMDms19OXpMaRmRf+9TaZ6zAX87cKtzPl7mOnEV6ODhhn
WhUoPedLS4R1vy3Hm9Mlh3zFy3JFQc9JUZv/Hr5jen4RcUoSDyTCkk26Jqsz8bg1
1O069rrrbVRWBNb27nyh+4FKQ5xQhpMRrfoHnVbIKleQNBtS4e5OrGggl5tg+lIe
LrbwQt4y+hdIH2MTBLrvtr3IWMRKQ1pV3xhkTmqF1gIu
-END CERTIFICATE-

The received server certificate:
-BEGIN CERTIFICATE-
MIIHETCCBPmgAwIBAgIKYW2GkwAABDANBgkqhkiG9w0BAQ0FADBBMRQwEgYK
CZImiZPyLGQBGRYEdGVzdDETMBEGCgmSJomT8ixkARkWA3JkcDEUMBIGA1UEAxML
cmRwLXRlc3QtQ0EwHhcNMTMwMjA1MTI1OTQzWhcNMTQwMjA1MTI1OTQzWjAZMRcw
FQYDVQQDEw5SRFAzMS5yZHAudGVzdDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
AgoCggIBANcbsbmmRVxCsTX8v6rXNeL1kceJyMvCcfpvs5er0AyxCtpQdePF9B7a
JHFQl38Hjz8Q+3timn2pnqAl0nQBqaKOceIj/k8NFYcLoQVrg1t6RlXsPO393pWJ
pgh1A86SSZM33QyjhuJOLaGZoWLbroDVFujmEBsrCtpNWgz3juMpnnsXf5jQNbT8
h2KDdrY6PVnFV/SU8ogAf5kLMs2KdM8Ro0CFcKr6JUEjXGgUzmMi5/gCKZ2EAWsx
/oPl0wPagVNPfjayiDjxE85c5kHw0OTyQC6hJWZk2INVIxdX/GBvre8cbA1JvQUl
XKujr7HlLiU5hfokbBNK4wepS+ozQvkDVC/ZLrhT4/7dzJLsm7nvIpJks0Yb/sN+
kCM8+iAyrlLAmLHPKqWN9ssWTCu9qxjcscVFmEdr3wb+iW2jUYRMhKazwRfzznIp
X+CO5MV2uFf/taHkCNH8/cC35IgTFjdv/Gj5XSydEZ3qYvrOPjrut0GU1YlY00oR
rW+SMu7EHchAbSu93BVCy6pRYcph1HFvexFc1FEEZSB9ATbW+03X/0/oNNdYzsnf
oW7h8+S6xIAcOLiiUOBfyVCiPvU5f5TX+mCBeKU6KvL+JEYpmVrShhQtunEiP4OM
JmjOaF4XM6S3aR86kWexFLgg+KKBMyGwKYDlbsIFF6q+vW4Tj2/ZAgMBAAGjggIx
MIICLTAdBgkrBgEEAYI3FAIEEB4OAE0AYQBjAGgAaQBuAGUwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMBMA4GA1UdDwEB/wQEAwIFoDAdBgNVHQ4EFgQUQuYy
zpan1x1E+MkoXMvxcnf9bxgwHwYDVR0jBBgwFoAU6EAyH5hw4hjk74TpjnsbYq1j
v3MwgcQGA1UdHwSBvDCBuTCBtqCBs6CBsIaBrWxkYXA6Ly8vQ049cmRwLXRlc3Qt
Q0EsQ049cmRwMzAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9cmRwLERDPXRlc3Q/Y2VydGlm
aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1
dGlvblBvaW50MIG6BggrBgEFBQcBAQSBrTCBqjCBpwYIKwYBBQUHMAKGgZpsZGFw
Oi8vL0NOPXJkcC10ZXN0LUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2
aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXJkcCxEQz10ZXN0
P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0
aG9yaXR5MBkGA1UdEQQSMBCCDlJEUDMxLnJkcC50ZXN0MA0GCSqGSIb3DQEBDQUA
A4ICAQBijnOrxavSdXJ79yg1iivXfZtASj9j4JmbKVioi/r7XTjJTdGrO3WYcx8g
iEATIs4OVV/Lkb4ScPtrIsFQWq24k+TuqhftB7y0zChrW8yBgwnVhicjTgvuwL54
uiQ1QlE8AdB4Hz5CsB3zkSBr5lqupxQnKd2PE45L6kXPSA/uMGi2fcvn3k1SC0hy
Dh+1oJXl3RadnD0vYjKR12GNLy1jgpimfZLcyVYbxoJ/GmSFwiJmEtN6Gkf6sXa0
URY5n6T9v+1eSHi6X4vdAjhQbFbgE30UYhYNX5DLJsJjt4upN0Q7ZNurdHpNK/Oo
npR5Vxpbhr6hKY+b5ZkAMER2HQ11BkD24NejLSY7Db71SMejYIAC1KmkIzksgJ4b
69wSGCqoFNl+XVw8vFpfYpxGnEMb0os8wjrPOudA+AYtrMVB69bgLjXDvNAKT8ov
Q8fcT19qsbMJzGtEqxKtTa7i0Q8HTmTt4XY71tq+LQRSXPGrk6YSqOFG3IxWFW3E
376CQ6myX+2WVWvTfwSkHSMKQSWtniT8/DZwTIe8B/LKcOr+3P4PF5wjHToToZuC
JdJuKhjBDbZAa6m641