I'm reading in the Nature of last week (September, 4th) about the nervousness of some scientist with the colleges that goes to a conference and takes photos with digital cameras and uses the data for their own publications.
I cannot definitely understand this position. The first ones, the lecturers are presenting some data in public and they can have the title of the first of publish it. At the same time this can be used as a base of the next publication upgrade, or to find any mistake that exists.
In this second possibility, imagine that in this PAMELA presentation they announce the dark matter detection (implies existence) with a mistaken proves that no one in the conference can study because of their obscurity. I'm not saying they should did mistakes, I'm saying not other scientist can check it. Yes, they like to review with some other colleges chosen by themselves, but this doesn't mean publish.
If they don't trust a 100% to their study why they publish it? Because no one else publish it before but saving the dress if they made a mistake? Oh, please! This have more sense in politics, or some where than the only important think is naming. There is no price for the second who discover dark matter, I understand it. But what happens if another scientist team is closer to the verified results and publish it; will this ones says 'they copy it from us' with an ultra-hidden camera in the conference?
Actualization: Reading more about this column in Nature, I understand the problem is more because the copyright of many publications than specifically because the scientist doesn't like it. Many times the slides are published after the conference, but the problem can come when the journals decides which data can be publish out them. How is the owner of the investigations?
Showing posts with label degree. Show all posts
Showing posts with label degree. Show all posts
2008/06/21
Repository mirroring
This post title contain the necessary words to find a solution to the problem that I post at the beginning of this month. After some try touching what was not think to be touch (the files in the .svn directory of a checkout) I decide to send an email to the users list.
Why I didn't send it before? Easily I receive a feedback indicating me that I am trespassing the limits of the things that the users should be allow to do. Then I explain not only the intentions, and more the reasons why I want this feature. And a fast answer appears!
Yes, a tool to help what I want exist, and its name is svk! I'll use it and reflect the impression. Really thanks to Ryan Schmidt.
Why I didn't send it before? Easily I receive a feedback indicating me that I am trespassing the limits of the things that the users should be allow to do. Then I explain not only the intentions, and more the reasons why I want this feature. And a fast answer appears!
Yes, a tool to help what I want exist, and its name is svk! I'll use it and reflect the impression. Really thanks to Ryan Schmidt.
2008/06/01
The project starts
The meditation time is over. The alpha sources of the branch 0.9 of the elliptic curve project has been upload to my svn repository. I say 'my' because this development files are not public until it has something useful to be publish. Many things are changing in the sources from the last 0.3 branch (that never saw the light).
I have a friend who sometimes says when we write code, we make bugs, as less code we write less bugs we make... I am completely agree with he, and this is one of the ideas that comes in the 0.3 branch: try to have the same code in the patch for the GnuPG 1.4 branch than the code that the libgcrypt 1.4 has.
Between them there are some differences, but the biggest ones has to be solve by the precompiler. Others can be solved by declarations. But the most important improvement that this merge has is the split of the code in different files. The first version was think to have everything together, in one file; now the cryptographyc code will live in the cipher directory, and the mathematic code in the mpi directory (at the end the operations between point are solved by low level operations over finite fields).
After the brainstorming did here, the best option, and the most pracmatic is to implement the Internet Draft for the ECC in OpenPGP.
I have a friend who sometimes says when we write code, we make bugs, as less code we write less bugs we make... I am completely agree with he, and this is one of the ideas that comes in the 0.3 branch: try to have the same code in the patch for the GnuPG 1.4 branch than the code that the libgcrypt 1.4 has.
Between them there are some differences, but the biggest ones has to be solve by the precompiler. Others can be solved by declarations. But the most important improvement that this merge has is the split of the code in different files. The first version was think to have everything together, in one file; now the cryptographyc code will live in the cipher directory, and the mathematic code in the mpi directory (at the end the operations between point are solved by low level operations over finite fields).
After the brainstorming did here, the best option, and the most pracmatic is to implement the Internet Draft for the ECC in OpenPGP.
2007/11/17
Secret sharing
Before to write about the possible implementation of elliptic curves over fields of characteristic 2, I want to propose another option: do some implementation over multi-public-key cryptography. This is if you have a secret that can not be trusted in only one person you can divide your secret in parts and give only one to one person. But under one reconstruction of this secret, you need all the people present.
If the secret that I said before is divided using a (n, t)-threshold scheme then your secret is shared between n players, but it can be reconstructed with t survivants from an attacker conspirator (this becomes from the thriller films).
You can create schemas with all the combination that you imagination gives. If you have a group of 10 people with a two heads, and two subgroups of four; and what you want if to have present two people of each subgroups and one of the heads (at least) you should have an schema (3-3)-threshold for the main secret and this keys to the shared secret will be re-shared as a (2-1)-threshold for the heads, and 2 (4-2)-threshold for each subgroup.
In Barcelona there are people working in this things. I meet some of them in some congresses and they are really nice people. For a long time, the secret sharing schemas have had charm for me. Could be interesting to implement this over embedded systems...
If the secret that I said before is divided using a (n, t)-threshold scheme then your secret is shared between n players, but it can be reconstructed with t survivants from an attacker conspirator (this becomes from the thriller films).
You can create schemas with all the combination that you imagination gives. If you have a group of 10 people with a two heads, and two subgroups of four; and what you want if to have present two people of each subgroups and one of the heads (at least) you should have an schema (3-3)-threshold for the main secret and this keys to the shared secret will be re-shared as a (2-1)-threshold for the heads, and 2 (4-2)-threshold for each subgroup.
In Barcelona there are people working in this things. I meet some of them in some congresses and they are really nice people. For a long time, the secret sharing schemas have had charm for me. Could be interesting to implement this over embedded systems...
Libgcrypt
As a continuation of the yesterday brainstorming, I want to write something more about the research project. Today I will think about what can make to contribute in the libgcrypt. In this library, the ECDSA that I did in my last research project, was rewritten. This was the objective of the project, to contribute in the free software.
It is necessary to do somethings in this library. The file 'cipher/ecc.c' contains a TODO list with the necessary improvements that this library needs:
How the project was adapted to the libgcrypt? The patch from it comes was written in a monolithic file in the way to do as less modifications as possible in the gnupg (in the 1.4 branch).
Then Werner made a good work moving the particular elliptic data structures to 'src/mpi.h' maintaining in the cryptofile 'cipher/ecc.c' the ones that have a direct relation with the pub and the private keys. Then, there are another file 'mpi/ec.c' that have everything about the mathematics background. But, in my opinion, this have one problem: the elliptic curve discrete logarithm problem (ecdlp) can be brought over primary fields (F_p) and also over fields of characteristic 2 (F_{2^m}), and this file should be split in this two mathematics bases.
This last paragraph propose another possible research project, that is implement what we had over primary fields but over characteristic 2 fields...
It is necessary to do somethings in this library. The file 'cipher/ecc.c' contains a TODO list with the necessary improvements that this library needs:
- If we support point compression we need to decide how to compute the keygrip - it should not change due to compression.
- In mpi/ec.c we use mpi_powm for x^2 mod p: Either implement a special case in mpi_powm or check whether mpi_mulm is faster.
- Decide whether we should hide the mpi_point_t definition.
- Support more than just ECDSA.
How the project was adapted to the libgcrypt? The patch from it comes was written in a monolithic file in the way to do as less modifications as possible in the gnupg (in the 1.4 branch).
Then Werner made a good work moving the particular elliptic data structures to 'src/mpi.h' maintaining in the cryptofile 'cipher/ecc.c' the ones that have a direct relation with the pub and the private keys. Then, there are another file 'mpi/ec.c' that have everything about the mathematics background. But, in my opinion, this have one problem: the elliptic curve discrete logarithm problem (ecdlp) can be brought over primary fields (F_p) and also over fields of characteristic 2 (F_{2^m}), and this file should be split in this two mathematics bases.
This last paragraph propose another possible research project, that is implement what we had over primary fields but over characteristic 2 fields...
2007/11/16
Elliptic curve isogeny
A few days a go (the 9th of November) a new patch about elliptic curves on GnuPG had been published. With two month delay since Mikael sent the code to me... As I read in the esr's book this is long longer time than acceptable.I'm sorry.
Now it's time to retrieve the projects. It is necessary to recuperate the gumstix development and also this year I will do my master degree research project. Against about elliptic curves. But what I said is really generic. I have some ideas, that I wanna write in this blog to be used as a brain storming to specify what is able to do and discard something else. Today is the turn elliptic curve isogeny.
Without speak on mathematics, and as far as I know, if you have a cryptoanalyst against finite fields and your paranoia says you that your privacy could be compromised, the only option that you have is increase your keylength... Use a bigger RSA or ElGamal key. Over elliptic curves you have one option before this: you can change the elliptic curve (and propose the elliptic discrete logarithm problem over a complete new one field). Nothing that the cryptoanalist computes for the old field can be used here.
But the cost to generate a new curve every key generation is hard. There are too much proprties and characteristics to test and be sure that this curve have good cryptographyc properties. One way to generate a new curve with a guarantee that it has cryptographyc characteristics is to perform some isogeny transformations to one curve that you know that it has this properties.
There exist algorithms to obtain a graph where the nodes represents elliptic curves and the edges represents an isogeny transformation. I don't need to go so far to know about isogenies, in the same university research group with I am studying they are specialists on this. For a long time a go I am listening conversations talking about this transformations an its advantages. The data structures that this isogeny transformation creates receive the name volcanus, and a join of volcanus receive the name of cordillera.
But! If the attacker knows the steps that you did in the volcanus to obtain your new isogeny curve, and it has good knowledge on isogenies transformation, it is possible to 'migrate' all the computation work that before I said that should be not useful, to the new field and continue the attack. This means that the isogeny could only generates more work to the attacker but it maybe doesn't improve the security.
An option, is to perform the transformation in secret. Generate a way in the volcanus during the key generation, from then you use the new elliptic curve and forget the relation with the one from it came... If the attacker is not able to stablish the path from one to the other, the system is secure.
Long time a go I was talking about this with Mikael, and he shows me that there are many people in the world that propose to use a public key isogeny cryptosystem, where the secret key is precisely this path in the volcanus.
Then the question is: Are we complicating so much the problem? In the low level we need to be careful with the AES symmetric cryptoanalysis. In the centre we have to beware if some algorithm better that pollard's-rho has been discovered. An then a third front we will have this transformation that could be grateful to reset a hole smartcard cryptosystem.
Yes, it is a grate thing to have the possibility to reset a institution smart card system without increase the keylength but with a restablishment of the security against an attacker.
Now it's time to retrieve the projects. It is necessary to recuperate the gumstix development and also this year I will do my master degree research project. Against about elliptic curves. But what I said is really generic. I have some ideas, that I wanna write in this blog to be used as a brain storming to specify what is able to do and discard something else. Today is the turn elliptic curve isogeny.
Without speak on mathematics, and as far as I know, if you have a cryptoanalyst against finite fields and your paranoia says you that your privacy could be compromised, the only option that you have is increase your keylength... Use a bigger RSA or ElGamal key. Over elliptic curves you have one option before this: you can change the elliptic curve (and propose the elliptic discrete logarithm problem over a complete new one field). Nothing that the cryptoanalist computes for the old field can be used here.
But the cost to generate a new curve every key generation is hard. There are too much proprties and characteristics to test and be sure that this curve have good cryptographyc properties. One way to generate a new curve with a guarantee that it has cryptographyc characteristics is to perform some isogeny transformations to one curve that you know that it has this properties.
There exist algorithms to obtain a graph where the nodes represents elliptic curves and the edges represents an isogeny transformation. I don't need to go so far to know about isogenies, in the same university research group with I am studying they are specialists on this. For a long time a go I am listening conversations talking about this transformations an its advantages. The data structures that this isogeny transformation creates receive the name volcanus, and a join of volcanus receive the name of cordillera.
But! If the attacker knows the steps that you did in the volcanus to obtain your new isogeny curve, and it has good knowledge on isogenies transformation, it is possible to 'migrate' all the computation work that before I said that should be not useful, to the new field and continue the attack. This means that the isogeny could only generates more work to the attacker but it maybe doesn't improve the security.
An option, is to perform the transformation in secret. Generate a way in the volcanus during the key generation, from then you use the new elliptic curve and forget the relation with the one from it came... If the attacker is not able to stablish the path from one to the other, the system is secure.
Long time a go I was talking about this with Mikael, and he shows me that there are many people in the world that propose to use a public key isogeny cryptosystem, where the secret key is precisely this path in the volcanus.
Then the question is: Are we complicating so much the problem? In the low level we need to be careful with the AES symmetric cryptoanalysis. In the centre we have to beware if some algorithm better that pollard's-rho has been discovered. An then a third front we will have this transformation that could be grateful to reset a hole smartcard cryptosystem.
Yes, it is a grate thing to have the possibility to reset a institution smart card system without increase the keylength but with a restablishment of the security against an attacker.
2007/07/05
Language processors
After many years studying computer science, another step is close to be finished. This is incredible, I need like 7 years to study my bachelor degree to be a technical engineer, using the Spanish naming. An 2 years a go, I began the Master degree and I am only at one subject to finish it. Next September I want to pass it, and then I will work on the research project, indispensable step to obtain the title.
One subject to the end: Language processors, or in other words compilers. Lexical analyzers, the abstract syntax tree, and the semantics. As far as I know, it is close to the subject that I already study when I was on Erasmus in the Vrije Universiteït.
During this summer that I will do the practicum works of this subject, I will profit to explain something.
One subject to the end: Language processors, or in other words compilers. Lexical analyzers, the abstract syntax tree, and the semantics. As far as I know, it is close to the subject that I already study when I was on Erasmus in the Vrije Universiteït.
During this summer that I will do the practicum works of this subject, I will profit to explain something.
Subscribe to:
Posts (Atom)
