146 reputation
5
bio website
location Germany
age
visits member for 1 year, 6 months
seen Aug 23 at 15:20

I'm a professional software developer employed at a well-known telecommunications company in Germany, where our team mainly develops and maintains internal system's software using Java J2EE, RDBMS, and associated current technologies. Before my current contract I've been studying computer sciences at the University of Koblenz, Germany where I graduated with the academic degree "Diplom Informatiker" while working part-time as a developer.

Besides my current profession I persue my interests in automotive technologies, embedded systems, and digital electronics developing both software and hardware projects, often using microcontrollers as the conceptual bridge between the two. Along the same line, I sometimes engage in middle- to low-level PC programming (Windows). - I like pushing the limits of what's possible :-)

Developing applications for the Android OS, both native and in Java, as of now concludes my experience in SW development on *nix platforms, while the Raspberry Pi is still sitting on my cupboard waiting to be explored when I have the time.

On the abstract to conceptual level I enjoy chances to busy myself with algorithms and optimizations thereof, as well as developing and optimizing processes, where I sometimes catch myself thinking in rather technocratic ways. Comes with the job, it seems ;-)


Sep
24
awarded  Autobiographer
Sep
11
awarded  Popular Question
Aug
22
comment Is it secure to derive an AES key from a MAC?
When you dismiss the key from the HSM, no one will be able to decrypt the encrypted per-file keys anymore and so the files will be gone. Voilà. - Or is there something I'm missing?
Aug
22
comment Is it secure to derive an AES key from a MAC?
Your algorithm looks a little over-complicated to me. Why not just encrypt the per-file 256-bit random number (per-file key) with the secret key from the HSM and publish this encrypted key with the metadata?
Mar
23
revised SHA-256: (Probabilistic?) partial preimage possible?
added 1462 characters in body
Mar
23
comment SHA-256: (Probabilistic?) partial preimage possible?
Alledgedly, it does when reduced to some 30 rounds. Which could be a reasonable approach. If it fails for, say, 15 rounds with significant probabilities, that may lead to a possible shortcut in the way I'm thinking of, reducing the computation to, e.g., 49 rounds + one probability estimation.
Mar
22
comment SHA-256: (Probabilistic?) partial preimage possible?
Yes, I have seen (and linked to in my question :)) that web site. And I found that the "pure" SAT approach does not gain much. I'm just still wondering if there are no short cuts to be found if simplifying (for instance the SAT approach) by probabilistic/heuristic approaches. -- I think I need to look up those papers about differential c.-analysis I referred to; they probably would show more clearly how I believe SHA's complexity could be reduced by probabilistic/heuristic means.
Feb
19
awarded  Editor
Feb
19
revised SHA-256: (Probabilistic?) partial preimage possible?
deleted 2 characters in body; edited title
Feb
19
comment SHA-256: (Probabilistic?) partial preimage possible?
@JBentley Seen this way, your argument sounds valid. Yet, I'd say it depends on the definition of "brute force". If you can probabilistically "skip" some d rounds inside the hash function this does not mean you can preclude a set of input messages without acutally doing r-d rounds for each input message. So, "better than brute force": Yes, possibly in terms of the number of computation steps required; no, in terms of the number of applications of the (partial) hash function needed.
Oct
30
comment SHA-256: (Probabilistic?) partial preimage possible?
Thank you for answering. However, I am not convinced that the process cannot be simplified. Especially I was interested in a probabilistic approach in forward direction of the algorithm which is not necessarily the same as breaking the compression function 'backwards'. Unfortunately, my researches about that seem to be no longer of any use given that the evolution of hardware (ASIC) has caused far more increases in speed than could ever be achieved by 'clever' exploitation of the algorithm; even if one could reduce the effort by 50% the ASICs will easily outperform that in a short time.
Oct
25
comment Can I safely replace XOR with ADD in a stream cipher?
Whether your stream cipher is broken or not, ADD does make a difference compared to XOR. This is not about obscuring flaws in the cipher, but about using its output more effectively.
Sep
21
comment Can I safely replace XOR with ADD in a stream cipher?
In fact, on the security side the bytewise addition is superior to the XOR operation. Simply put, with addition modulus 2^n each bit of the key and/or the plaintext has the chance to influence up to n bits of ciper text, which causes better diffusion of input data and complicates attacks on the cipher's output.
Jun
20
revised SHA-256: (Probabilistic?) partial preimage possible?
edited tags
Jun
20
awarded  Student
Jun
20
asked SHA-256: (Probabilistic?) partial preimage possible?
Jun
8
awarded  Supporter