Kaz

1,056 reputation

210

bio	website	kylheku.com
	location	Vancouver, Canada
	age
visits	member for	1 year
	seen	13 hours ago
stats	profile views	34

Check out the TXR language http://www.nongnu.org/txr

	1,056 reputation	bio	website	kylheku.com	visits	member for	1 year
210 badges		location	Vancouver, Canada		seen	13 hours ago

summary answers questions tags badges favorites bounties reputation activity

68 Actions

suggestions reviews revisions comments badges posts accepts all

14h	comment	Lessons learned and misconceptions regarding encryption and cryptology @DW Well yes, since the division is explicit in the message, but those bits are not included in the hash!!! Do not hash payload and leave out the header or meta data. Hash the whole message. This is not a catenation issue. Whatever you exclude from a hash is not protected by it regardless of what it is. Length field that breaks up the payload into two parts, time stamp, or anything else.
1d	comment	Lessons learned and misconceptions regarding encryption and cryptology And if I put two bits together and hash them, aren't I catenating strings? So we must hash each bit separately so that it is identified. We wouldn't want attackers moving boundaries between bits so that 00 1 suddenly becomes 0 11.
1d	comment	Lessons learned and misconceptions regarding encryption and cryptology Okay, so we have two strings "builtin" and "securely". We put them together so there is no boundary "builtinsecurely". Where the division lies is not represented at all in the message in any way whatsoever. No framing bits or bytes, no length fields, nothing. And then we hash it. And so now the attacker "changes the boundary". How does the attacker change that which is not there?
1d	comment	Lessons learned and misconceptions regarding encryption and cryptology @D.W. Did I say encrypt? I meant to write "digest". There, fixed it. Good thing s.e. lets us edit comments hours after they are written.
2d	comment	Lessons learned and misconceptions regarding encryption and cryptology Wha??? This answer makes no sense. If the data is ambiguous, there doesn't have to be an attacker. Alice doesn't know how to interpret "builtinsecurely" because Bob didn't put in a space. This ambiguity is not a problem introduced by the attacker, but is rather inherent in the chosen data representation. How can we digest anything if we can't catenate? Every message more than one bit long is a catenation.
2d	comment	Lessons learned and misconceptions regarding encryption and cryptology It can't be a rule of cryptology not to invent crypto, and it's not a misuse of some existing API or algorithm.
May 15	awarded	Yearling
May 11	comment	How can I punish a hacker? Even if it is "his" IP, it could be a dynamic line which can be reassigned to another customer.
May 11	comment	How can I punish a hacker? @TomLeek writes: The said hacker already spends his nights on his computer, alone, staring at his bleak screen, looking for vulnerabilities and installing backdoors. How could you possibly punish him any further ? Yeah, but the ground is level on that point, since OP spends his nights on his computer alone, tracking down the activities of crackers attacking his website and dreaming up punishments.
May 11	comment	How can I punish a hacker? Punish crackers, reward hackers.
May 9	revised	Is salting a hash really as secure as common knowledge implies? deleted 66 characters in body
May 8	comment	Is salting a hash really as secure as common knowledge implies? But the most likely reason two records would have the same hash (in the absence of salt) is that the users in fact have the same password, not that they have different passwords with the same hash.
May 8	comment	Is salting a hash really as secure as common knowledge implies? Hash collisions over message digests are a different issue because hashes are the basis for digital signatures, and so that allows a signature to be moved to a forged document. Salts make the problem worse in that case because the forger can manipulate the salt to help construct the forgery. If the genuine document is not allowed to have any random garbage appended (i.e. the salt) then the forged document also cannot do that, otherwise it seems suspicious. The only weapon is a solid hashing function which makes it hard to find collisions.
May 8	comment	Is salting a hash really as secure as common knowledge implies? I don't see why collisions are a problem (that you can find another string that works as the password). It's a problem in the very hypothetical case that you pick a very strong password, but it collides with "passw0rd". :)
May 8	answered	Is salting a hash really as secure as common knowledge implies?
May 8	comment	Is salting a hash really as secure as common knowledge implies? Eliminating hashing collisions is a complete non-issue here. That matters in hash tables, and in hash tables you cannot append add random bits to the search keys just to eliminate collisions, because then you're changing the search keys. So "Bob" is not found in the hash table, because, silly you, you should have been searching for "Bob0z+dKl".
Apr 29	comment	CTRL+ALT+DEL Login - Rationale behind it? I do not believe the claim that Ctrl-Alt-Del was never intended for users.
Apr 16	awarded	Scholar
Apr 16	awarded	Supporter
Apr 16	accepted	What are security implications of enabling access to performance counters on ARM Cortex A9?