[
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934798#comment-13934798
]
John Hewson commented on PDFBOX-1847:
-------------------------------------
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)
