[ 
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934798#comment-13934798
 ] 

John Hewson edited comment on PDFBOX-1847 at 3/14/14 9:11 AM:
--------------------------------------------------------------

I'm in the process of adding this patch and making the necessary changes to 
PDFBox. I have some questions and feedback which need to be discussed:

# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the 
getTimeStampAttribute method of TSACreator, which means the message digest 
which gets created is:
{code}
MessageDigest.getInstance("2.16.840.1.101.3.4.2.1", new BouncyCastleProvider());
{code}
Why not use Java's built-in "SHA-256" message digest?
----
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
----
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, "nonce is" + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I 
have fixed this, but I still wanted to let you know about it.
----
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty("Content-Transfer-Encoding", "binary");
{code}
But "Content-Transfer-Encoding" is a MIME header for e-mails, not HTTP 
requests, is there some reason why it's there?
----
# In TSAUtils, the byteToASN1Object method has a try/catch for 
ClassCastException, but I don't see why this exception needs catching, does 
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
----
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
    Random rand = new Random();
    Integer randomNum = rand.nextInt((max - min) + 1) + min;
    BigInteger nonce = new BigInteger(randomNum.toString());

    Long timeLong = System.currentTimeMillis();
    Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;

    return nonce.multiply((new BigInteger(timeInt.toString())));
}
{code}
There are some problems with this approach. The first is that 
_java.util.Random_ is not cryptographically secure ([see 
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]). 
The second is that the current time is not a source of cryptographically secure 
entropy, furthermore it's already included in the seed for  _java.util.Random_ 
which means that multiplying the random nonce by the current time cannot 
improve the nonce. I will fix these issues by using SecureRandom, but I wanted 
to let you know about them.

Thanks!


was (Author: jahewson):
I'm in the process of adding this patch and making the necessary changes to 
PDFBox. I have some questions and feedback which need to be discussed:

# In CreateSignature you define SHA_256_IDENTIFIER which is passed to the 
getTimeStampAttribute method of TSACreator, which means the message digest 
which gets created is:
{code}
MessageDigest.getInstance("2.16.840.1.101.3.4.2.1", new BouncyCastleProvider());
{code}
Why not use Java's built-in "SHA-256" message digest?
----
# In TSACreator, the getTimeStampToken method generates an nonce as follows:
{code}
BigInteger nonce = TSAUtils.generateNonce(0, 97359710);
{code}
Where does magic value of 97359710 come from? Is it special?
----
# In TSACreator, creation of the nonce is immediately followed by:
{code}
log.log(Level.INFO, "nonce is" + nonce);
{code}
Which leaks the nonce to the log file before it has been sent to the server. I 
have fixed this, but I still wanted to let you know about it.
----
# In TSACreator, the openTSAConnection method sets the following HTTP header:
{code}
connection.setRequestProperty("Content-Transfer-Encoding", "binary");
{code}
But "Content-Transfer-Encoding" is a MIME header for e-mails, not HTTP 
requests, is there some reason why it's there?
----
# In TSAUtils, the byteToASN1Object method has a try/catch for 
ClassCastException, but I don't see why this exception needs catching, does 
bouncy castle throw it? (It shouldn't, but it is known to do things like that).
----
# In TSAUtils, the generateNonce method is as follows:
{code}
public static BigInteger generateNonce(int min, int max)
{
    Random rand = new Random();
    Integer randomNum = rand.nextInt((max - min) + 1) + min;
    BigInteger nonce = new BigInteger(randomNum.toString());

    Long timeLong = System.currentTimeMillis();
    Integer timeInt = timeLong != null ? timeLong.intValue() : 761820123;

    return nonce.multiply((new BigInteger(timeInt.toString())));
}
{code}
There are some problems with this approach. The first is that 
_java.util.Random_ is not cryptographically secure ([see 
documentation|http://docs.oracle.com/javase/7/docs/api/java/util/Random.html]). 
The second is that the current time is not a source of cryptographically secure 
entropy, furthermore it's already included in the seed for  _java.util.Random_ 
which means that multiplying the random nonce by the current time cannot 
improve the nonce. I will fix these issues by using SecureRandom, but I wanted 
to let you know about the issues with this method.

> TSA Time Signature
> ------------------
>
>                 Key: PDFBOX-1847
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-1847
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: Signing
>    Affects Versions: 2.0.0
>            Reporter: vakhtang koroghlishvili
>            Assignee: John Hewson
>             Fix For: 2.0.0
>
>         Attachments: CreateSignature-updated.java.patch, 
> TSATimeSignature.patch, resultOfSigning.jpg
>
>
> When we was signing document, we was using time from our time. For more 
> security we can use Time Stamp server. 
> "Trusted timestamping is the process of securely keeping track of the 
> creation and modification time of a document. Security here means that no one 
> — not even the owner of the document — should be able to change it once it 
> has been recorded provided that the timestamper's integrity is never 
> compromised."(wiki)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to