meta user
network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 9 months |
| seen | 16 hours ago | |
| stats | profile views | 5 |
|
1d |
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. |
|
2d |
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 15 |
answered | True random numbers generated by sensors |
|
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 13 |
answered | random number generator 10-side dice alternative |
|
May 13 |
answered | Increased CRC collision probability when adding bits to input message |
|
May 9 |
awarded | Informed |
|
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 |
answered | recommendation for steganography tool? |
|
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 |
revised |
Knowing a valid salted hash for an unknown secret, is it possible to compute another valid hash? correction |
