John Deters

1,035 reputation

bio	website
	location
	age
visits	member for	9 months
	seen	8 hours ago
stats	profile views	5

	1,035 reputation	bio	website		visits	member for	9 months
8 badges		location			seen	8 hours ago

summary answers questions tags badges favorites bounties reputation activity

57 Comments

suggestions reviews revisions comments badges posts accepts all

20h	comment	Requiring a “supervisor” key pair and a “user” key pair to decrypt multiple-recipient messages Oh, and see my comment below regarding needing to follow SSS on a per-message basis if you want Jim's level of control to be on a per-message basis. That means encrypting each message with a unique secret key, and securely distributing the shares with every message (most likely using public key cryptography.)
20h	comment	Requiring a “supervisor” key pair and a “user” key pair to decrypt multiple-recipient messages The SSS solution above gives Jim that ability. When he gives all his key parts to Alice, Alice now has the ability to decrypt - if Jim never gets a share in return (and why should he?) Jim still can not decrypt. It does give Alice enough shares to enable Mark to decrypt, but if she can be trusted with the message, she already has the level of trust required not to irresponsibly disclose the message or keys. It does imply that the SSS step has to happen on a per-message basis, though.
2d	comment	Increased CRC collision probability when adding bits to input message Ah, I misread 100 BITS as 100 BYTES. In this really limited case, you could get away with a one bit version indicator. Its state would indicate "current" version or "future" version, and once both sides were deployed, you would simply invert it at the next release of a new message spec. Which is where you were at with the original CRC question anyway. :) I'd still look to squeeze a byte out of an existing field. With a little bit masking wizardry, you could certainly turn the 8 bit CRC into a 7 bit CRC, and trade reliability as poncho suggests.
May 21	comment	Increased CRC collision probability when adding bits to input message The protocol you describe is so brittle that it is truly at the end of its useful life. You're spending more to maintain it than you would to replace it. To introduce the obligatory vehicle metaphor, if it were an automobile, you'd be towing this one to the junkyard and paying cash for a new one. You keep insisting that it can't be changed, but anything can be changed if you spend the money. It's time.
May 15	comment	True random numbers generated by sensors These sensors were designed by an engineer to measure acceleration; they were NOT designed to be a random number generator. Therefore the overly-high precision readings you are seeing have no engineering reason to reflect actual randomness. Yes, you can still use these sensors to generate randomness, but the only reliable way is to use them for their intended purpose to measure acceleration, and to derive randomness from that activity. Don't rely on the accidental fluctuations unless you understand how they are being generated.
May 15	comment	True random numbers generated by sensors You are better off using Apple's SecRandomCopyBytes(), which is a cryptographically secure random number generator. If you want to add the jitter from the accelerometer into the entropy pool, you can periodically write those bits into /dev/random. See developer.apple.com/library/mac/documentation/Darwin/Reference/… and developer.apple.com/library/ios/#documentation/Security/… for more info.
May 15	comment	True random numbers generated by sensors You are seeing "jitter". Those bottom bits are changing for some physical reason. It's possible the suspended mass is shaking due to ambient sound or other vibrations in the room, or due to a capacitive charge, or maybe even a small magnetic field. There is no guarantee that the reason isn't physical and predictable. What if a capacitive charge is causing the values to oscillate at a period that you don't yet recognize is synchronized with your polling of the sensor?
May 14	comment	Using an MD5 hash as a password In practice, there's another problem in that different sites have incompatible password complexity schemes. Some require upper and lower case, some require one or more special characters, while some prohibit those same special characters.
May 13	comment	random number generator 10-side dice alternative I suppose I should add that unless your attacker has the opportunity to map out the statistical distribution of generated letters you'll probably have "random enough" passwords to suit your purpose. As far as OTP keys go, be very careful not to take out more than one letter at a time as a shortcut. If I knew you took out 5 letters each time, my search space for testing keys is reduced considerably, and the perfect security of the Vernam cipher is broken.
May 9	comment	Winzip AES256 vs PGP WinZIP has its faults, but being available and convenient are also likely of consideration. Regardless, it's far more important to your security that you're following good key management practices: use a lengthy high entropy passphrase, securely communicated on a separate channel (preferably two or more separate channels, such as half the passphrase spoken over a land-line and half via iMessage.)
May 9	comment	encrypt message with one digest 0-9 instead of 01-26 That was a brilliant demonstration of your point!
May 7	comment	How to hash a structure that needs to include that hash's outcome? @mikeazo, if you're going to all that trouble of swapping the checksum, you may as well put the MAC at the end of the structure and omit it from the computation entirely. It's less complexity, less moving parts, less to incorrectly implement, and therefore more secure.
May 4	comment	session keys in an online e-voting system This doesn't ask a crypto question. Are you asking how servers work? How to code web pages? Or how to generate a session key?
May 4	comment	recommendation for steganography tool? @layla , a histogram is a report of the luminance of the colors in an image. It is not a component of a JPEG image, so your question doesn't really make sense. Do you mean a stego program that alters the quantization entries chosen?
May 3	comment	What length should the padding be when encrypting or signing with RSA? Standard RSA implementations like PKCS#7 and CMS specify random padding to prevent two identical messages from yielding the same output. Is there a difference between what you are trying to accomplish with the salt and the standard implementations?
May 2	comment	Knowing a valid salted hash for an unknown secret, is it possible to compute another valid hash? I'm still guessing at your intent, but it seems like you want to create parallel systems that can yield different digests given the same inputs. Some implementations use unique salt as the differentiator, by taking the hash of message M+"system1", M+"system2", etc. Otherwise you could use different hash algorithms, but that would be complex, confining, and inflexible.
May 1	comment	chaining rsa with ecies Now I understand your point. Sorry if the description was confusing, I was trying to state exactly that: to store the TDEA key alongside with the private key. Yes, if you encrypted the TDEA key and kept it with the data, that would be utterly useless.
Apr 30	comment	How to compare two datasets „anonymously”? @RickyDemer, post that as the answer, because it's the answer.
Apr 30	comment	chaining rsa with ecies It's not bogus, but it's another layer of protecting the TDEA key. Sure, he could superencrypt the TDEA message with AES, too. There's no particular rule saying keys must be encrypted only with asymmetric algorithms, and data must only be encrypted with symmetric algorithms. That's the common use of public key cryptography, but this application may not even have that need.
Apr 29	comment	toy hash algorithm At this point the idea probably isn't to get students to cryptographically break a hash function, it's more likely intended to teach them "why it's important that it's hard to discover a collision" and "why it's important that you can't recover the original message from the digest".