Ace:Validating Witness and Tokens - Revision history

Toaster at 18:13, 24 October 2008

2008-10-24T18:13:01Z

← Older revision		Revision as of 18:13, 24 October 2008
Line 152:		Line 152:
	==Validating CSIs and the IMS==		==Validating CSIs and the IMS==

	~~TBD~~		Validating CSIs against published witnesses is similar to the process for validating a digest against a CSI. The IMS provides the call, createWitnessProofForRound that takes a list of rounds and returns a list of responses containing the witness ID for that round, time the round was signed, and a proof linking that particular round to the witness value.

Toaster at 19:08, 18 September 2008

2008-09-18T19:08:04Z

← Older revision		Revision as of 19:08, 18 September 2008
Line 151:		Line 151:

	==Validating CSIs and the IMS==		==Validating CSIs and the IMS==

			TBD

Toaster at 18:11, 18 September 2008

2008-09-18T18:11:05Z

@@ Line 72: / Line 72: @@
 Once you have recalculated the CSI for a round, you can request the stored CSI for the round from the IMS and compare the two. If they are equal, then the token and hash is valid. If they do not match, then you either have a corrupt token or hash value.
 ===Calculate CSI===
@@ Line 147: / Line 115: @@
+     }
 </pre>
 ==Validating CSIs and the IMS==

Toaster at 18:10, 18 September 2008

2008-09-18T18:10:21Z

@@ Line 70: / Line 70: @@
 Using the token above, this diagram shows how the tree is rebuild from the bottom up.
 ===Converting String to byte array===
@@ Line 100: / Line 102: @@
+         }
          return b;
+     }
 </pre>
 ==Validating CSIs and the IMS==

Toaster at 18:04, 18 September 2008

2008-09-18T18:04:02Z

← Older revision		Revision as of 18:04, 18 September 2008
Line 68:		Line 68:

	[[Image:Ace-proof-diagram.png]]		[[Image:Ace-proof-diagram.png]]

			Using the token above, this diagram shows how the tree is rebuild from the bottom up.

	===Converting String to byte array===		===Converting String to byte array===

Toaster at 18:03, 18 September 2008

2008-09-18T18:03:21Z

← Older revision		Revision as of 18:03, 18 September 2008
Line 63:		Line 63:
	The values in the xml proof are the hex encoded values of the digest. See below for converting details.		The values in the xml proof are the hex encoded values of the digest. See below for converting details.

	The list of elements in the proof starts with the leaf nodes listed ~~first~~ and previous round CSI listed as the bottom ~~node~~. ~~The parent hash value for each level in~~ the tree ~~is obtained by running~~ the ~~digest on a byte array containing all the child nodes~~. ~~The index for each proof element indicates in where the previous generated hash should be inserted. For the bottom of~~ the tree, ~~this is~~ the hash of the file we are ~~testing, for all other levels,~~ it's the ~~value generated from~~ the ~~lower level~~.		The list of elements in the proof starts with the leaf nodes listed at the top and contains all levels of the tree through the previous round CSI, which is listed at the bottom. To generate the CSI, you start building the tree at the bottom. To start the tree, you take the hash of the file you are checking at combine it with the hash listed in the proof.

	For example, the first element specifies an index of 0. This means the digest for myfile.txt will be inserted first, followed by the proof's hash value.		For example, the first element specifies an index of 0. This means the digest for myfile.txt will be inserted first, followed by the proof's hash value. The two byte arrays will be concatenated and a sha-256 digest generated for the array. This generated digest will be inserted into the next higher level of the tree and the digesting process repeated. You repeat the insert and digesting until you have used all used all elements in the proof. The final value is your CSI.

			[[Image:Ace-proof-diagram.png]]

	===Converting String to byte array===		===Converting String to byte array===

Toaster at 17:55, 18 September 2008

2008-09-18T17:55:49Z

