Jeremy Banks

201 reputation

bio	website	stackoverflow.com/u/1114
	location	Toronto, Ontario, Canada
	age	23
visits	member for	1 year, 9 months
	seen	18 hours ago
stats	profile views	6

email: jeremy@jeremybanks.ca

	201 reputation	bio	website	stackoverflow.com/u/1114	visits	member for	1 year, 9 months
17 badges		location	Toronto, Ontario, Canada		seen	18 hours ago

summary answers questions tags badges favorites bounties reputation activity

28 Actions

suggestions reviews revisions comments badges posts accepts all

May 12	awarded	Yearling
Apr 22	comment	How is CipherCloud doing homomorphic encryption? Official response: Responding to the Myths about CipherCloud’s Encryption Technology (and Hacker News discussion)
Sep 7	awarded	Critic
Mar 17	comment	What is the purpose of using different hash functions for the leaves and internals of a hash tree? Oops! Thank you for the clarification. New interpretation: The trees are secure in the context of BitTorrent because it already knows the total length of the input, so it's impossible for an attacker to add or remove leaves as would be necessary.
Mar 17	accepted	What is the purpose of using different hash functions for the leaves and internals of a hash tree?
Mar 17	comment	What is the purpose of using different hash functions for the leaves and internals of a hash tree? I realized that the reason BitTorrent's Simple Merkel Trees aren't vulnerable to this is that they're padded full by adding `0`-leaves (until the number of them reaches a power of two). On the other hand THEX allows unpaired leaf hashes to "float up" the tree into a spot where an internal hash would otherwise be expected.
Mar 17	comment	How does a “Tiger Tree Hash” handle data whose size isn't a power of two? I have inquired further about this point here: What is the purpose of using different hash functions for the leaves and internals of a hash tree?
Mar 17	asked	What is the purpose of using different hash functions for the leaves and internals of a hash tree?
Mar 16	revised	How does a “Tiger Tree Hash” handle data whose size isn't a power of two? added section 2.1 from document: I haven't seen the behaviour of using different hashes for leafs and internals in other hash tree descriptions.
Mar 16	suggested	suggested edit on How does a “Tiger Tree Hash” handle data whose size isn't a power of two?
Mar 16	accepted	How does a “Tiger Tree Hash” handle data whose size isn't a power of two?
Mar 15	comment	How does a “Tiger Tree Hash” handle data whose size isn't a power of two? @HenrickHellström Edited a bit to clarify my meaning; I'm asking about the implementation called "Tiger Tree Hash"/TTH in peer-to-peer protocols, not about Tiger-based hash trees in general.
Mar 15	revised	How does a “Tiger Tree Hash” handle data whose size isn't a power of two? added 175 characters in body; edited title
Mar 15	revised	How does a “Tiger Tree Hash” handle data whose size isn't a power of two? added 4 characters in body
Mar 15	asked	How does a “Tiger Tree Hash” handle data whose size isn't a power of two?
Feb 13	asked	Why not use CTR with a randomized IV?
Jan 4	comment	Does AES-CTR require an IV for any purpose other than distinguishing identical inputs? My tentative understanding is this: NIST SP800-38A Appendix B warns that "The initial counter blocks for each message that is encrypted under the given key must be chosen in a manner than ensures the uniqueness of all the counter blocks across all the messages". It also defines that the standard way of incrementing the counter value as what seems to be ordinary unsigned binary addition, so an IV of 0 in one message would result in its first block being ciphered in the same way as the second block of a message with an IV of 1.
Jan 4	awarded	Scholar
Jan 4	accepted	Does AES-CTR require an IV for any purpose other than distinguishing identical inputs?
Jan 4	comment	Does AES-CTR require an IV for any purpose other than distinguishing identical inputs? This is for a freenet-style peer-to-peer scheme: the URL will contain the hashes of both the plaintext (private) and the ciphertext (public). The ciphertext's hash is used to locate it on the network, after which it is decrypted and verified using the plaintext's hash.