>       From: owner-openssl-us...@openssl.org On Behalf Of Chuck Pareto
>       Sent: Monday, 24 May, 2010 19:13

>       When I run openssl rsa to display my public key info. I see this
below. 
> How do I convert this output to a byte array? What is this output? Is it
ascii or base64?
        
>
00,ac,80,e7,da,fb,6b,82,d2,01,ac,cf,74,fa,dc,
<snip>

Do you really get commas for -text? As long as I can remember openssl's
format 
here (and several similar places) is colons. Certainly in all the versions 
I have it is bytes in hex separated by colons (and linebreaks as needed), 
and what you have certainly looks like hex (and is the right length). So:

- in a language that has hex literals like C++ you could just do 
  unsigned char modulus [] = { /*0? see below*/ 0xac, 0x80, 0xe7 etc etc
I don't know if C# does this or something (sufficiently) similar.

- otherwise convert each byte to decimal and use those. As noted, 
a simple perl or awk script could do this. 

Or, on Unix or with Unixy tools like mingw, you *could*:
  # convert pem to 'raw' (binary) DER
  openssl rsa -in public.pem -pubin -out public.der -outform der
  # or more simply
  openssl base64 -d -in public.pem -out public.der

  # locate the portion that is the actual pubkey (a BIT STRING)
  # and within that locate the part that encodes the modulus
  openssl asn1parse -in public.der -inform der 
  openssl asn1parse -in public.der -inform der -strparse $locBITSTRING
  # where locBITSTRING should be 18 or 19 depending on key size.
  # Add offset of BITSTRING plus its hl (header length) plus 1 
  # plus offset of first INTEGER within (3 or 4) plus its hl (3 or 4)
  # giving location in file, and take the INTEGER's length (l);
  # optionally adjust loc+1 and len-1 for leading 0, see below.

  # display those bytes in decimal
  od -j $loc -N $len -t u1 public.der # unsigned or -t d1 for signed
  # (and ignore the offset column; I've found no standard way to omit)

Note that the ASN1 encoding in the file, and displayed by openssl, 
has a leading zero byte (00) because it's 'full-width' signed.
Other software may not need or even allow this. The (C#) RSA-Provider 
example you pointed to did not have it, so presumably you can drop it 
and maybe you must. 

Also, in one of the other pages nearby on the M$ website, 
I saw some mention of some (PKC) data being little-endian. 
I *think* this was only in relation to older CAPI not dotnet,
but it wasn't entirely clear; however the Encrypt example was 
clearly big-endian, and openssl, and ASN1, is big-endian -- 
so I doubt this is a problem, but you might keep it in mind 
as a possible issue if you do have problems that appear related 
to invalid/wrong key or damaged/improper ciphertext value.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to