dhoward wrote on Wednesday, May 11, 2011 20:01:
I was recently playing around with OpenSSL's EC_KEY interface, specifically
generating and examining keys generated using the curve sect233r1, when I
decided to print the raw key out, in hex form. A quick analysis showed me
that the key was
This is contrary to the specification: The total length of an Enhanced
Provider symmetric
key and its salt value cannot be greater than 128 bits.
So, I think this salt value should not have any influence, as the bits you can
set are the
trailing bits between the reduced key size and the one the
Remus Rusanu wrote on Saturday, May 07, 2011 07:41:
I need to exchange encrypted content with an existing application
on Windows with an RC4 key that is salted as per
http://msdn.microsoft.com/en-us/library/aa387782%28v=vs.85%29.aspx
(KP_SALT_EX). Note that this is not a passphrase and salt
Johannes Bauer wrote on Friday, May 07, 2010 11:40:
(encoding 15 characters) results in one result block being generated ...
when encrypting a full block ...
Then two result blocks are generated ...
PKCS#5 padding appends 1..blocksize padding bytes.
--
Peter-Michael Hager - acm senior -
On Friday, April 30, 2010 19:22 Stephan Müller wrote:
I am not sure but BN_generate_prime_ex sounds like its generates
(pseudo)primes. So you have with _very high_ probability gcd(C,N) = 1
for all N..
If the security of an algorithm relies on C and N to be relative
prime, then a very high
denot...@libero.it wrote on Friday, April 30, 2010 9:30:
I need to generate a BIGNUM C that is relatively prime
with a BIGNUM N( GCD(N,C)=1 )
is there a pre-built function in openssl library ??
You can do it in a simple loop like
do{
BN_generate_prime_ex(C,bits,0,NULL,NULL,NULL));
Adam Grossman wrote:
thanks for the info, but this is on linux.
The socket interface is almost the same on linux:
#include sys/socket.h
int hSocket;
int dwTimeout=1000; // milliseconds
setsockopt(hSocket,SOL_SOCKET,SO_RCVTIMEO,(void*)dwTimeout,sizeof dwTimeout);
The correct URL syntax (in accordance with RFC 1738/2396)
for your request is:
https://admin:ad...@192.168.167.166/
On Wed February 17 2010, cerr wrote:
Hi There,
I would like to open a session to an open ssl http server on port 443
without any manual keyboard entry.
I've tried the
Christoph,
these are the algorithms the Microsoft Enhanced RSA and AES CSP can manage:
RC2/4, 1/2/3DES, AES-128/192/256, RSA_SIGN/KEYX,
SHA-1/256/384/512, MD2/4/5, SHAMD5, MAC, HMAC.
(Extracted with CryptGetProvParam(,PP_ENUMALGS_EX,,,).)
As this CSP is usually associated with the private
Unlike PEM files, P12/PFX files are not base 64 encoded text files.
These directly have ASN.1 encoded content w/o line breaks.
On Thu November 12 2009, Michael S. Zick wrote:
On Thu November 12 2009, Midori Green wrote:
On Thu, Nov 12, 2009 at 7:01 AM, PMHager wrote:
Just a suggestion
Might be this can help you to solve the issue: In the attached gif is
the ASN.1 decoded content of the PFX (upper part) and the decrypted
content of the pkcs8ShroudedKeyBag's octet string (lower part).
A question regarding the Mac import attempt: Does the error occur
before or after it asks
Just a suggestion which does not consume much time:
The .P12 (or .PFX) formats from OpenSSL and Windows
are slightly different. To convert between the two,
just import the P12 into the MS CertStore My and
locate and export the certificate with its private
key from that list:
First you fill the rsa structure with the private key,
PEM_read_bio_RSAPrivateKey(in,rsa,NULL,NULL);
then you overwrite it with the public key.
PEM_read_bio_RSA_PUBKEY(in, rsa, NULL, NULL);
RSA_private_decrypt() which points to
RSA_eay_private_decrypt() requires the
private exponent rsa-d
In crypto\md5\md5_locl.h:
#define HASH_UPDATE MD5_Update
#define HASH_FINAL MD5_Final
#include md32_common.h
now in crypto\md32_common.h:
int HASH_UPDATE (HASH_CTX *c, const void *data_, size_t len)
{...}
int HASH_FINAL (unsigned char *md, HASH_CTX *c)
{...}
Please note that #define is not
It is in crypto\md5\md5_dgst.c:
int MD5_Init(MD5_CTX *c)
{
memset (c,0,sizeof(*c));
c-A=INIT_DATA_A; // see #define INIT_DATA_A (unsigned long)0x67452301L
c-B=INIT_DATA_B; // see #define INIT_DATA_B (unsigned long)0xefcdab89L
c-C=INIT_DATA_C; // see #define INIT_DATA_C (unsigned long)0x98badcfeL
...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Patrick Patterson
Sent: Sunday, July 19, 2009 12:40 AM
To: openssl-users@openssl.org
Subject: Re: One CA for many clients (a silly question)
Hi there:
PMHager wrote:
Correct, as I already denoted these are from the obsolete
Correct, as I already denoted these are from the obsolete RFC2459.
As the IETF/PKIX charter could not define a consenting set of flags,
Steve Kent had suggested to drop them and leave it to the IPsec WG.
This has been done by RFC4809: Its recommendation is not to use any
extKeyUsage and, if
Extract from obsoleted RFC2459:
-- extended key purpose OIDs
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
id-kp-ipsecTunnelOBJECT IDENTIFIER ::= { id-kp 6 }
A possible solution might be to get a private enterprise number from the
http://www.iana.org/assignments/enterprise-numbers IANA
[http://www.iana.org/assignments/enterprise-numbers]. With this you can build
up your own
object identifier definitions (starting with 1.3.6.1.4.1..) and build up a
19 matches
Mail list logo