← Older revision		Revision as of 17:55, 18 September 2008
Line 63:		Line 63:
	The values in the xml proof are the hex encoded values of the digest. See below for converting details.		The values in the xml proof are the hex encoded values of the digest. See below for converting details.

	The list of elements in the proof starts with the leaf nodes listed first and previous round CSI listed as the bottom node. ~~Using~~ the proof from ~~above~~, the ~~partial tree would look like:~~		The list of elements in the proof starts with the leaf nodes listed first and previous round CSI listed as the bottom node. The parent hash value for each level in the tree is obtained by running the digest on a byte array containing all the child nodes. The index for each proof element indicates in where the previous generated hash should be inserted. For the bottom of the tree, this is the hash of the file we are testing, for all other levels, it's the value generated from the lower level.

			For example, the first element specifies an index of 0. This means the digest for myfile.txt will be inserted first, followed by the proof's hash value.

	===Converting String to byte array===		===Converting String to byte array===

Toaster at 17:29, 18 September 2008

2008-09-18T17:29:46Z

@@ Line 50: / Line 50: @@
 </pre>
-* token-class:
+* token-class: name of the service on the IMS that issued the token.
-* digest-service:
+* digest-service: name of the algorithm used when creating the proof
 * name: name of the file this token refers to. This was supplied by the client in a token request.
 * round-id: The ID of the round this token was issued in. This is used to request a CSI from the IMS.
@@ Line 58: / Line 58: @@
 ===Calculating CSI from Proof===
 ==Validating CSIs and the IMS==

Toaster at 16:07, 18 September 2008

2008-09-18T16:07:14Z

← Older revision		Revision as of 16:07, 18 September 2008
Line 8:		Line 8:

	Tokens are issued to clients after they submit a request. The request contains a hash to secure and a file name. All the hashes for a given time are gathered together and a summary value(CSI) is generated and stored on the IMS. After the round completes and a CSI is generated, clients are given a token that contains enough information to recalculate the CSI for its round. Comparing the recalculated CSI to the CSI stored on the IMS will let clients prove their hashes and tokens are valid.		Tokens are issued to clients after they submit a request. The request contains a hash to secure and a file name. All the hashes for a given time are gathered together and a summary value(CSI) is generated and stored on the IMS. After the round completes and a CSI is generated, clients are given a token that contains enough information to recalculate the CSI for its round. Comparing the recalculated CSI to the CSI stored on the IMS will let clients prove their hashes and tokens are valid.

			Here's what happens when a round is closed and a CSI needs to be calculated:

			# All the request hashes are set as the leaf nodes in a tree.
			# requests are paired together and a sha-256 digest is created for the pair. In the case of an odd number of requests, the last three hashes are paired together.
			# The created hashes, Intermediate Hash Value(IHV), are set as the parent nodes for the paired leaf nodes.
			# Similar to the previous pairing, IHV's are paired together and a digest is created for the pairs (or last triplet). This new digest is set as parent to the child IHV's.
			# The previous step is repeated until only one hash remains at the top of the tree, the Aggregated Hash Value(AHV).
			# The new AHV is taken and hashed with the previous CSI to create a new CSI for this round. The new CSI is assigned an ID.
			# A token for each request is generated containing the round ID and proof that will allow a client to regenerate the rounds CSI. See below on how to use this proof to reconstruct the CSI

	==Validating Tokens and Hashes==		==Validating Tokens and Hashes==

Toaster at 15:56, 18 September 2008

2008-09-18T15:56:00Z

← Older revision		Revision as of 15:56, 18 September 2008
Line 6:		Line 6:

	===Issuing Tokens===		===Issuing Tokens===

			Tokens are issued to clients after they submit a request. The request contains a hash to secure and a file name. All the hashes for a given time are gathered together and a summary value(CSI) is generated and stored on the IMS. After the round completes and a CSI is generated, clients are given a token that contains enough information to recalculate the CSI for its round. Comparing the recalculated CSI to the CSI stored on the IMS will let clients prove their hashes and tokens are valid.

	==Validating Tokens and Hashes==		==Validating Tokens and Hashes==