artifact_id;status_id;status_name;priority;submitter_id;submitter_name;assigned_to_id;assigned_to_name;open_date;close_date;last_modified_date;summary;details;"Component";"Operating System";"Product"
688;1;"Open";3;214;"Goswin Brederlow, von";100;"Nobody";"2010-07-22 13:24";"";"2010-07-22 13:24";"Support for Bigarray as well as string";"The Bigarray module has several advantages over strings for use a buffer.  The data in a bigarray is allocated outside the GC heap and will not be moved by the GC. This allows the data to be accessed within caml_enter/leave_blocking_section() without the need to copy it first. This allows a zero copy read()/write() or use of libaio for IO.

The same applies to e.g. computing a sha1 digest. It would be nice if one could use a Bigarray in place of the string. This would allow the sha1 function to run within caml_enter/leave_blocking_section() and in parallel with other threads.

For an example on how to do it see my Patch for the Digest module. You can probably copy the code straight from there with minimal adjusting: http://caml.inria.fr/mantis/view.php?id=5005

MfG
   Goswin
";"None";"None";"None"
1090;1;"Open";3;158;"Romain Bardou";100;"Nobody";"2012-01-30 16:19";"";"2012-01-30 16:19";"PKCS1.5 and OAEP Padding + miscellaneous thoughts";"This library seems very well designed, but I have some thoughts.

- Maybe a smart constructor for RSA keys could be provided, of type:

val custom_key: ?size: int -> ?p: string -> ?q: string -> ?dp: string -> ?dq: string -> ?qinv: string -> ~n: string -> ~e: string -> ~d: string -> key

(The size field can be computed from n.) This would also make it more clear that the CRT fields are not mandatory. In fact, d and e could also be optional if one only wants to decrypt or encrypt, respectively.

- The RSA.new_gen documentation states that e=3 is faster. It is also weaker. Indeed, for small values of m and if e=3, m^e is less than n, and so m^e mod n = m^e, thus one does not need the private key to decrypt; one just needs to compute the cubic root.

- There is no padding scheme provided for RSA. I would suggest PKCS1.5 and OAEP. The former is weak (Bleichenbacher attack) but is still widely used, the latter is less weak (there is sometimes the Manger attack) but is less easy to implement.

- The Padding module assumes that the padded text will stay at the beginning of the block. This may be true for most block cipher mechanisms, but it is not for RSA paddings such as PKCS1.5 and OAEP. The former, for instance, is:

00 02 (8 positive random bytes) (some other positive random bytes) 00 (plain text)

Thus the plain text is actually at the end. In fact, I would assume that most RSA paddings require the strong endian byte to be 00 to ensure the plain text is strictly less than n.

I'd like to hear your thoughts about this. These are just wishes; PKCS1.5 is easy to implement anyway, and OAEP is easier to implement once the hash functions are available. Your library already provides great functionality.";"None";"None";"None"
1223;1;"Open";3;7916;"Vincent Bernardoff";100;"Nobody";"2012-09-26 17:37";"";"2013-04-05 02:32";"sha512";"It would be nice to have sha512 and hmac_sha512 functions.";"None";"None";"None"