> The MAC should be computed over the encapsulated content of the
> S-HTTP message.
>
> -What will the size of this content over which mac is computed?
sizeof(Message) + 32bit + sizeof(shared key), if not the new HMAC is
used.
But: this all is written down in RFC 2660, could you please explain
your problem more detailed?
> -Also, can I request mac-info for a range of bytes that I haven't yet
> downloaded?
What are you doing?
Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"
-Yea, sorry. I'll reframe my question.
I want to know what the "encapsulated content" that the rfc is talking
about. I want to know how big this "encapsulated content" would be. Or,
in other words, the size of "message bits" that it considers in the
formula.
-Rest assured, I am not trying anything unethical. I want the hash of
the file in the remote http server, without having to download the file
itself. Can you help me?
Anand kumar <a.anandkumar@gmail.com> wrote:
> I want the hash of
> the file in the remote http server, without having to download the file
> itself. Can you help me?
Sorry. I think, I cannot help you. MACs in sHTTP are not per file but per
message AND time (AND key).
Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"
No wait, in that rfc link, there's a para under the hmac computation
that says that key and time are optional. Which would mean that I can
get only teh mac (or mac of mac) of the message bits, if I specified no
key and time in my previous message to the server.
Now can you/anyone help me with my questions?
-I want to know what the "encapsulated content" that the rfc is talking
about. I want to know how big this "encapsulated content" would be. Or,
in other words, the size of "message bits" that it considers in the
formula.
-I want the hash of the file in the remote http server, without having
to download the file
itself. Is this possible?
Any resource pointed out that talks about this would be great too.
Anand kumar <a.anandkumar@gmail.com> wrote:
> No wait, in that rfc link, there's a para under the hmac computation
> that says that key and time are optional. Which would mean that I can
> get only teh mac (or mac of mac) of the message bits, if I specified no
> key and time in my previous message to the server.
2.4.5. MAC-Info tells me, that only time is optional. But you will
not get a hash for a file with this, even if the secret also would be
optional, because sHTTP requires a MAC for the encapsulated content
of a message, and not a hash over the binary representation of a file.
Sorry. Also the HMAC does not work for this.
> -I want to know what the "encapsulated content" that the rfc is talking
> about. I want to know how big this "encapsulated content" would be. Or,
> in other words, the size of "message bits" that it considers in the
> formula.
The encapsulated content means, if you're transmitting a file, message
header and the encoded representation of the transported data, not the
binary representation of only the file content.
> -I want the hash of the file in the remote http server, without having
> to download the file
> itself. Is this possible?
Don't think so.
But, another question: _why_ do you want to have this? Perhaps it could
be possible to solve your needs in another way.
Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"
>The encapsulated content means, if you're transmitting a file, message
>header and the encoded representation of the transported data, not the
>binary representation of only the file content.
This will not be a problem for what I have in mind, if u can confirm
that only http headers are included along with the file contents to
calculate the mac.
If this is so AND https allows me to request random blocks of data off
the server, I think I will be able get the hash of the encapsuated
content by aborting the transfer just after receiving the header.
>But, another question: _why_ do you want to have this? Perhaps it could
>be possible to solve your needs in another way.
Well, I am working on the possiblity of creating torrent files for
contents on a webserver without it's knowledge. This can be used to
relieve workload off the server in case of slashdots or generally.
Sorta like corral. But I don't want the website/server to install
another server/service just to do torrentification.
SiriusB <a.anandkumar@gmail.com> wrote:
> >The encapsulated content means, if you're transmitting a file, message
> >header and the encoded representation of the transported data, not the
> >binary representation of only the file content.
> This will not be a problem for what I have in mind, if u can confirm
> that only http headers are included along with the file contents to
> calculate the mac.
> If this is so AND https allows me to request random blocks of data off
> the server, I think I will be able get the hash of the encapsuated
> content by aborting the transfer just after receiving the header.
Don't think so. BTW: sHTTP is _not_ HTTPS.
> >But, another question: _why_ do you want to have this? Perhaps it could
> >be possible to solve your needs in another way.
> Well, I am working on the possiblity of creating torrent files for
> contents on a webserver without it's knowledge. This can be used to
> relieve workload off the server in case of slashdots or generally.
> Sorta like corral. But I don't want the website/server to install
> another server/service just to do torrentification.
Why don't you publicize just the .torrent files, and people are getting
content from bittorrent only? Or is this a misunderstanding?
Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"
Https question 
Linear Mode
