3,173 reputation
215
bio website
location
age
visits member for 1 year, 2 months
seen 2 hours ago

3h
comment Encryption algorithm designed to be easy to decrypt by machine but impractical to decrypt by hand
How about multiplying the plaintext by a matrix in $GF2^8$? Generation of the matrix to match the plaintext size would need to follow some predefined algorithm to be consistent
10h
comment Why develop new stream ciphers when block ciphers can be trivally made into streams?
On small modern CPUs for embedded systems, RC4 will be hilariously faster
23h
comment Public key encryption without ciphertext expansion
if that is is ranged 0-255, that is 256 bytes, which is 2048 bits, a standard secure RSA key size
1d
comment Password generation/storage scheme
I would assume using the key in HMAC with the site name as the plaintext?. It should be noted I designed a scheme around this idea, there are a lot of complexities involved, like site password character and length restrictions, among other things
1d
comment Encryption algorithm designed to be easy to decrypt by machine but impractical to decrypt by hand
harder at a linear or geometric rate?
1d
comment How can a good pseudo-random number genarator be made?
Sponge construction over a suitable permutation fits the bill, as it has well defined and analyzed security properties
1d
comment Encryption algorithm designed to be easy to decrypt by machine but impractical to decrypt by hand
You are pretty much describing any modern cryptographic algorithm with a human readable encoding scheme...
2d
comment Encryption algorithm designed to be easy to decrypt by machine but impractical to decrypt by hand
should it be practical for a human to encrypt by hand?
2d
comment public key certificate on TLS/SSL
TLS is built on the premise of certificates for authentication. You can self sign your certificate if using it for yourself and not on a device to be access by the public
Oct
25
comment Crypto (mainly binary
0s per line, 1s per line, digits per line, convert to bytes and ignore nulls, etc, etc. fyi, requests for deciphering data is off topic
Oct
25
comment Crypto (mainly binary
there does not seem to be enough entropy for an encrypted message, it is probably coded somehow, or possibly just mostly junk data
Oct
25
comment Large file validation on an embedded system through hash and encryption
delta updates will not help him if he needs to verify the entire file everytime the application is launched, but it will definitely make updating the program faster
Oct
25
comment Large file validation on an embedded system through hash and encryption
Also, how fast is the read speed of the storage device? sequential reads on those things usually tops out at 150MB/s, thats over a minute just to read the file from storage for verification
Oct
25
comment Advantages of combined PRNGs
size is relative, 4096 bits is large for a cryptographic key, but very small for a lot of other reasons. A cryptographic key with equal distribution of bytes would look like a nonrandom permutation, but in the long run (megabytes) yes, a PRNG should have a near even byte distribution.
Oct
24
comment Large file validation on an embedded system through hash and encryption
BLAKE2b on 64-bit ARM can operate at 164MB/s per GHz, which is a max of 410MB/s on a top end quad core unit @ 2.5GHz. Reducing the hash to 6 rounds will up that to 680MB/s and probably still be secure.
Oct
24
comment Large file validation on an embedded system through hash and encryption
You want to hash at 2GB/s.. on an embedded system? MD5 is a quarter that speed on a 3GHz xeon. BLAKE2b is your fastest option. It may be prudent to validate the files only when they need to be accessed.
Oct
24
answered Format Preserving Encryption for 32 or 64 bit plaintext values
Oct
24
comment How are salt values more secure?
Note that "using timestamps" is very bad, unless the timestamp was an input to some function that generates the salt, then that is acceptable. A future salt should not be predictable to an attacker.
Oct
24
comment How are salt values more secure?
\$alg\$salt\$hash is a common way of storing hashes in a database, so a typical database field may look like \$apr1\$h7Fb0iS3\$24a7435b994b0bf6ea99155ac24747ec
Oct
24
comment Advantages of combined PRNGs
I am using a similar system, CTR mode XOR with the OS PRNG, which is then hashed. This guarantees minimum entropy per output bit (7 bits of input to hash for 1 bit out), as well as maintaining security with a potentially malicious CryptGenRandom/RDRAND