Using a torrent file from
http://torrent.ubuntu.com:6969/
I am calculating its hash which matches with the hash on the page.
Then i make a request to the tracker. Like
http://torrent.ubuntu.com:6969/announce?info_hash=9a81333c1b16e4a83c10f3052c1590aadf5e2e20
But i get
d14:failure reason63:Requested download is not authorized for use with this tracker.e
According to the spec this should work?
Tracker Spec
General Spec
You specified the info_hash in hex, rather than URL-encoding. The bytes of the SHA-1 hash should be encoded directly, like this:
http://torrent.ubuntu.com:6969/file?info_hash=%9A%813%3C%1B%16%E4%A8%3C%10%F3%05%2C%15%90%AA%DF%5E.%20
Also, for the announce URL, some additional parameters like peer_id are usually required.
Related
I am writing an https client to fetch https raw data using Wolfssl and http-parser. It works on regular HTML pages but not MIME type files.
The problem is that http-parser cannot decide the ending of the HTTP response stream. Based on my reading of the documents of http-parser and http protocol, I know that there are three signals related to the ending of a stream: content-length and '\r\n' after the response body and EOF. However, I found that many HTTP responses which contain a jpeg image don't contain them. For example, the response of this URL has no content-length and no '\r\n' and no EOF. https://raw.githubusercontent.com/wolfSSL/wolfssl-examples/master/SGX_Linux/README-images/expected-make-output.png
I wondered if there are other ways to find the ending of the stream or if there are some bugs in my code?
I have found a bug in my code.
After reading some data from the socket, I used strlen() of the recv_buf as the lengh of the receiving data. This may be right when reading data from regular HTTP pages but will fail when reading an image file.
So I guess http-parser can correctly find the ending of a response stream.
We want to create a logfile at customer site where
the customer is able to read the log (plain text)
we can verify at our site that the log file isn't manipulated
A few hundred bytes of unreadable data is okay. But some customers do not send us files where they can't verify that they do not contain sensible data.
The only reasonable option I see so far is to append a cryptographic checksum (e.g. SHA256(SECRET_VALUE + "logtext")). The SECRET_VALUE would be something hardcoded which is plain "security through obscurity". Is there any better way?
We use the DotNet-library and I do not want to implement any crypto algorithm by hand if that matters.
You can use standard HMAC algorithm with a secret key to perform the checksum.
Using a secret key prevents in a simple way that the checksum can be regenerated directly. A hardcoded key could be extracted from code, but for your use case I think is enough
The result is a binary hash. To insert it into the text file encode the value as hexadecimal or base64, and ensure you are able to revert the process in server side so you can calculate the hash again with the original file.
You could use also a detached hash file to avoid modifying the log file
Target
customer readable logfiles
verifyable by our side
minimum of binary data
must work offline
Options
Public-Private-key-things... (RSA, ...)
would be secure
but only binary data
Add a signature
We are not the first ones with that idea ( https://en.wikipedia.org/wiki/Hash-based_message_authentication_code )
DotNet supports that ( System.Security.Cryptography.HMACSHA256 )
Key must be stored somewhere ... in source
Even with obfuscation: not possible to do so securely
Trusted Timestamping
again: we are not first ( https://en.wikipedia.org/wiki/Trusted_timestamping )
needs connection to "trusted third party" (means: a web service)
Build Hash + TimeStamp -> send to third party -> sign the data (public-private-key stuff) -> send back
Best option so far
Add a signature with HMAC
Store the key in native code (not THAT easy to extract)
Get code obfuscation running and build some extra loops in C#
Every once in a while (5min?) put a signature into log AND into windows application log
application log is at least basically secured against modification (read only)
and it's collected by the our error report
easy to oversee by customer (evil grin)
I've been struggling for several days about how to compute the digest for the SignedProperties element in a XAdES signature. I have a reference XML file with the two digest values computed (the file being signed and and the signed properties), and I know it's good because it passes the verifiers. I computed the right digest value for the file being signed, but whatever I give as an input to the digest method (I use OpenSSL), I cannot get the same value that in the reference file. Of course my own file don't pass the verifier after that. I use the following command to compute the digest:
openssl dgst -sha256 -binary myfile.xml | openssl base64
I recorded the file myfile.xml by extracting the SignedProperties element of the reference file and saved it as is.
<xades:SignedProperties Id="xmldsig-f6a6a2a1-87af-4720-8eed-cf4532e99106-signedprops"><xades:SignedSignatureProperties><xades:SigningTime>2015-09-22T09:02:48.624+02:00</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><ds:DigestValue>cAJECbIzXZiLH+ILWPrM5jfA13GKcEC8t1qe7/BxqBM=</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName>CN=thawte SHA256 Code Signing CA,O=thawte\, Inc.,C=US</ds:X509IssuerName><ds:X509SerialNumber>13010307134774063901853305426952669967</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties><xades:SignedDataObjectProperties><xades:DataObjectFormat ObjectReference="#xmldsig-f6a6a2a1-87af-4720-8eed-cf4532e99106-ref0"><xades:Description>signature détachée du fichier indexfile.txt</xades:Description><xades:MimeType>text/plain</xades:MimeType></xades:DataObjectFormat></xades:SignedDataObjectProperties></xades:SignedProperties></xades:SignedProperties>
Apparently, I should get the value :
6JK3GHDL25+EIRefNMQJ3SOGSI8uzQ45PiziMomZkYs=
But I can't get it. I don't know if some transformations or canonicalization must be applied, the specification is very vague about this part. It's encoded in UTF-8, no line feeds.
Does anyone how to do this ? Any trick ?
I finally found out how to obtain the right digest value. Apparently, the same canonicalization algorithm must be applied to the SignedProperties element, although this is not described precisely in the recommendation. I missed two important things in generating the canonized form :
Auto-closed tags must be explicitly opened and closed : becomes
Any namespace declared in an ancestor element must be reported in the root element of the document subset, even if it is not used in this particular subset, which I found quite weird.
Anyway the correct canonized form for this subset is :
<xades:SignedProperties xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#" Id="SignedProperties"><xades:SignedSignatureProperties><xades:SigningTime>2015-09-22T09:02:48.624+02:00</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod><ds:DigestValue>cAJECbIzXZiLH+ILWPrM5jfA13GKcEC8t1qe7/BxqBM=</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName>CN=thawte SHA256 Code Signing CA,O=thawte\, Inc.,C=US</ds:X509IssuerName><ds:X509SerialNumber>13010307134774063901853305426952669967</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties><xades:SignedDataObjectProperties><xades:DataObjectFormat ObjectReference="#SignedFile"><xades:Description>signature détachée du fichier indexfile.txt</xades:Description><xades:MimeType>text/plain</xades:MimeType></xades:DataObjectFormat></xades:SignedDataObjectProperties></xades:SignedProperties>
I don't understand at the moment how countersignings work.
I'm thinking about is it possible to manipulate a file and resign it with the orginal key including a faked countersign?
I'm using e.g.:
signtool.exe sign /f "mycert.pfx" /t "http://timestamp.verisign.com/scripts/timstamp.dll" /v "MyApp.exe"
So will I get a signed application with a contersign. But how does that work? Does the "timestamp" server simple sign the current timestamp? If I understand right that would be allow a replay attack. So that I could sign a file in the past.
How is the contersign protected?
In your particular case it's not countersigning at all. The Authenticode timestamp is included as an attribute in PKCS#7 packet of the original signature. It's a signature (its digest) that is timestamped. The server signs the digest and the time value with its certificate.
Consequently there's no room (or sense) for replay attack - if you change the data, you will get different timestamp packet and if you want to replace older timestamp of the same data with the new timesamp, you can just re-sign and re-timestamp the data instead of playing with timestamps.
I need to write a program that read the .eml files from IIS's mail drop box, but I can't find a definitive source that tells me the encoding of the .eml files. Is there a specification somewhere that tells me the encoding of the files, or do I just have to guess/assume one?
You need to read the Content-Transfer-Encoding header. This value will tell you how the email is encoded. The most common are 7-Bit (no encoding), Quoted-Printable (where you see a lot of =HEX pairs), and base64 (which is base 64 encoding).
Based upon that header value, you decode the following body part using the specified routine.
I found my answer at en.wikipedia.org/wiki/MIME: "The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters... "
Though it's too late to answer but eml file format nothing but a plaintext MIME (rfc822) file format for storing emails.